+1 Related to the (non-functional) reasons not to release, I'm sure there may be a few. I can also understand the reasoning behind aiming for a perfect release. On the other hand, we have to take stock of the fact that this release process has been ongoing for a while now, and a perfect first release will postpone things more. Doing this release now rather then later, especially after years of 0.1, will preserve the existing momentum and will provide the experience necessary to do a better 0.2 release, of course assuming the minimal Apache standards are being met and the release goes forward. It will also allow 0.2 work to continue, which is the whole point. No, the release will not be as good as it would be if another month of careful work and cleanup goes into it, but at the end of the day it will be hugely better than no release at all. Release early release often indeed. Eugen.
On Thu, May 19, 2011 at 7:31 PM, Ross Gardler <[email protected]> wrote: > -1 for the reasons already given > > Sent from my mobile device (so please excuse typos) > > On 19 May 2011, at 16:31, Richard Frovarp <[email protected]> wrote: > > > On 05/19/2011 04:28 AM, Thorsten Scherler wrote: > >> On Thu, 2011-05-12 at 18:03 -0500, Richard Frovarp wrote: > >>> On 05/12/2011 03:30 PM, Richard Frovarp wrote: > >>>> A 0.1-incubating release candidate has been created, with the > following > >>>> artifacts up for a vote: > >>>> > >>>> SVN source tag (r1100814): > >>>> > https://svn.apache.org/repos/asf/incubator/droids/tags/0.1-incubating/ > >>>> > >>>> Maven staging repo: > >>>> > https://repository.apache.org/content/repositories/orgapachedroids-031/ > >>>> > >>>> Source release: > >>>> > https://repository.apache.org/content/repositories/orgapachedroids-031/org/apache/droids/droids/0.1-incubating/droids-0.1-incubating-source-release.zip > >>>> > >>>> > >>>> > >>>> PGP release keys (signed using D1323BDA): > >>>> https://svn.apache.org/repos/asf/incubator/droids/KEYS > >>>> > >>>> > >>>> Vote will be open for 7 days. > >>>> > >>>> [ ] +1 approve > >>>> [ ] +0 no opinion > >>>> [ ] -1 disapprove (and reason why) > >>> > >>> -1 > >>> > >>> Looking through this, I'm starting to see problems with the release. > >>> > >>> 1) My svn threw extra crap into the source release that shouldn't be > there. > >>> 2) A couple of files are missing headers > >>> 3) Not all of the NOTICE files are complete > >>> 4) We really should pull everything that isn't referenced in our top > >>> pom.xml out of that spot in SVN to create a clean source release. That > >>> might help with problems #2& #3. > >>> > >>> What do others think? I'm going to work on these issues tonight. It > >>> won't change the code, but would change the release artifacts for the > >>> next release / release attempt. > >> > >> I tried the code and it works fine for me. Regarding the points you > >> mentioned if they do not change the functional integrity then I say we > >> fix them and do another release. However here my +1 for the functional > >> part. > >> > >> salu2 > > > > Yes, they don't change the functional part at all. However, this has to > be sent to the IPMC for approval, and they'll probably send the release back > down to us due to these issues. I can prepare a cleaned up release this > weekend. How long of a vote do we want for that one? >
