Hi folks,
congratulation for getting the release out of the door ... :-) ... and
shiro folks (aka JSecurity) did an excellent job.
Regarding the "no-frills step-by-step, no room-for-error release"
+) it is difficult to write
+) different projects have different tools to release (manual, Ant,
Maven) making the stuff even more difficult
Maybe more stuff can be done to streamline your release process using M2
- maybe I can lend you a hand
Cheers,
Siegfried Goeschl
On 01.06.10 22:26, Les Hazlewood wrote:
The download page links to reposity.apache.org.
However repository.apache.org is not to be used for direct
publication to end users, it is for publishing to the main maven repo.
This wasn't clear on the apache infrastructure page - it states that
repository.apache.org is part of the distribution infrastructure. Now
that we've been notified that this is not the case, we'll fix it as
soon as possible. Thanks!
Also, the downloads page does not have a link to the KEYS file. Nor
does it have any documentation on how to use the sigs and hashes.
We'll fix that.
The downloads page should only link to the ASF mirrors, see for example:
http://incubator.apache.org/photark/photark-downloads.html
Also, there is no DISCLAIMER in any of the archive files.
AIUI, Incubator releases MUST contain a disclaimer:
The branding link only specifies that podling websites must display
that disclaimer. That exact disclaimer is the very first paragraph on
the download page. AIUI, there is no mandate that a DISCLAIMER file
must be included in the actual packaged distribution. Otherwise we
assume the release would have been voted against.
On a side note, we're doing our best to adhere to all requirements,
and we're happy to do so. But it has been *incredibly* time consuming
and frustrating to try to interpret what should be step-by-step
courses of action to adhere to these requirements.
Why isn't there a no-frills step-by-step, no room-for-error release
checklist that podlings can follow to guarantee that all required
criteria are met? It seems like such a checklist would be of the
highest priority for the Incubator to ensure that personal
interpretation is minimized or eliminated from the release process.
This release management page [1] is incredibly long and full of policy
and reasoning, which is all well and good if one wants to understand
*why* these policies exist, but podlings really need a step-by-step
*how-to* guide that references the 'why' document so we can service
our communities as efficiently as possible. The 'why' guide is
fantastic to read at our leisure, but the 'how' document would be far
more useful to podlings when release time comes.
My .02,
Les
[1] http://incubator.apache.org/guides/releasemanagement.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
