[MERGE] left align log output if it only contains merge revisions

[Kent Gibson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Aaron Bentley wrote:
> Kent Gibson wrote:
>> Firstly, I don't blame you, the underlying problem is that the
>> role of the RM hasn't been sufficiently well defined.  That isn't
>> your fault. As I've eluded to before, my opinion is that the RM
>> should be the benevolent dictator for a month.
>
> I really don't think we should lay this on the RM at all.  People
> should not need that extra prompting.
>
> Unfortunately, I have found that they do.  In this past release
> cycle, I have had several patches go un-reviewed until warned that
> I would bypass the review process and submit unreviewed patches.
>
I agree.  If it were an ideal world things would just hum along on
their own without the need of someone providing oversight.
So far Bazaar has done pretty well, but since the London sprint you
cores seem to have been focussed on the performance drive at the
exclusion of more mundane things like reviewing code from non-cores.
(Reviewing a core's code has a different dynamic since you get
something out of it - that core is more likely to review your code in
return.)

> Reviewing isn't really related to releasing.  It should always be
> done promptly, because a patch may go through several cycles before
> merge.

Sorry to pin it on the RM, but I don't see anyone better suited.
Btw, what I think of as the RM others might call Project Manager for
the release in question.

>
> And the RM doesn't really have the authority to make people act,
> only to encourage them.

I think the cores should be answerable to the RM, at least wrt
scheduling their input to the release.  That is one of the
responsibilities of being a core, IMHO.

For non-cores all the RM can do is plead, but for non-cores the work
doesn't involve reviewing, it's all about getting their code up to
spec so it can be merged for the release.
I would imagine non-cores would be keen to comply ASAP.  I know I try
to respond with updates as soon as life permits.

>
>
>> Aaron's view is that mainline revisions have a special place in
>> bazaar
>
> I'm not sure whether you mean that the specialness of mainline
> revisions is my view only.  It's not.  It's a design decision that
> has affected many things:
>
> - the assignment of revnos - the way "pull" describes what it did -
> the fact that "merge --pull" is not the default behavior - the
> behavior of "status" when there are pending merges - the behavior
> of missing - the behavior of log --short and log --line - the
> append_history_only flag for branches - the Branch api
>

I didn't mean to imply it was your view alone, just that it was your
side of the argument.

>> , and deserve the left margin to themselves.
>
> It would be much mess controversial to say "mainline revisions are
> special, but that doesn't mean that the left margin must be
> reserved for them."

That works for me.

>
> If you want to say "mainline revisions aren't special", then please
> see our debates with the git folk.  Some VCSes take that approach,
> but we don't.
>

Fair enough.  I probably should give it another pass next time I have
a few days to spare.
That is obviously part of the thread I didn't absorb on the first pass.
Is there something on the wiki that might cover this?

Cheers,
Kent.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGi6WAgoxTFTi1P8QRApGkAKCThMNZi1cxyMsuLQkyKLZ4NtBMmQCgkXuw
FaPmm+T7E0DFfKf/vr3rc5w=
=qqLf
-----END PGP SIGNATURE-----