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, 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
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
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 <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.
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?
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
If I am not mistaken, both git and bzr are capable of generating and displaying the same graphical structure.
As for the merging of branches, git is perfectly capable of merging a branch as a single merge point in the graph (use the -no-ff option). And, I am sure that you could cause bzr to emulate the git "one at a time" incremental merge behavior, if you so wish. Good, or bad, those are not the defaults (unless you set your personal preferences to override the vendor default). Many (most?) users simply use the system default and never realize that they have other options.
Again, I will comment that my preference for git is largely based on the lack of support for bzr on Mac OSX. If we had the same GUI support that is provided by, for example GitX, and we had integration with the Xcode IDE, then I am sure that I would not care which DVCS was used as the backend.
But, IFAIK, that support is not available. And, it is through that support that I do almost all of the things that I need to do on a routine basis. For the few remaining cases, I do not mind reverting to the command line (with the man pages in another window since I never remember the esoteric syntax of each VCS).
Perhaps we can have the best of both worlds by setting up a "bot" to export/import the bzr tree to a git tree on a routine basis. I presently maintain both the underlying .git and .bzr directories in my development trees.
Richard
On May 21, 2012, at 10:13 AM, Barry Warsaw wrote:
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
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/richard%40nfsnet.o...
Security Policy: http://wiki.list.org/x/QIA9
On May 21, 2012, at 10:53 AM, Richard Wackerbarth wrote:
Again, I will comment that my preference for git is largely based on the lack of support for bzr on Mac OSX. If we had the same GUI support that is provided by, for example GitX, and we had integration with the Xcode IDE, then I am sure that I would not care which DVCS was used as the backend.
I'm pretty much a command line guy, so can't help much with the gui integration. But I do get that it would be useful. I could ask around if you want though.
Perhaps we can have the best of both worlds by setting up a "bot" to export/import the bzr tree to a git tree on a routine basis. I presently maintain both the underlying .git and .bzr directories in my development trees.
I don't know if github can import foreign vcs branches, but that might be one thing to investigate. As long as we don't get pull requests from git branches, I'd certainly support that. (Launchpad can import foreign vcses into bzr branches, though Mercurial will soon be deprecated due to bit rot in the bzr-hg plugin.)
-Barry
On May 21, 2012, at 4:18 PM, Barry Warsaw wrote:
On May 21, 2012, at 10:53 AM, Richard Wackerbarth wrote:
Perhaps we can have the best of both worlds by setting up a "bot" to export/import the bzr tree to a git tree on a routine basis. I presently maintain both the underlying .git and .bzr directories in my development trees.
I don't know if github can import foreign vcs branches, but that might be one thing to investigate. As long as we don't get pull requests from git branches, I'd certainly support that. (Launchpad can import foreign vcses into bzr branches, though Mercurial will soon be deprecated due to bit rot in the bzr-hg plugin.)
I will have to find out if fast-export | fast-import works as an incremental updater. If so, whether directly on github or on a server (mine or otherwise), we can have a cron-driven bot looking for changes and cross-posting them. (At least in the bzr-->git direction.)
Richard
Barry Warsaw writes:
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:
No VCS "requires" rebase, or removing commits from history.
Agreed, but just about every git fan I've ever talked to always emphasizes rebase [...]. [W]hen 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.
All true, but if it's my branch that introduced the regression, you have to bisect the whole thing either way. Worse, in your workflow, if you have 25 commits and I have 25 commits on our respective branches, it's not uncommon for bisect to "localize" the regression to the set of those 50 commits (ie, only the final merge commit exhibits the regression).
The implication is that your workflow is happiest with many small feature branches; at the very least, bisect would not work well with kernel-style development where there are a fair number of long-lived feature branches.
I don't think there are many projects like the kernel, though. Most projects are happier with many small feature branches. The point is simply that the kernel has special needs, and git is mostly developed by kernel developers, they are going to prefer the workflow they are used to. (Other projects may have more than a little kernel envy. :-)
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.
Touche -- but your comment about graphical log viewers applies here, 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.
git allows this; you can select only merge commits for logging (and other DAG-traversal operations IIRC). It's not the default because the git and kernel developers prefer the rebase-based workflow.
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.
No, it's not. They don't "rebase away" the intermediate commits; they create a new presentation of the changes, sequencing the commits "as if" they were carefully planned, and crafting new commit messages as documentation of those changes. If you send a branch to Linus with change/message skew, you'd better be prepared for massive skin grafts in the near future (and that's the good case, it means your patch is deemed to have some socially redeeming value :-).
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.
No question incldued files are "more accessible to more folks", but the people who care in the way that Wacky and I are describing are generally going to have a checkout anyway. The "suitably maintained" caveat is also a biggie.
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
That's why I used a "mentor" example. The mentor probably shouldn't be maintaining branches for application to George's code, right? But if the description is sufficiently explicit, the git attribution machinery allows a commit with "author:wacky committer:george".
A plain text file in the tree is still going to be a better place to record contributions, IMHO.
Depends on policy. I have a patch in the Emacs tree, but since RMS put it into final form, I don't have an AUTHORS entry. (And that's all right by me, but that's another story....)
On May 19, 2012, at 9:26 PM, Barry Warsaw wrote:
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.
I can argue that this is also a weakness. The tool is imposing management practices on the users. In a current sense, conventions are equally capable of designating the mainline. In a historical sense, the mainline only indicates the order of "approval".
Having a main branch implies that the organization is imposing its idea of "the right way".
It is somewhat like the Corp of Engineers telling a river how it should travel through its delta region.
History shows that parts which once were considered "the main branch" often become byways as the momentum of the flow embraces new ideas, directions or leadership.
Richard Wackerbarth writes:
Having a main branch implies that the organization is imposing its idea of "the right way".
In some sense true, but few organizations have either the resources or inclination to maintain and support more than one "right way" at a time.
History shows that parts which once were considered "the main branch" often become byways as the momentum of the flow embraces new ideas, directions or leadership.
Are you implying that bzr isn't capable of recognizing that a new branch has become the mainline? That's false, you know. Any head in your workspace can become mainline, and any commit can sprout a new head. (It's true that it requires substantial effort to change the *public* mainline, but that's true of all DVCSes, including git: this is a consequence of the same underlying issue that we know as "the rebase problem".)
The rule in bazaar is actually the same as in git: the sequence of leftmost ancestors of the current checked-out head appears as mainline. The difference is that by default "bzr log" will hide non-leftmost ancestors of merge commits, thus emphasizing the mainline, and this behavior is part of the specification of bzr.
This is very compatible with the project workflow Barry expressed a preference for: the mainline appears as a sequence of merges of feature branches. However, bzr is perfectly compatible with much less elegant workflows, such the use of bzr to emulate CVS. ;-)
In any case, Mailman is not going to change VCSes any time soon, and if you prefer to use git or hg, bzr supports the fastimport format for export and import.
Okay, you get the last word too. :)
On May 21, 2012, at 06:32 AM, Richard Wackerbarth wrote:
On May 19, 2012, at 9:26 PM, Barry Warsaw wrote:
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.
I can argue that this is also a weakness. The tool is imposing management practices on the users. In a current sense, conventions are equally capable of designating the mainline. In a historical sense, the mainline only indicates the order of "approval".
Note that 'mainline' does not mean 'blessed master branch'. Conventions surely do designate the latter. Someday when y'all revolt against me, you can all agree that lp:mailman is no longer the blessed master branch. Hey, that's FLOSS. But I still think that within a single branch, it's useful to have a main line of development, and I think that jives with most people's intuition about software development.
The really important concept I think is that merges are first class events on a particular branch, represented by their own single revision within the history. These merge revisions can be expanded for more detail, where all the gory details of its history are revealed, letting you choose to care or not care about it.
Having a main branch implies that the organization is imposing its idea of "the right way".
It is somewhat like the Corp of Engineers telling a river how it should travel through its delta region.
History shows that parts which once were considered "the main branch" often become byways as the momentum of the flow embraces new ideas, directions or leadership.
Most feature and bug fix branches are quite short lived. They rarely become the heads of long lived lines of development. There are other ways to handle the conventions that lead to more sweeping changes of focus, and I don't think there's much of a difference in how the dvcs's handle that. There may be ways in which the code hosting providers do better or worse ways of managing that, but it seems independent of the lower-level dvcs.
Cheers, -Barry
Hi,
Am 20.05.12 16:22, schrieb Richard Wackerbarth:
However, I am concerned that your implementation exposes "/postorius/" in the URLs and in the template names for the themes.
It doesn't - it's a simple configuration issue. The URL namespace for
Postorius is defined in the *project's* urls modules (in our case
dev_setup/urls.py), *not* in Postorius'.
You can easily change postorius to something else to define a
different namespace for all Postorius-URLs. You can also define
"postorius.urls" as the ROOT_URLCONF in your project to use no namespace
at all (this would of course only make sense for installation scenarios
where no url-collisions are expected, like a (sub)domain that serves
nothing but Postorius).
Remember that dev_setup is just an example django project that we put into trunk for convenience' sake during PyCon. It is not part of the Python-package that get's installed with Postorius. Although, as we discussed recently, dev_setup should be moved to a separate location.
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.
Quite the opposite. The whole idea of distributing postorius as a django *app* and not a django *project* aims at making it easily possible to integrate Postorius into existing scenarios. That's why the URL namespace isn't defined in the app-level urls module.
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.
Absolutely. Both scenarios should be (and are) possible. A stand-alone installation as well as integrated into an existing django-project.
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.
The URL namespace you choose for the Postorius URLs has no effect on the theme that is used. You could change the namespace to
(r'^googlegroups/', include('postorius.urls') # SCNR :-)and django would still look for a template folder with the name
postorius (both in your app as well as your project). So overriding
the app's theme (or just single templates) on the project level would
work just like with every other django app.
For instance, you could override Postorius' base.html on the project level to make it use your existing site's html/css layout.
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.
We already have a MAILMAN_THEME setting (set to 'default') which you could easily change to something else and add another theme folder to the templates/postorius folder. We did that exactly with the idea in mind to deliver more than one theme with the application.
However, I don't like the idea very much any more, because django already has a very good system to override existing themes, either through project-level overrides or through installing a "theme-only" app.
Florian
I believe that it may be your intention to have kept "postorius" hidden. But I don't think that the actual implementation has accomplished that.
Please see ~mailman-coders/postorius/trunk : /src/postorius/templates/postorius/base.html (revision 65) at lines 11 - 16
Clearly, this file is a part of the postorius app and not the dev_setup site.
And you seem to have missed my point in suggesting that we deliver two themes. I recognize that Django has a good mechanism for the implementation IF the user templates are written in a generic manner. However, all too often, in many projects, I find that the actual code written fails to adhere to the necessary standards and is therefore very difficult to port to an alternate implementation.
If we force ourselves to maintain two, significantly different, implementations, we are much more likely to remain within the design standards and thus have something that an end-user can readily customize for their own use.
Richard
On May 21, 2012, at 10:26 AM, Florian Fuchs wrote:
Hi,
Am 20.05.12 16:22, schrieb Richard Wackerbarth:
However, I am concerned that your implementation exposes "/postorius/" in the URLs and in the template names for the themes.
It doesn't - it's a simple configuration issue. The URL namespace for Postorius is defined in the *project's* urls modules (in our case
dev_setup/urls.py), *not* in Postorius'.
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.
We already have a MAILMAN_THEME setting (set to 'default') which you could easily change to something else and add another theme folder to the templates/postorius folder. We did that exactly with the idea in mind to deliver more than one theme with the application.
However, I don't like the idea very much any more, because django already has a very good system to override existing themes, either through project-level overrides or through installing a "theme-only" app.
Florian
Am 21.05.12 18:24, schrieb Richard Wackerbarth:
I believe that it may be your intention to have kept "postorius" hidden. But I don't think that the actual implementation has accomplished that.
Please see ~mailman-coders/postorius/trunk <http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/files/65/src/postorius/templates/postorius>/base.html (revision 65) at lines 11 - 16
If you are talking about the static file paths containing postorius I
don't see why we should break out of this very useful convention (or why
it should be contradictory to the goal to make postorius more customizable).
Having the app name hard-coded in static file paths is pretty common.
And for a good reason - for instance, if you use manage.py collectstatic - which has the sole purpose of making app assets
available within a <STATIC_URL>/<app_name>/... folder structure (and is
essential for serving static files effectively and hassle-free).
Do we want to be able to customize the namespace in page urls? Yes. Do we want to make it possible to override single postorius URLs (for instance if you just want to use the subsription page on your site)? Also yes. Those are basic django features and you can do that with Postorius, too.
But if you want postorius to use different asset paths IMHO the django way to do it would be to just override base.html. What we could do though (we already have your bug report for that) is optimize base.html's block structure a bit.
And you seem to have missed my point in suggesting that we deliver two themes. I recognize that Django has a good mechanism for the implementation IF the user templates are written in a generic manner. However, all too often, in many projects, I find that the actual code written fails to adhere to the necessary standards and is therefore very difficult to port to an alternate implementation.
I agree, the goal is to keep the markup in the sub-templates (the ones that extend base.html) as simple and generic as possible. In order for them to work well even with a very different override of base.html. I'm glad for every inconsitency you can find and report on that side (or even fix it!). I'm sure there are things we can do better. It's still alpha code after all.
Also, I'm very eager to clean-up the view code and add better testing at the moment. So we definitely can use some help with the templates.
If we force ourselves to maintain two, significantly different, implementations, we are much more likely to remain within the design standards and thus have something that an end-user can readily customize for their own use.
I agree - with the small exception that someone has to write that second theme... ;-)
Florian
Richard Wackerbarth writes:
I believe that it may be your intention to have kept "postorius" hidden. But I don't think that the actual implementation has accomplished that.
Please see ~mailman-coders/postorius/trunk : /src/postorius/templates/postorius/base.html (revision 65) at lines 11 - 16
Clearly, this file is a part of the postorius app and not the dev_setup site.
I don't understand your point. For better or worse, CSS is tied to the HTML it styles via id and class tags, and element nesting patterns. Another app for presenting list admin functions would have different HTML and different CSS. So a site which wishes to customize the appearance of postorius will need to add postorius-specific CSS anyway, which may as well be indicated by a path element in the URL.
Note that STATIC_URL is site-specific, and if you want to add the postorius theme code in a site-specific place, add that place to the STATICFILES_DIRS setting.
What am I missing?
A different question: what happens if MAILMAN_THEME is set to "foo", and postorius doesn't have a "foo" theme? I think it would be obnoxious to require all customizers to customize everything.
On May 21, 2012, at 8:33 PM, Stephen J. Turnbull wrote:
Richard Wackerbarth writes:
I believe that it may be your intention to have kept "postorius" hidden. But I don't think that the actual implementation has accomplished that.
Please see ~mailman-coders/postorius/trunk : /src/postorius/templates/postorius/base.html (revision 65) at lines 11 - 16
Clearly, this file is a part of the postorius app and not the dev_setup site.
I don't understand your point. For better or worse, CSS is tied to the HTML it styles via id and class tags, and element nesting patterns. Another app for presenting list admin functions would have different HTML and different CSS. So a site which wishes to customize the appearance of postorius will need to add postorius-specific CSS anyway, which may as well be indicated by a path element in the URL.
Yes, but one of the design points of Django is that, without a great deal of effort, the user can customize his site URLs in any manner. Further, doing so follows the DRY principle. Embedding the actual text stream "/postorius/" in templates, particularly multiple times, is a violation of this design.
Following the design, the user will specify the appropriate prefix for the subsystem dependent static files as a part of the settings. The default value will include "postorius". However, since most users view the GUI to be a part of the larger mailing list system, I could argue that "mailman" might be a better choice.
Note that STATIC_URL is site-specific, and if you want to add the postorius theme code in a site-specific place, add that place to the STATICFILES_DIRS setting.
STATICFILES_DIRS relates to the server-side storage of files. I am talking about the client-visible URLs used to reference them.
What am I missing?
You are also missing the fact that postorius is intended to be a subsystem within a larger website, As such, it should be obtaining its "boilerplate", including the basic page layout, navigation menu structure, css, etc. from the parent website. That website should not be expected to invert the hierarchy and use files within the postorius namespace for pages that have nothing to do with the administration of the mailing lists. Remember, we must assume that there also might be some other subsystem (such as an e-commerce storefront) that will coexist with the mailing list. We should assume that it would follow the same structural design. Since both of these subsystems cannot be the source of the essential boilerplate, we would have to force one of them to defer to the other. It is a poor design to create an artificial dependency between the two subsystems. Rather, both of the subsystems should defer to the main site since they are a subsection of it.
A different question: what happens if MAILMAN_THEME is set to "foo", and postorius doesn't have a "foo" theme? I think it would be obnoxious to require all customizers to customize everything.
I agree. However, I think that it is a mistake to build themes for the entire website into the postorius app itself. Using a theme app is a better design. Thus, "MAILMAN_THEME" would apply only to the specific content portion of the pages involving mailing list settings, etc. Since much of the "look and feel" for that content should be inherited from the surrounding page, I think it reasonable to require that the selected postorius theme components exist.
Richard
Am 22.05.12 13:14, schrieb Richard Wackerbarth:
On May 21, 2012, at 8:33 PM, Stephen J. Turnbull wrote:
I don't understand your point. For better or worse, CSS is tied to the HTML it styles via id and class tags, and element nesting patterns. Another app for presenting list admin functions would have different HTML and different CSS. So a site which wishes to customize the appearance of postorius will need to add postorius-specific CSS anyway, which may as well be indicated by a path element in the URL.
Yes, but one of the design points of Django is that, without a great deal of effort, the user can customize his site URLs in any manner. Further, doing so follows the DRY principle. Embedding the actual text stream "/postorius/" in templates, particularly multiple times, is a violation of this design.
Again: This is not generally true. It is true for hard-coded *page* URLs
in templates. One really should use the url template tag for this. So
*if* you find hard-coded *page* links in postorius, consider it a bug
that needs to be fixed.
But having the app name (in our case: the text stram "postorius") appear hard-coded in *static file* paths (CSS/JS etc.) in base.html is, in fact, a wide-spread and very useful Django convention. After all, the app's name is "postorius" and as such it is the reference point for Django, needed for template overrides and static file collection.
Even Django's own contrib apps handle it like this.
Following the design, the user will specify the appropriate prefix for the subsystem dependent static files as a part of the settings. The default value will include "postorius". However, since most users view the GUI to be a part of the larger mailing list system, I could argue that "mailman" might be a better choice.
A prefix is not the recommended approach any more. In fact the "admin_media_prefix" context variable in django's own contrib.admin app is now deprecated, because that's exactly what contrib.staticfiles/collectstatic and template overrides can do better.
If you'd like to have urls like "/mailman/lists/new" instead of "/postorius/lists/new", or even "/mailman/come/on/lets/add/a/list": Fine, you can do that. But if you want to use different static assets, you need to override the template.
You are also missing the fact that postorius is intended to be a subsystem within a larger website,
There is probably more than one opinion on what Postorius is intended to be. If you ask me, it is more than just that. A subsystem in an existing site, yes. But also a stand-alone mailing list management app that you might serve on a specific (sub)domain. And also (hopefully, in the future) part of a collection of other mailman-related django apps (although in that case, you could argue that it's a subsystem).
that it would follow the same structural design. Since both of these subsystems cannot be the source of the essential boilerplate, we would have to force one of them to defer to the other. It is a poor design to create an artificial dependency between the two subsystems. Rather, both of the subsystems should defer to the main site since they are a subsection of it.
I really like the idea of independent and easily pluggable apps. But it obviously has some downsides. I bet we're not the first ones argueing about the best way to plug different Django apps together. That's why I'd rather talk about how to find a "good solution" but about a "poor design".
A different question: what happens if MAILMAN_THEME is set to "foo", and postorius doesn't have a "foo" theme? I think it would be obnoxious to require all customizers to customize everything.
I agree. However, I think that it is a mistake to build themes for the entire website into the postorius app itself. Using a theme app is a better design.
See my reply to Steve's previous post...
Florian
On May 22, 2012, at 7:23 AM, Florian Fuchs wrote:
Am 22.05.12 13:14, schrieb Richard Wackerbarth:
On May 21, 2012, at 8:33 PM, Stephen J. Turnbull wrote:
I don't understand your point. For better or worse, CSS is tied to the HTML it styles via id and class tags, and element nesting patterns. Another app for presenting list admin functions would have different HTML and different CSS. So a site which wishes to customize the appearance of postorius will need to add postorius-specific CSS anyway, which may as well be indicated by a path element in the URL.
Yes, but one of the design points of Django is that, without a great deal of effort, the user can customize his site URLs in any manner. Further, doing so follows the DRY principle. Embedding the actual text stream "/postorius/" in templates, particularly multiple times, is a violation of this design.
Again: This is not generally true. It is true for hard-coded *page* URLs in templates.
But you are now making a distinction between assets based on their method of generation. Whether a file is .html , .css, or .js , django can generate it from templates. It is only for server efficiency that a distinction is made.
Further, unless the content is customized for the subsystem, I would argue that the asset should appear in a global namespace and not within the namespace of the subsystem. For example, it would be a poor practice to deliver content for ".../jquery-1.7.1.js" from within the subsystem which is different from that which was supplied by the vendor. Why, therefore, should ".../postorius/jquery-1.7.1.js" ever exist?
One really should use the
urltemplate tag for this. Equally, there SHOULD be an equivalent mechanism for the static content.
But having the app name (in our case: the text stream "postorius") appear hard-coded in *static file* paths (CSS/JS etc.) in base.html is, in fact, a wide-spread and very useful Django convention. Only because that was an expedient implementation to which most users do not object.
After all, the app's name is "postorius" and as such it is the reference point for Django, needed for template overrides and static file collection. As an internal name, I agree. However from an external view, I think that it is more confusing than helpful.
I also think that using the entire FQDN in the website URLs is a mistake. (I have no problem with them in the REST interface) There are three obvious use cases. I believe that the most common usage will be the middle one. Case 1) One website serves mailing lists from multiple email domains. Here, we need to specify both the list name and the domain in each get request in order to be able to handle duplicated list names in separate email domains. Case 2) The website serves multiple mailing lists, all from the same email domain. Here, the email domain need not be a part of the URL because it is implied by the website domain. The django view handling the transaction should supply the email domain for processing purposes. Case 3) The website serves only a single mailing list. Here the django view can supply both the list name and the email domain.
Actually, the urlpattern mechanism should be capable of parsing the different URL cases and a single view can handle all three cases. So, we could supply the includable url patterns for each case and the installer could activate the appropriate one.
A prefix is not the recommended approach any more. In fact the "admin_media_prefix" context variable in django's own contrib.admin app is now deprecated, because that's exactly what contrib.staticfiles/collectstatic and template overrides can do better.
Actually, I think that "media" was intended to be for uploaded content, "static" is for invariant install-time content, and templates are for generated upon request content.
You are also missing the fact that postorius is intended to be a subsystem within a larger website,
There is probably more than one opinion on what Postorius is intended to be. If you ask me, it is more than just that. A subsystem in an existing site, yes. But also a stand-alone mailing list management app that you might serve on a specific (sub)domain.
But, that is just a special case of a trivial master site of which the postorious administration interface, and quite likely a mail archive interface are the only subsystems.
Richard Wackerbarth writes:
Yes, but one of the design points of Django is that, without a great deal of effort, the user can customize his site URLs in any manner. Further, doing so follows the DRY principle. Embedding the actual text stream "/postorius/" in templates, particularly multiple times, is a violation of this design.
Following the design, the user will specify the appropriate prefix for the subsystem dependent static files as a part of the settings. The default value will include "postorius". However, since most users view the GUI to be a part of the larger mailing list system, I could argue that "mailman" might be a better choice.
I can't speak to the "multiple times" issue (it does sound like a violation of DRY), but after arguing vehemently for multiple themes, you now seem to be mistaking Postorius for a unique part of Mailman (core). It's not. One could even imagine us sharing a site and you insist on using Postorius for your admin duties while I prefer CeterisAdmin, and having both installed. Postorius-specific components of a theme will need to be in a Postorius-specific namespace.
Note that STATIC_URL is site-specific, and if you want to add the postorius theme code in a site-specific place, add that place to the STATICFILES_DIRS setting.
STATICFILES_DIRS relates to the server-side storage of files. I am talking about the client-visible URLs used to reference them.
What am I missing?
You are also missing the fact that postorius is intended to be a subsystem within a larger website, As such, it should be obtaining its "boilerplate", including the basic page layout, navigation menu structure, css, etc. from the parent website.
I'm beginning to see your point, and I think I'm going to stay far away from it (and most especially not devote any implementation effort to it). AIUI, Mailman itself doesn't currently provide a website (although maybe it should, limited to the purpose of providing a common framework for inserting Mailman-related apps into a larger web site), and who knows what a "larger website" might provide. So I don't see how to implement that requirement.
That website should not be expected to invert the hierarchy and use files within the postorius namespace for pages that have nothing to do with the administration of the mailing lists.
Why would it do that anyway? (I concede your jquery example, but I don't think that would be hard to fix up. The base template and base CSS are hairballs OTOH.) What I would expect is a (hopefully minor) violation of DRY:
- Designer designs Big Web Site.
- Admin installs Mailman and Postorius.
- Designer adds BigWebSite theme to Postorius (not a problem for Postorius-specific aspects)
- including a BigWebSite base template and CSS (DRY violation!)
- Admin sets MAILMAN_THEME to "BigWebSite".
Sure, I'd love to say "Postorius will inherit from the Big Web Site, so we can omit 4", but I don't think we can.
We should assume that it would follow the same structural design.
I disagree. Postorius is being built so we can throw it away. If we're real lucky, maybe we won't have to, and if it's sufficiently modular, maybe we can get away with only redoing the base template or something like that. But trying to make it all things to all Big Web Sites now is imposing a huge burden on the Postorius implementers, because it's almost certain they will get it wrong for some Big Web Sites. Let's leave them to do what they can get right.
Also, Postorius is an admin function, with complex internal navigation needs. I could see trying to make the user interface for managing one's subscriptions conformant to a larger design, but the list and site admins are necessarily going to see a Postorius-specific navigation scheme. It might be artistically better to leave that entirely up to Postorius.
dependency between the two subsystems. Rather, both of the subsystems should defer to the main site since they are a subsection of it.
That would be OK if we had a specification of "main site" (specifically how themes and navigation are implemented). Do we? I don't see one (I don't even see reason to suppose it will be implemented in Django!), but I may be missing something (I'm not a web designer).
Am 22.05.12 03:33, schrieb Stephen J. Turnbull:
A different question: what happens if MAILMAN_THEME is set to "foo", and postorius doesn't have a "foo" theme? I think it would be obnoxious to require all customizers to customize everything.
That's why I'd like to get rid of the MAILMAN_THEME setting rather sooner than later. It seemed like a good idea at the time, but that was in Django 1.2 days. Since 1.3 (with the introduction of contrib.staticfiles) there's no benefit in doing it like this any more.
If you ask me, Postorius should ship with a default theme and make alternatives available as installable "theme-only" apps. If a theme is available on pypi it takes about two command line actions and one change to your settings to install a new theme.
Florian
participants (5)
-
Barry Warsaw -
Florian Fuchs -
Richard Wackerbarth -
Richard Wackerbarth
-
Stephen J. Turnbull