Wendy, Thanks for taking the time for all that stuff. Thanks for the additional explanation. If the separation is an approvement for all people using atom feeds: so much the better. There was no veto yet (only symbolic -0's), so please proceed like you originally planned. --Manfred
On 5/15/07, Wendy Smoak <[EMAIL PROTECTED]> wrote:
On 5/14/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > I am -0 on placing Continuum messages on a different mailing list > > because I like seeing the commit message(s) followed by a Continuum > > success/failure message. The Continuum message is a nice confirmation > > that the commit(s) did or did not break the build. Email clients can > > be configured to filter messages if the user prefers to not see the > > Continuum message or see the message in a different folder. The > > converse can also be said, filtering commit and Continuum messages > > into the same folder. > Yep, these are my thoughts too. > > When Continuum is running stable I really prefer its messages showing up > after the commit. Even a newbie developer should see that every commit > triggers an (nearly) immediate action. > In the end every developer should subscribe to the continuum > notification list too ... so no need to split them. Somehow, I feel the need to restate my case. :) People who want to see commits and notifications right next to each other should absolutely have that option. And you will, just filter both lists into the same folder (or give them the same tag.) And active developers should certainly be watching both commits and notifications. Howver, _how_ you watch them should be up to you -- the Atom feed on the official archives is a great resource, as are Nabble forums. Separate streams of information can be combined and consumed in whatever way makes sense for you, personally. Also _whether_ you watch both of them should be up to the reader. Not everyone who reads the commits list is a developer. One of the reasons I argue for descriptive commit messages is that I learn a great deal from reading code and understanding what the change was meant to do. I do this for projects I'm only a casual user of. At that level, notifications are just noise -- soon enough, I'll see the next commit with the correction and another explanation. So, carry on... -- Wendy
-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
