commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [all] Together, and bricks apart
Date Fri, 02 Dec 2005 08:55:26 GMT
On 11/30/05, Mario Ivankovits <mario@ops.co.at> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message