I think one problem, considering the current votes, is that it's really difficult to test anything. Releasing api bundles with no implementation to test is definitely not helping imo. Holly, just a question: is there a specific reason why are you doing the release in multiple votes ? It would be simpler to just release everything in one go and wait for a longer time because there are more things to check, or at least, release the api + implementation so that we can actually try something. Just my 2 cents.
On Mon, Jun 25, 2012 at 8:07 PM, Daniel Kulp <[email protected]> wrote: > > Honestly, with the change to using Nexus, the SHA1 and MD5 checks are > completely pointless. Nexus generates them itself based on what's > uploaded. The "is it a valid signature" part of the GPG testing is also > pointless as Nexus won't let you close the repo unless the signatures are > valid. The only check you really need to do is to make sure the key that > was used is "trusted" by you. (aka: was it really Holly who deployed those > artifacts) So the monontonous parts of checking that stuff is really > irrelevant at this point. (providing we trust that infra has Nexus > sufficiently locked down and secure) > > > I actually don't have a big issue with the difficulting in getting votes. > I'm involved in another community that has a PMC that is easily 4 times the > size of this one, yet we still have difficulting getting votes there. > While not ideal, life events can cause priority shifts and such so people > may not be able to be as responsive. > > My bigger problem is that the entire per bundle release process and symantic > versioning crap has put a HUGE burden on the release manager. That makes > it much harder to get quality releases out and makes it less likely that > anyone will step up to get "minor fixes" released. The only reason I > stepped up with the 0.3.1 bp stuff is that *MY* customers are being > affected by it. Like wise for the proxy stuff. If *my* customers were > not affected, I don't think I would have spent the time and effort. If > the process for getting fixes and releases out to users was smaller and > easier, I have no problem doing them. For CXF, we do full releases on 3 > branches every other month or so. But that's because it's EASY to do. > > If it was up to me, I'd toss out the entire versioning thing with 1.0 and go > back to per module versioning thing. So my fix to proxy would have > involved checking out all of "proxy", fixing it, and releasing all of proxy > as a proxy "0.3.1", even the modules that haven't changed. It's just a > huge hassle to track down which bundles have changed, which haven't which > version numbers need to be updated, etc.... If it's not quick and easy to > do releases as a release manager, very few people are going to step up to do > it. It may not be 100% "proper OSGi", but IMO, getting fixes and such to > the users is more important than that. But that's my opinion. > > > Dan > > > > On Saturday, June 23, 2012 03:27:07 PM Holly Cummins wrote: >> Hi all, >> >> Now that Jeremy's taken the time to write up our release verification >> process, I'd like to propose we change it. :) I think it's too onerous >> on the pmc, which therefore also inhibits our ability to be responsive >> to our users. >> >> >> ------------------------------- Why what we have isn't working for the >> community ------------------------------- >> >> I believe our users would like more frequent releases. We've had >> several keen requests and tweets and comments on the aries-user >> mailing list wishing we'd release more often. For example: >> >> * "Desperately waiting for an Aries release after loooong time.." >> * "The problem with Aries is they seem to be too busy coding to >> release anything." >> * "Compared to other projects (like Karaf and Camel) Aries releases >> tend to take quite some time." >> * "It's 2012 now and Aries 0.3 is almost a year old. Is there any >> chance of a new Aries JPA release any time soon? " >> * "Looks like Apache Aries has made no visible progress since Jan >> 2011, if the time stamps on the maven central artefacts are to be >> believed." >> >> ------------------------------- Why what we have isn't working for us >> ------------------------------- >> >> Both Dan and I are trying to do releases at the moment, and struggling >> to get enough PMC votes. Dan's release is to back port a show-stopper >> proxy fix, so a release there is particularly pressing - he's got a >> non-binding +infinity vote, but that's all. My test support release >> vote has been open for about 64 hours, and only got one vote so far >> (thanks David B!). Obviously testsupport is less exciting than proxy, >> but that bundle does block more interesting releases. >> >> Why aren't people voting? My guess is that it's too much work to do >> the full set of verifications described at >> http://aries.apache.org/development/verifyingrelease.html. There are >> seven steps, and while they don't actually take that long to complete, >> it's enough of a burden that we tend to leave the voting to someone >> else unless we really care about a release. I'm as guilty of this as >> anyone - I think a release is a good idea, but I'm spending enough >> time working on the 1.0.0 release that I don't want to take time out >> to vote on another release. I suspect Dan might feel exactly the same >> about my 1.0.0 bundles. :) >> >> With release-by-bundle, there's a lot of verifications. Excluding the >> sandbox code, we have 123 bundles to release in 1.0.0. At three votes >> per bundle, that means the PMC need to do 369 MD5 checks, 369 PGP >> checks, 369 RAT checks, and so on, just to get 1.0.0 out the door. >> This just doesn't seem like it scales. Batching the bundle releases >> together eases some of this burden, but not all. >> >> ------------------------------- What I propose >> ------------------------------- >> >> I suggest we move to a more trust-based system, where PMC members >> carefully check releases if they want, but where in general they're >> voting on the principle of the release, rather than the mechanics of >> the archives. In particular, they don't feel compelled to do checks >> before voting. If PMC members could say "Our users need this function, >> so +1", or "I know Holly has done sensible things in the past, so +1" >> or even "Do I want to check the SHAs on a test support bundle? Really? >> +1" it would get our releases moving better, and also save work for >> all of us. >> >> (At the moment I think what's happening is people are thinking "Do I >> want to check the SHAs on a test support bundle? Really?" and then >> skipping the +1 bit. :) ) >> >> To ensure that at least *someone* has run the checks, the release >> manager could include the output of the seven checks in an email to >> the list. I think this level of checking is perfectly compatible with >> the minimum Apache process, which is that the release manager signs >> the artefacts and three PMC members vote +1 >> (http://www.apache.org/dev/release-publishing.html#voted). >> >> What do people think? >> >> Holly > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
