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