Re: [Mailman-Developers] [Merge] lp:~wacky/postorius/csrf into lp:postorius
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. > 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. > 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 ). Rebasing that away just > seems *wrong* to me. That is not the purpose of rebase, and I doubt any well-managed project permits it. > 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. 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? ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Merge] lp:~wacky/postorius/csrf into lp:postorius
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 , 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 ). 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 ___ Mailman-Developers mailing list Mailman-Developers@python.org h
Re: [Mailman-Developers] [GSoC 2012] Metrics
Hello Stephen, On Sat, May 19, 2012 at 09:12:03PM +0900, Stephen J. Turnbull wrote: > I don't see why. I would think quality metrics would be usefully > presented via the same application as quantity metrics. It would be > interesting to correlate quality and quantity, for example. What i was trying to say is that the quality metrics need some designing on a "posts rating system" first. Of course they will be presented by my app. > Do you mean to say "this is out of scope of my project?" As much as > I'd like to see quality metrics provided, I'd have to agree with you > that it's out of scope of your project (maybe you could do one or more > quality metrics on a time-permitting basis at the end of the period). Yes, i think it is out of my GSoC project, but i would like to implement this after finish with quantity metrics this summer. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Merge] lp:~wacky/postorius/csrf into lp:postorius
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,
