Hey all, I don't see any particular advantages/disadvantages to any of the options if you are using a mail client that supports filters.
But, for the sake of keeping list archives clean - I would lean toward using the commit@ list. Anyone who is a committer should be subscribed and most casual (non-dev) users will not be. But it might make sense to put this subject onto its own discuss/vote threads rather than continuing to hijack this one. Jay Joe Bohn wrote: > Jeremy Hughes wrote: >> 2009/9/30 Daniel Kulp <[email protected]>: >>> One more issue.. >>> >>> I did NOT turn on the email notifications yet. Do we want them and >>> where >>> should they be sent? >> >> What notifications get sent ... all failures presumably, all successes >> too? I guess it's configurable. >> I looked at >> http://mail-archives.apache.org/mod_mbox/cxf-notifications/200909.mbox/browser >> >> and yikes! there's some non ASCII in the subject. >> >>> There are basically three schools of thought: >>> >>> 1) A dedicated notifications@ list. A couple projects (like CXF) >>> use this >>> approach. If you are interested, subscribe. If not, don't. (note: >>> the >>> people committing changes contributing to a build also get an email on >>> failures) >>> >> >> +1 >> >>> 2) dev@ Some projects use this as all developers should know if >>> builds are >>> failing. Then again, some people think it pollutes/dilutes the >>> value of the >>> dev list. >> >> -1 not good for encouraging non-committers to subscribe to aries-dev >> >>> 3) commits@ Since builds are informational similar to the commits, >>> put all >>> such notices together. >> >> -0 don't you have to subscribe to this using an apache id? It would be >> good if non-committers can see the notifications if they like, but not >> a problem if they can't - they just have to take a look at the CI >> machine > > You don't need an apache id to subscribe. It is just recommended that if > you are making commits that you subscribe using your apache id so that > commit notifications sent from your apache id are not rejected by the > list. I personally think #3 is a good compromise - keeping the dev list > clean and sending the build messages in relative order with the commit > messages. > >> >>> Thoughts? >>> Dan >>> >>> >>> >>> On Wed September 30 2009 9:13:17 am Daniel Kulp wrote: >>>> I setup a basic build (on checkin) and a deploy build (once a day if >>>> changes) to deploy snapshots. >>>> >>>> http://hudson.zones.apache.org/hudson/view/Aries/ >>>> >>>> >>>> In both cases, I used Maven 2.2.1 and Java 6. Are people OK with that? >>>> Should we also setup a Java 5 build? >>>> >>>> Dan >>>> >>>> On Wed September 30 2009 9:02:22 am Jeremy Hughes wrote: >>>>> 2009/9/30 Daniel Kulp <[email protected]>: >>>>>> http://hudson.zones.apache.org/hudson/ >>>>> Nice that the tabs are alphabetically organised - I won't have to page >>>>> right to get to Aries :-) >>>>> >>>>>> In anycase, I'll setup a build. >>>>> Thanks! >>>>> >>>>>> Dan >>>>>> >>>>>> On Wed September 30 2009 8:46:07 am Jeremy Hughes wrote: >>>>>>> I'm curious about Hudson. I've not used it before. What are the >>>>>>> advantages over continuum, which admittedly is something I'm more >>>>>>> used >>>>>>> to. There is an instance of continuum at vmbuild.apache.org which we >>>>>>> could potentially use. I just looked at hudson.dev.java.net ... is >>>>>>> there an instance of it running in the apache.org domain or are you >>>>>>> suggesting we build at java.net? >>>>>>> >>>>>>> Jeremy >>>>>>> >>>>>>> 2009/9/30 David Bosschaert <[email protected]>: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I've just committed the parent pom structure and updated the >>>>>>>> Blueprint component to use it. >>>>>>>> You can now run 'mvn install' from the Aries trunk to build >>>>>>>> everything (which currently is just blueprint :). >>>>>>>> >>>>>>>> I guess this would be enough to get a Hudson build going... Anyone >>>>>>>> with the right credentials there fancy setting it up? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> David >>>>>> -- >>>>>> Daniel Kulp >>>>>> [email protected] >>>>>> http://www.dankulp.com/blog >>> -- >>> Daniel Kulp >>> [email protected] >>> http://www.dankulp.com/blog >>> >> > >
