On 8/16/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Rahul Akolkar wrote:
<snip/>
>
> [1] http://www.apache.org/dev/release-signing.html#policy
> [2] http://people.apache.org/~henkp/checker/sig.html
Thanks for those pointers Rahul. I'll be sure to add, at least the first
one to the guide.
I had a look at the Apache Maven 1 repo at
http://people.apache.org/repo/m1-ibiblio-rsync-repository/
There doesn't seem to be any consistency when looking at different
components. I had a look at a few:
<snap/>
Yes, unfortunately. Thats why the language in [1] above differentiates
between existing artifacts and new ones. We (Jakarta) must aim to be
consistent for new releases.
How do we handle this? If the previous pom is signed then the relocated
one should also be signed, is one way to go.
<snip/>
My opinion as well. And as a corollary, if the previous POM isn't
signed, we leave it at that after the mods.
And a more philosophical question: is a pom an artifact?
<snap/>
Traditionally, release artifacts have been source (and binary, where
applicable) distributions. With central repositories, things such as
jars and project metadata (poms) have begun to be "distributed"
individually, which gives them a flavor of being a release artifact.
Parent poms are routinely voted on and released, in many Apache
projects. Therefore, IMO, its best to have them summed and signed.
However, as always, I'm open to other views.
Henk's page does not seem to look at the Maven repos at all, only in /dist/
<snip/>
Correct, I realized that after I closed the door, but wanted to make
it to the Yankee stadium in time for the game ;-)
-Rahul
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
