Leo Simons wrote:
Vadim Gritsenko wrote:
Leo Simons wrote:
On 24-08-2005 01:27, "Vadim Gritsenko" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
