On May 19, 2012, at 5:12 PM, Florian Fuchs wrote:

Personally, I only delete branches only if I'm really sure I won't work on them any longer. I'm also pretty sure that when you delete a branch that has been merged into a project, it's still accessible from the revision timeline and the bug report, even if it's no longer visible in your profile's branch list. So once it has been merged into another branch there's no way of removing it from LP.

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.

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.

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 :)

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.

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

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.

...

I'm working on some new underlying base.html files. Fortunately, Django lets me place them directly in my website directory and the template loader then overrides your version. When they are ready for, and get merged into the trunk, I can easily revert to the vendor version.

I think that we should create an otherwise empty "themes" app and place the various templates within that namespace rather than directly in the postorius namespace. What is your opinion?

I guess it would be a bit confusing to have the default templates in a completely different app (at least for people who use django regularly). My feeling is that it's kind of expected for django users to have a default theme delivered as part of the actual app package. So I would prefer to deliver the theme as part of postorius as well.

As far as alternative themes are concerned I have seen some cases where additional themes were distributed as separate apps

As an "installer" mechanism, this seems just fine. And I agree that a default theme should be delivered as a part of the postorius package.

However, I am concerned that your implementation exposes "/postorius/" in the URLs and in the template names for the themes.

IMHO, all of this design seems to reflect a philosophy based on the idea that the purpose of the website is to run mailing lists. I think that we need to look at it from a different perspective. The use case is that of a company, organization, etc. that has a presence on the 'net. For example, their website is primarily an e-commerce site. The company runs a customer contact mailing list to which individuals can subscribe. Here, the postorius interface is a small subsection of the overall website. But, properly written, the display should appear to be a seamless addition to the content. This implies that "themes" would apply to the whole site and not just the postorius section. As such, I think that we should put the theme definition in a "theme" namespace rather than within the "postorius" namespace. This does not imply that we cannot package one, or more, themes in the postorius app.

I suggest that we deliver at least two themes. One would be in the style of "mailman" and the other that of "django". I suggest this because, if we cannot do both easily, it will provide some indication of the usability of our website structure.

Richard