On 2/3/11 20:39, David Jencks wrote:
I think that if it's good enough for the rest of the maven ecosystem it's good
enough for felix. How is felix special?
Felix is special because we think it is, so we make the rules based on
what we want to do, not what someone else does.
so I think rerolling releases and staging them to apache nexus for voting with
the same version number until a vote passes is just fine.
As I said, I can go either way.
If enough people respond maybe we can reach some sort of consensus...or
else we could call a vote on it.
-> richard
david jencks
On Feb 2, 2011, at 7:34 AM, Richard S. Hall wrote:
On 2/2/11 10:09, Guillaume Nodet wrote:
They should not have valid signatures. Signatures are supposed to be
always provided by the ASF infrastructure, else anybody can claim
being a valid release.
Depends on how you want to define "valid". The signatures are valid, you will
be able to verify that the release was signed by one of our committers. But the signature
will not be on a valid release, which makes the signature invalid. But how would someone
know unless they knew they were required to go to Apache and get the signature files?
Still, though, I don't really care. Really I don't. :-)
Decide on the rule and add it to our release page...
-> richard
On Wed, Feb 2, 2011 at 16:00, Richard S. Hall<he...@ungoverned.org> wrote:
On 2/2/11 9:49, Felix Meschberger wrote:
Hi,
Am Mittwoch, den 02.02.2011, 14:42 +0000 schrieb Richard S. Hall:
I think originally we were more strict on changing the version number
after failed votes, but we've since backed off. The reason for not being
as strict, if I recall, is that people can still download the failed
version while it's available with the signatures and put them up on some
web site and call them official and people wouldn't know because the
signatures are valid. So, what are we really gaining by changing the
version number?
The problem is exactly, that people may grab these packages under vote
and put them up. We cancel the vote; rebuild the package with the same
version number; succeed and publish.
At this point in time we not only have an invalid package uploaded which
can be identified as invalid (there is no tag for the failed release and
there is no vote success).
Rather we have two instances of a package with the same version number
in the wild. One is invalid and one is official. But which is which ?
I understand that argument, but we don't completely eliminate the confusion,
since there is still a failed version in the wild with valid signatures. So,
unless someone comes and does an audit of our releases and finds out there
isn't one (and understands what this means), then they won't know that their
release with valid signatures isn't valid.
In the end, I can care less either way. But lately we haven't been as strict
about this. I am fine with not worrying about it, but if others want to
worry about it we can do that too.
-> richard
I hope I did properly summarize the problem sketched by Roy.
Regards
Felix
-> richard
On 2/2/11 9:01, Guillaume Nodet wrote:
Last, remember each PMC decides on its own rules to govern its project.
So the fact Roy sent an email on Jackrabbit doesn't make it an
official policy for the ASF (and the ASF itself doesn't care about
such technical details).
I'll re-roll those releases, but I'd like things to be agreed upon
*and* documented at some point.
On Wed, Feb 2, 2011 at 14:59, Guillaume Nodet<gno...@gmail.com> wrote:
On Wed, Feb 2, 2011 at 14:18, Felix Meschberger<fmesc...@adobe.com>
wrote:
Hi,
My vetoes (actually there is no veto in a release vote since this is a
majority vote)
I know there's no vetoes in releases, but the goal is usually to
gather a consensus.
The fact you voted -1 puts a lot of pressure on me if I want to go to
the majority in order to have those released ;-)
are grounded on a message Roy Fielding once sent to the
Jackrabbit list [1]:
The problem with doing all of our laundry in public is that the
public
often download our unreleased packages even when we tell them not to.
For that reason, most Apache projects increment the patch-level
number
each time a new package is produced (releases do not need to be
sequential).
I suppose that depends on the definition of "most". Over the dozen of
projects I'm involved at the ASF, this is the first time I see that.
Maybe for projects like httpd that was the case, but I don't expect
many people that aren't felix committers to have downloaded those
released in the last 48 hours, so I still stand by the fact that in
our case, people are very aware that the jars aren't official yet.
Anyway, if that's us becoming an official Felix project policy, I'd
like that to be written somewhere. Oral tradition is not really good
for newcomers ;-)
Unfortunately I cannot readily find the written rule for this, but
this
makes perfect sense to me, which is why I would prefer to get a new
version number. Which is also why I always choose a new version number
for a release vote after I had to cancel a vote.
Regards
Felix
[1] http://markmail.org/message/533ybky6pqwwc2is
Am Mittwoch, den 02.02.2011, 11:16 +0000 schrieb Guillaume Nodet:
Over the past two years, I've been doing several releases in Felix
and
i've re-rolled some with the same version without any problems.
I don't see any mention about not reusing the same number twice in
the
release process:
http://felix.apache.org/site/release-management-nexus.html
What's the driver behing that ?
Until those releases are published, poeple accessing those are fully
aware of waht they are, so I don't see that as a problem.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com