[Mailman-Developers] [Merge] lp:~wacky/postorius/csrf into lp:postorius

[Barry Warsaw]

I don't want to side track too long into a vcs discussion, so I'll respond
here and then you can have the last word.  :)

On May 21, 2012, at 12:21 PM, Stephen J. Turnbull wrote:

>Barry Warsaw writes:
>
> > I personally think that rebase is an abomination generally required
> > by workflow policies that try to overcome tool deficiencies.  By
> > not *requiring* rebase (it is of course possible), it means that
> > all your intermediate commits are preserved
>
>No VCS "requires" rebase, or removing commits from history.

Agreed, but just about every git fan I've ever talked to always emphasizes
rebase as an important part of the merge workflow.  When I dig deeper into why
that is, it always seems to come down to this: when I merge your branch into
mine, all your intermediate commits get slapped right onto my branch, one at a
time.  Which means that if your branch introduced a regression, and I want to
bisect to find it, I have to bisect through all your intermediate commits.
This has implications for logging too, which would show me all your
intermediate commits as well.  If I saw that all the time, I'd think it would
suck too.

Admittedly, I'm not speaking from rich first hand experience, so feel free to
correct the FUD.  But I really like the bzr way of seeing my merge of your
branch as one clearly labeled revision on my branch.  I can dig into your
intermediate commits if I want (there's often valuable information there), but
most of the time I don't care, and my tool allows me to not care, until I do.

> > because sometimes they are useful.  Most of the time you can ignore
> > them which is exactly how it should be, IMHO.
>
>This is the nub of the argument.  bzr mandates a presentation of
>history that bzr fans like, and some folks don't.  I'm not a big fan
>of bzr log -n# for any value of # AFAIK ;-), but I'm willing to try
>different things as they seem useful.

There are some good graphical representations of that history, for folks who
like that sort of thing.  I think they can make digging into those branch
sidings nicer.

> > In a well-developed branch, that rationale should be included in
> > the intermediate commit messages of the proposed branch (not to
> > mention good comments in the code <wink>).  Rebasing that away just
> > seems *wrong* to me.
>
>That is not the purpose of rebase, and I doubt any well-managed
>project permits it.

Isn't this essentially how the kernel works?  When I talk to developers of
git-run projects, it does always seem to come down to this.

> > As far as the attributions go, I think the best place to be
> > explicit is in the NEWS file.  Folks getting Mailman via tarball or
> > distro package won't have access to the VCS history anyway.
>
>False.  It's less convenient for them, but they can browse launchpad.

If they can find it.  I still think a NEWS file or ACKNOWLEDGMENTS file
(suitably maintained :/ ) is more accessible to more folks.

>Anyway, the NEWS file is way too coarse for the purposes that Wacky
>and I have in mind.  Eg, George may need some changes to the IArchiver
>interface, and send you a branch that makes them.  But a crucial patch
>may have been suggested and supplied by a mentor.  I trust that you'll
>mention George in NEWS, but will you even be aware of the
>contributions by third parties?

Probably the best way to handle this is for George's NEWS file entries to
include that information.  If George really did merge a mentor's branch for
the crucial patch, and then I merged George's branch, the history of that will
be reflected in the bzr revision history.  It may be off in a 2-level deep
siding, but it's there.  The usefulness of that seems independent of the vcs
being used.  A plain text file in the tree is still going to be a better place
to record contributions, IMHO.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120521/5a42144f/attachment.pgp>