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

[Barry Warsaw]

On May 20, 2012, at 09:22 AM, Richard Wackerbarth wrote:

>My interest in deleting a branch is to clean the external namespace so that
>users are not wasting their time examining branches which are not currently
>useful.
>
>It appears that Launchpad handles this by setting the branch status to
>"merged".  As a result, I don't need to do anything.

Merged is usually automatically set when the branch is merged into the series
trunk (e.g. lp:mailman).  You can also set the status to Abandoned to make it
clear it isn't useful any more.

>> I use git a little more often then Bazaar, but I can't say that I am
>> clearly in favor of one of them. I guess I'm just happy whenever I don't
>> have to use SVN any more. ;-)
>
>My experience goes back to RCS. CVS was an improvement on that. Today's
>version control systems are much better. My only complaint is that there are
>too many of them :)
>
>My preference for git stems largely from the lack of decent gui tools for bzr
>on Mac OSX. That, plus the fact that I run a git-based infrastructure and
>most of the other projects in which I participate use git, makes it an easy
>choice for me.

While I really don't want to get into yet another religious VCS discussion on
yet another unrelated list <wink>, Bazaar has one killer feature IMO that
neither hg nor git has.  (There are many things I prefer in bzr over hg and
git, but this is the big one).

Bazaar has a strong concept of a 'mainline' branch.  This means that merges
are first class objects, and when I merge your feature branch into the trunk,
it shows up on mainline as a single commit.  And because tools like log and
bisect treat the merge as a single commit by default, they always do the right
thing, without requiring you to rebase your branch before its merged.  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 because sometimes they are useful.  Most of the time you can ignore
them which is exactly how it should be, IMHO.

>> I think the workflow used in Launchpad is not necessarily the only way
>> to use Bazaar. However, I can't say that I have really fully groked the
>> launchpad way, but here's how I understood it:
>> 
>> Every project has an owner (a person or group, "Mailman Coders" in our
>> case). Changes to the trunk can only be made by owners, which is why
>> nobody else's names ever appear in the revision history.
>
>What a waste of display space :)

They do appear in the revision history, but they're off to the side and
ignored by default.  Use `bzr log -n0` for all the verbose glory.

>> The way launchpad credits the work of "non-owner" contributers is by
>> stating the merges and bug fixes in the revision history the way it just
>> happened with your branch.
>> 
>> So there's nothing wrong with the way you did it. Just create a new
>> branch with the changes and then do a merge proposal. You *could*  link
>> the branch to the bug report yourself, just to make sure I don't forget
>> that before merging it in.
>
>I'll try to do so for the next submission.  As you note, there are many ways
>to use a particular tool. "Learning the culture" is part of the contribution
>task.

Yep!  All tools take some getting used to.  I agree it's kind of a shame that
bzr/git/hg all do things differently, as does Launchpad/github/bitbucket.  But
hey, FLOSS is all about freedom, right? :)

>> You see, those "non-owner" contributions are buried a bit deeply inside
>> the revision history. And I guess that's why Barry suggested to add a
>> more obvious "contributed by ..." message to every commit that involves
>> the work of a non-owner.
>
>I prefer the more explicit attribution of git because it makes it much easier
>to determine "blame". Not that I care about kudos, points, or such, but
>because I often want to know more about the rationale behind some particular
>change. (The documentation rarely is adequate in explaining rationale -- and
>we are all "guilty" in that respect) To do so, I need to know the author

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.
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.

>> But, as I said: That's just how I understood the LP workflow. I'm sure
>> there are still things I've missed...
>
>My workflow pattern is to create short-lived branches for each bug, Once the
>bug is closed and merged into trunk, the branch is effectively
>"dead". Launchpad seems to handle this adequately.

+1

Cheers,
-Barry