excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: One more change to be included into the release...
Date Wed, 24 Aug 2005 22:58:08 GMT
Leo Simons wrote:
> Vadim Gritsenko wrote:
> 
>>Leo Simons wrote:
>>
>>>On 24-08-2005 01:27, "Vadim Gritsenko" <vadim@reverycodes.com> wrote:
>>>
>>>>is no reason to do yet another RC build just because of it :-) because
>>>>it is simple addition which does not alter any existing behavior.
>>>
>>>-1 on such a process. There should be *no* difference between the RC
>>>that is voted on and what is eventually released. Take this seriously!
>>
>><vent>
>>Give me a break!
> 
> Sorry Vadim, but no. You should be giving the release manager a break
> and not put pressure on him to keep including changes into a release
> near the end of a several-week release process. Its bad form and wastes
> everyone's time.

Hey, I never meant to add a burden to the heroic person we have for a release 
manager right now! Only if suggested something which is "that's not the way we 
do it here" (tm).


> The problem you brought up has existed for years and there have been
> many years to fix it. I understand it is a new problem for you and
> you're burning to fix it now,

It's fixed for me, right now; only question was, does it make sense to include 
it in this release round or not. Including in the next release is good enough 
for me. I'm cool.

<snip/>

> If you want a release that includes your fix you can volunteer to build
> it and put on the release manager hat. That would be very healthy for
> this community.

Can't volunteer for this now - was planning to do release of another project 
first...


> Having releases once every so often (with often << year)
> is good. We're not going to get to such a point if every release cycle
> takes rediculously long.

+1 to that.


>>PMC can release whatever it wants as long as what is
>>had released matches with what it had voted upon to release!
> 
> Yes, if you define "matches" as "same MD5 signature". No, otherwise.

You are not correct. PMC decides how it will do business. It can decide that 
'matches' means source code. If that PMC requires matching MD5 sigs of 
zip/tar.gz release, so be it (even though I might not agree with it and complain 
about it :P ).

But - note that your MD5 sigs won't match with final release anyway - for 
example because of different entries in the Manifest (version: 1.2.3 rc5 changes 
to version: 1.2.3 giving different MD5).


>>If PMC
>>voted to release "SVN r239620", it might or might not match any of the
>>previous (RC or Beta or Alpha or Milestone) releases.

(completing the sentence) ... and that is not a problem: rc3 release is not the 
same as final release, so it is different vote, and different release.


> Indeed, which is why we won't.

As long as SVN r239620 is SVN r239620, release made out of it is the same 
release. If you 'svn cp' r239620 today or tomorrow, you still get same result, 
always. Does not matter how many other releases do you have (m1, m2, ... mn, a1, 
a2, ... an, b1, b2, ... bn, rc1, rc2, ... rcn). Also does not matter how you 
name your releases (alpha, beta, gamma, ...).

Point is,
   * You have to uniquely and reproducably identify what you
     are releasing (1)
   * You have to give it a name


>>Moreover, one might argue there is no point in enforcing RCn == Final
>>policy as it lacks common sense.
> 
> Oh c'mon. "common sense" is what led to a solid and verifiable and
> documented and repeatable release process in the first place.

Yep, see (1) above.


>>And in addition to this, RCn is already
>>out there anyway and re-releasing it is waste of bandwidth.
>></vent>
> 
> Heh. There is a transformation process between an SVN revision and a
> distribution that is manual, non-trivial, environment-dependent, and
> fragile.

So it makes most sense than for each developer to repeat the process and compare 
results - that is, if you want to transform it into something more stable.


> It is because of this that we have things like releases and
> release candidates.

This PMC, might be. Most others don't do this, hence I, as unfamiliar with 
practice, got confused.


> Otherwise we could just have gump or some other
> build bot autopublish all the stuff it compiles and save ourselves a
> whole lot of work.

I imagine some folks from 'release early, release often' would love to just do 
that, if not already doing. Write a cron job, schedule it to execute each 3 
month, and announce code freeze week or two before that. Good process for lively 
maintenance branch which gets patched regularly, especially if there are 
automated nightly tests. And if you put on top of that requirement to add a test 
for each bug found... This will produce good releases.


> These processes weren't invented because there's a bunch of really
> strange people that totally lack common sense and for some odd reason
> love fiddling with bits and bytes and votes and showing off authority or
> anything like that. They exist because of all the experiences we've had
> with f****d up releases causing nasty problems for years.

This gives background why this PMC had chosen such process. Thanks. I wonder 
what was primary cause of problematic releases - was it issues with jar files in 
repository, difference in version of build tool, difference in plugins / addons 
/ jars to the build tool... Makes me want to commit maven repository into the 
SVN - in order to achieve (1) above...


>>But, whatever - it's your PMC.
> 
> Not really, I'm just one of many. In fact, our PMC is also just one of
> many. We are a part of the ASF and as such we have a shared
> responsibility towards all of its users and developers to uphold
> extremely high quality standards.

Notice though that this would not be a top and foremost goal of ASF. It might be 
a by-product of achieving other ASF goals (such as strong communities), or some 
third or fourth level goal, but not a top goal in and by itself. Moreover, some 
senior ;-) member of the community would argue that in order to achieve high 
quality software sometimes all you need to do is to push out a release with bugs 
in it :-)


> The "Official ASF release" stamp is a
> rather big one and its not to be waved around or toyed with.

Leo, relax. Take off your tie and 3 piece suite, put jeans and t-shirt on. :-)

Vadim

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


Mime
View raw message