On Apr 4, 2007, at 4:09 PM, Martijn Dashorst wrote:
On 4/4/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
If there have been changes since the release was cut, a new release
must IMHO be created, so that people can vote (on the wicket lists
first, and then come back here) on the correct one.
Like Gwyn said, we'd rather wait until *all* feedback is delivered,
before starting a spam action on this list to get the release vetted.
Nothing wrong with that approach.
Given the lack of time of one of the most trustworthy IPMC members,
this checking takes longer than expected, but we are willing to wait
(not too long, mind you) until we get more feedback.
Yeah there's a bit of an issue here. Vetting releases isn't exactly
fun or easy work to do, and sometimes it can be quite a lot of work
too. Robert deserves a medal, but that's still not a sustainable
workflow.
Also, I'm not too convinced of the "release that is not meant for
public consumption" thing - according to the ASF's definition,
binaries do not constitute a release unless they're meant for public
consumption.
This is not what (most) of the mentors and IPMC members here have
voiced in the past.
Yeah, we know, we sort-of suck at communicating these things
consistently. It stems from misunderstandings of what our legal
processes are and how things are meant to work. Every now and then
someone who has some more understanding of the legal bits joins in
some discussion to correct some of the understanding of some of the
IPMC, and then the focus of some of the communication changes.
Recently Roy re-explained some of this.
In order to graduate, a podling is required to
build a release, if only it is a developer only release (take the
harmony podling as an example).
I'm not convinced we actually say (or have always consistently said)
"REQUIRED to build a release". IIRC Apache Directory might have
graduated without building a release.
(...)
The incubator has not liked its own release process and rules for a
while, which I guess is why they keep changing. It's apparently just
really hard to come up with better processes.
Rest assured, I believe wicket's right on track and doing this "get
the legal bits reviewed and then do a 'real' release" is a fine idea.
I know you have users waiting for a final release. (given we're
running something called wicket-1.3-incubating-r492460-p12.jar in
production over here!)
There's just this one little tidbit - if the IPMC votes to *release*
something, that something should then actually be released. "Release"
has a specific meaning and we (have to) do "distribution at no charge
to the general public" of them. I guess it's all in a name.
The alternative is to *not* release something, and then there should
not be a release vote, but a different kind of vote, or no vote at all.
A release can be called wicket-incubating-DO_NOT_USE_THIS_CODE-this-
is-a-legal-reasons-only-release-1.3.0-alpha.zip and we can take care
to not publicize that we release things, but if it is a release, it
still needs to be distributed to the general public. And then after
that we can pull the release so it exists only on archive.apache.org.
If we don't do it that way we all get very confused.
Yes, that does mean that what we did process-wise with the ofbiz
snapshot release
http://marc.info/?l=incubator-general&m=116319350715033&w=2
was a bit wrong. *shrug*. Seems we did it right wth the harmony
snapshot releases though.
cheers,
Leo
--
Meet me for beer at ApacheCon Europe: http://apachecon.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
