lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: [Lucene-java Wiki] Trivial Update of "ReleaseTodo" by YonikSeeley
Date Wed, 22 Sep 2010 00:34:57 GMT

: correct me if I'm wrong) to presume that you are saying that it is 
: alright for the RM to decide what artifacts should be released.  So, if 
: that's not the case, then fine, I agree, but if it is, then no, I don't 
: think this is the right message to put on the page.  And it certainly 

I haven't seen anyone even remotely claim that.  the The RM most certainly 
gets to decide what *they* think should be released -- but it is the PMC 
that gets to decide what *will* be released, and the PMC decides by voting 
on it.

RM is just a label for someone who posts a file online somewhere, signs 
it, and calls a vote -- they don't have to be a commiter, they don't have 
to be a PMC member, they don't have to be building off of any specific 
branch, they don't have to organize their files in any particular way -- 
all that matters is that they say "here's some stuff, i think we should 
release it as Apache Foooooo 4.5.6.3.121_a" and it's up to the PMC to say 
"we're not ging to vote in favor of releasing that, it's just a zip file 
containing a foo.java file thta doesn't compile because it's just an 
ascii art picture of a monkey."

It's largely meaningless to try and argue that there should be a hard and 
fast formally voted on process for how we do a release, because a 
volunteer release manager can't be legally bound to follow that process -- 
they can just say "screw you guys, this is a pain in the ass i'm going 
home to do something fun with my time".  

It's likewise largely meaningless to try and argue that there should be a 
hard and fast formally voted on set of requirements for what must 
constitute a release candidate -- because no matter what the PMC might 
vote on as far as what those rules should be, they would be irrelevant 
once an actual release vote was called (ie: if PMC feels that all releases 
need to include a picture of a monkey, you don't need to vote on that as a 
formal rule - you just need to vote against any release that doesn't 
include a picture of a monkey)

Instead of spending a lot of time arguing over what type of formal process 
should be involved, and what is mandatory or not, and how to make 
mandatory things formally mandatory, etc....  it would probably be more 
productive if folks who have strong opinions about what is important to 
produce as part of a release just focused on making it easier to do 
releases that produce those things.

For example...

Robert feels strongly that releases should always be well tested for many 
langauges/locales/jvms (+1), so he's been working his ass off to 
contribute patches that make sure we have an automated way to test these 
things so we don't have to think hard about them at release time. (++1)

If other people feel like releases should always have rock solid support 
for maven users to consume release artifacts that have accurate poms, then 
they should contribute patches that make sure we have an automated way to 
generate/publish those artifacts so we don't have to think hard about them 
at release time.

Likewise: If i feel like releases should always include a picture of a 
monkey holding the New York times on the day the release is made, then i 
should contribute a patch that causes the build to generate a picture of a 
monkey holding the new york times automaticly when the build is run, so we 
don't have to remember to do it at release time.

If any of the various goals conflict (ie: if grant doesn't want to vote in 
favor of a release because my picture of a monkey doesn't have a pom so 
it's not useable for maven users; or if robert doesn't want to vote in 
favor of a release that includes pom's because there are no tests 
verifying that those poms are usable) then let's argue about those 
specific, individual, seperate, points in a way that leads towards patches 
and automation and simplification of process -- Let's try to avoid arguing 
about formal rules and regulations that just lead to us having formal 
rules and regulations with no actual implementation or technical solution 
to make those rules/regulations a reality.


-Hoss

--
http://lucenerevolution.org/  ...  October 7-8, Boston
http://bit.ly/stump-hoss      ...  Stump The Chump!


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message