On 11/30/05, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Phil Steitz wrote: > > For me +1 means pretty much what Martin describes above. I check the > > release contents, make sure required elements are there and in jars, > > make sure there is nothing funny included. I test the builds, > > validate sigs, etc and inspect the web site and, if present, > > clirr/jdiff and look carefully at the release notes. I also review > > the javadoc, maven reports and POM. I do try to learn a little more > > with each release that I review; > Thats true, I'll learn with every release review too, but can do this > only if another one complains about this and that. > If I read the stuff you do to check a release I am shocked, damn much > work to do. > > At least one of you "release checkers" ;-) should setup a wiki to > describe every step to do, this helps the release manager and those > checking it. > Especially if you are a newbie in the release cycle it might be a great > start AND it defines standards.
That was the intention of the releases pages: http://jakarta.apache.org/commons/releases/index.html When I get out from under water, I will add a final "checklist" type section, or someone else can. That is a good idea. > One thing which drives me crazy is that I dont know what to do to make a > project ready for a release. > I have to wait if anyone complains on an RC and even then, in case of > [vfs] the real release blocker were uncovered while voting for 1.0 - > after we have had a couple of month one RC after another! I agree that this is frustrating and don't have a great answer. See comments at end below. The same thing just happened to me in [math]. After a couple of RCs a major issue that was really a problem with 1.0 was raised and it took a while to get it fixed. To me, this is a consequence of not wanting to release with significant known issues, which is sort of an unwritten rule which we tend to follow in commons. See Martin's response below on "fix later". My view, shared by (I think) most others is that there has to be a very good reason to do that. At least on the components that I have worked on (see list below), we tend to get the real issues closed before release and to stop releases when they show up during the vote or RC testing. > And e.g. we started to discuss if we have to convert line-endings - > after years (!) of commons releases - and we were not able to have a > vital discussion about this little topic. In the "old days" we kept lf line endings on all the source files in cvs and hand-rolled ant scripts were used to put crlf on the .txt files in the zips. Between maven and svn's eol=native, that is no longer possible or at least immediate. The real question (see other response) is do we care about this? From lack of response to [poll] thread, could be the answer is no. > > These are really demotivating things! > Agreed and sorry if we seem to be making things harder rather than easier. Patches - or direct commits to - the releases page and any other suggestions to make things easier are most welcome. > One other comment that I have on the issue of voting on releases is that the core problem here is lack of component-committed volunteers, IMHO. I remember a couple of years back when we discussed whose votes were binding on component releases. Hen made the interesting comment that he felt that committers not working on the component should vote and their votes were as important / even more important than those of the project team. We have now devolved to the point where without these votes, we will in some cases not be able to get 3 binding +1's. This is not good. Somehow we have to reengage as Rahul pointed out at the top of this thread. It might be a good idea for each of us to take stock of the components that we can really +1 releases for (in Neil's sense) and then see where the gaps are. By "us" I mean the whole community. Anyone who is willing to review releases, respond to bug reports, answer user questions, submit patches, or improve docs is encouraged to step up. We need help! I will start. All I can really support right now are [math], [lang], [collections] in commons proper and [id] in sandbox. One day when I have more time and courage, I would like to jump into [beanutils] to help save it from drowning under unresolved bugs and both [functor] and [graph2] in the sandbox (possibly absorbing one or both into [math]), but for now the four above are all I can really stay on top of. To record this kind of info, we might add a list of active volunteers to the Wiki page for each component. Does this sound like a good idea? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
