You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/12/19 13:45:16 UTC
PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Stephen McConnell wrote:
>
> Leo Simons wrote:
>
[...]
>> btw, this is a PMC vote is it not?
>
>
> Yep.
>
>> We should mark it as such I think.
A release vote is a PMC vote, no matter how it's marked.
It can be marked as such, but there is no gain in having to do so. Only
PMC members votes are counted anyway.
> And do it on the PMC list.
I disagree. There is no need for secrecy. We should not use that list if
not for secrecy reasons.
> There are members subscribed there that are not active here.
If it's true that Avalon PMC members are only on that list, IMNSHO this
it wrong. We should have that all subscribed to the PMC should be also
subscribed to the dev list.
> Steve.
>
>>
>>
>> - Leo Simons
>>
>> (at home sick so only replying to votes atm)
Get better!
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: news [mailto:news@main.gmane.org]On Behalf Of Ulrich Mayring
>
> Berin Loritsch wrote:
> >
> > The bottom line is that we are willing to help users of the
> > release.
>
> Maybe I'm in the wrong projects, but wherever (here too!!) I asked a
> question about cvs code people helped me. There is no such thing as
> formal support in OpenSource projects. But very rarely will the
> developers not be interested in user questions - but in my experience
> they don't make a distinction between releases and cvs code.
I'm not saying we treat you like dogmeat if you are running CVS code.
All I am saying is that if we have users that are forced to work with
only released code, then we have to be willing to help them make the
release work. If that means that with XYZ release, you can't upgrade
your jars with PDQ library yet, we need to let them know those
constraints. IOW, if I am only allowed to use released code by my
boss, or by the practicalities of not being able to keep up with CVS
changes in another open source project, then instead of saying "if
you go with current CVS you can XYZ PDQ as well as fix the problem
you are having".
> Maybe you mean: when something's broken in a release all
> developers put
> everything else aside and work on that bug? In contrast, when
> something
> in cvs is broken, it's not a first priority?
If a user supplies a bug report for released code, we should be
able to incorporate the fix right away (provided the user isn't
too vague). If a user supplies a bug report for CVS code, you
have to make the determination whether the code still exists (#1),
and if it is "transitional" (#2). If the code no longer exists,
but the bug still does, the fix supplied in the bug report won't
work. OTH if the code no longer exists, there is a good chance
that the bug is gone as well. If the code exists, but was
introduced as a place holder until more robust code could replace
it, you might not want to expend the energy on the fix.
In either case, if the bug report is for existing code, we need
to fix it ASAP. Bugs are bad. Not only should we fix the bug,
but we should add a testcase to make sure it doesn't creep back in.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Ulrich Mayring <ul...@mayring.de>.
Berin Loritsch wrote:
>
> The bottom line is that we are willing to help users of the
> release.
Maybe I'm in the wrong projects, but wherever (here too!!) I asked a
question about cvs code people helped me. There is no such thing as
formal support in OpenSource projects. But very rarely will the
developers not be interested in user questions - but in my experience
they don't make a distinction between releases and cvs code.
Maybe you mean: when something's broken in a release all developers put
everything else aside and work on that bug? In contrast, when something
in cvs is broken, it's not a first priority?
[release procedure]
Thanks for the info,
Ulrich
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: news [mailto:news@main.gmane.org]On Behalf Of Ulrich Mayring
>
> Berin Loritsch wrote:
> >
> > Minor nitpick:
> >
> > The release was *prevented*. Once a release is made, we
> have to support
> > it. There is no "oops, I didn't mean to do that".
>
> The release was up for downloading and then deleted. Just
> like a faulty
> commit is up for downloading and can be deleted, if a problem
> arises. I
> don't see the difference, except for that support issue you
> brought up.
> Curious: what does that support consist of that is given for
> a release,
> but not for a cvs version?
Support means answering questions regarding the released product
and how it works--note the answer should not be "get the latest
CVS and ....". It also means that we need to incorporate bug
fixes into subsequent releases. It also means that release 4.0.3
should not be wildly different from release 4.0.2.
The bottom line is that we are willing to help users of the
release.
> I'm just trying to understand the procedures here, because I want to
> learn something for my own use in other projects. What are the people,
> who voted +1 now, committing themselves to, which they wouldn't if it
> was just a cvs commit? What is the reasoning behind a +1 or
> -1 for a release?
9 times out of 10, a release does not get a -1 unless there is an
outstanding technical issue.
What is typical in most projects is to create a release archive, put it
on the server as a Release Candidate (i.e. Apache httpd-2.1.0rc1), and
let the community work with it for a little bit. If there are no real
Blockers (a really bad error like "it erased my hard drive when under
XYZ circumstances), then the release will be made. There can be several
iterations of the Release Candidates--where the *only* difference is a
bug fix.
During the whole Release Candidate process, the code is considered "frozen".
That means that there are no more features being added, and the only thing
being considered are bug fixes. The community may feel that a bug is so
minor that they can live with it for this release rather than create a new
Release Candidate for it.
When the release is official, the announcements are made in the
general locations.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Ulrich Mayring <ul...@mayring.de>.
Berin Loritsch wrote:
>
> Minor nitpick:
>
> The release was *prevented*. Once a release is made, we have to support
> it. There is no "oops, I didn't mean to do that".
The release was up for downloading and then deleted. Just like a faulty
commit is up for downloading and can be deleted, if a problem arises. I
don't see the difference, except for that support issue you brought up.
Curious: what does that support consist of that is given for a release,
but not for a cvs version?
I'm just trying to understand the procedures here, because I want to
learn something for my own use in other projects. What are the people,
who voted +1 now, committing themselves to, which they wouldn't if it
was just a cvs commit? What is the reasoning behind a +1 or -1 for a release?
Ulrich
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Ulrich Mayring <ul...@mayring.de>.
Leo Simons wrote:
>
> if the PMC doesn't vote and release software, the ASF doesn't release
> the software. It is then not any kind of "official ASF release", which
> might mean less legal protection and such. What you get then is a
> "convenience download of a cvs snapshot", ie a nightly build.
Ok, so this is a legal reason and therefore valid. But it's really only
"the ASF says so" at this point, not why they say so.
> There's also the issue of making sure the community is behind changes;
> voting means they have checked and agreed that the changes are good, the
> build is stable, etc etc etc.
Ok, also valid in theory, but it doesn't happen in real life. Paul wrote
a few words about the changes, everyone trusted him that the changes
were ok and said +1. Nobody checked the changes or ran any tests,
everyone trusted Paul - so why not trusting him in making a release?
> need I go on? :D
At your discretion ;-)
Ulrich
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-12-20 at 19:18, Ulrich Mayring wrote:
> Nicola Ken Barozzi wrote:
> >
> > Ulrich Mayring wrote:
> > > I don't really see why a release has to be voted on. It's less dangerous
> > > than a commit.
> >
> > Not at all. Apart from many other reasons, it's simple to see that a
> > commit can be reverted, not a release.
>
> Phoenix 4.0.3 release has just recently been reverted, when something
> was found to be wrong (lack of voting). QED.
>
> Now, what about all the other many reasons? :)
if the PMC doesn't vote and release software, the ASF doesn't release
the software. It is then not any kind of "official ASF release", which
might mean less legal protection and such. What you get then is a
"convenience download of a cvs snapshot", ie a nightly build.
There's also the issue of making sure the community is behind changes;
voting means they have checked and agreed that the changes are good, the
build is stable, etc etc etc.
frankly, the only reason _not_ to vote is because one would be in a real
hurry. And hurried software development generally is less quality.
need I go on? :D
cheers!
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
> On my count its 6 PMC members in favour - vote closes in about 3 days.
> I'm sure Paul will provide the result details when he's back from
> partying!
Diagnosis confirmed. Partying outbreak here.
Monday is the day I think. If the vote does not swing the other way
I'll upload the same targets to the new mirror system and make links.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Berin Loritsch wrote:
> [...]
>
>> What is the count of PMC members voting on the release? Can someone
>> make
>> an announcement?
>
On my count its 6 PMC members in favour - vote closes in about 3 days.
I'm sure Paul will provide the result details when he's back from partying!
Cheers, Steve.
>
> Who started the vote usually makes the announcement, adds the release
> in the STATUS file and makes the release.
>
> Paul, when you're ready (remember guys that he has to set up the
> mirroring, the're work to do there), you can proceed with all.
> If you need help, just ask. Thanks :-)
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
[...]
> What is the count of PMC members voting on the release? Can someone make
> an announcement?
Who started the vote usually makes the announcement, adds the release in
the STATUS file and makes the release.
Paul, when you're ready (remember guys that he has to set up the
mirroring, the're work to do there), you can proceed with all.
If you need help, just ask. Thanks :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: news [mailto:news@main.gmane.org]On Behalf Of Ulrich Mayring
>
> Nicola Ken Barozzi wrote:
> >
> > Ulrich Mayring wrote:
> > > I don't really see why a release has to be voted on. It's
> less dangerous
> > > than a commit.
> >
> > Not at all. Apart from many other reasons, it's simple to see that a
> > commit can be reverted, not a release.
>
> Phoenix 4.0.3 release has just recently been reverted, when something
> was found to be wrong (lack of voting). QED.
>
> Now, what about all the other many reasons? :)
Minor nitpick:
The release was *prevented*. Once a release is made, we have to support
it. There is no "oops, I didn't mean to do that".
Last time I checked, we have several +1s and no -1s. The whole PMC vote
thing was an issue brought up, but without vetoing the release.
What is the count of PMC members voting on the release? Can someone make
an announcement?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Ulrich Mayring <ul...@mayring.de>.
Nicola Ken Barozzi wrote:
>
> Ulrich Mayring wrote:
> > I don't really see why a release has to be voted on. It's less dangerous
> > than a commit.
>
> Not at all. Apart from many other reasons, it's simple to see that a
> commit can be reverted, not a release.
Phoenix 4.0.3 release has just recently been reverted, when something
was found to be wrong (lack of voting). QED.
Now, what about all the other many reasons? :)
Ulrich
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ulrich Mayring wrote:
> Berin Loritsch wrote:
>
>>I don't recall seeing anything in writing that explicitly stated
>>that all releases have to be decided on the PMC list.
>
>
> Just get the @&%§$ing thing out the door :)
>
> I don't really see why a release has to be voted on. It's less dangerous
> than a commit.
Not at all. Apart from many other reasons, it's simple to see that a
commit can be reverted, not a release.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Ulrich Mayring <ul...@mayring.de>.
Berin Loritsch wrote:
>
> I don't recall seeing anything in writing that explicitly stated
> that all releases have to be decided on the PMC list.
Just get the @&%§$ing thing out the door :)
I don't really see why a release has to be voted on. It's less dangerous
than a commit.
Ulrich
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Greg Stein <gs...@apache.org>.
In article <3E...@apache.org>, "Stephen McConnell"
<mc...@apache.org> wrote:
> Berin Loritsch wrote:
>
>>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>>
>>>If you want something to be considered as ratified by the PMC then the
>>>PMC have to vote on it on the PMC list - otherwise its not a PMC vote.
Nah. The PMC should be equal to the active developers, so they ought to
be in both places. A vote anywhere is still demonstrable that the PMC is
providing the necessary oversight.
[ recall that the intent is to simply show that the PMC is in charge and
is responsible for all code changes and releases; that can then be used
to make the ASF responsible for the code, rather than individuals; it
doesn't matter *where* the PMC/ASF takes charge -- only that it does so
and can be demonstrated ]
>...
>>You lost me Steve. I personally don't think that releases should be
>>decided on the PMC list. A release is something we all should be
>>excited about, and support. That's the community side of me speaking.
It can happen either place. Again: as long as it can reasonbly be shown
that the PMC is the group making the release. If the PMC'ers are doing
that on the dev@ list, then we're all right.
IMO, yes: it should be on the dev list.
>...
> The board is reasonably clear about the fact that it increases its
> exposure at the point of release of a product. For a release to occur,
> the board needs notification of this by the PMC Chair.
Easy there. A release can occur at any point, at the whim of the PMC. The
Board doesn't need any kind of notification. We *do* want to know about
it within the PMC's quarterly report to the Board (and hopefully, some
portion of the Board will know about it before then). The Board is *not*
a gating factor to a release. Do the release, and simply let the Board
know in the report.
> The question is
> - is a vote of the committers on a product release binding on the Chair
> to notify the board, and is the Chair's notification on a non-PMC
> decision binding on the Board. My impression is after reading a bunch
> of really dull stuff is that it isn't - bacause the Board only
> recognizes the PMC and the PMC Chair. I.e. if your want recognition of
> liability by Apache - you have to push this up from the committer
> community to the PMC to the Board.
The PMC can act anywhere it wants. And really: the Board is entirely
uninvolved in the release process. The PMC Chair is an officer of the
corporation and is empowered to act on behalf of the ASF. The Board has
the power to do "anything" but it isn't directly or indirectly
responsible for the code [releases]. That responsibility lies squarely on
the shoulders of the PMC Chair.
The short of it is: don't worry about the Board. It has nothing to do
with what you guys need and want to do. We have no responsibilities w.r.t
Avalon, its development, or its releases. We want to track what the PMC
is doing, and we have the right/responsibility to ensure that moves along
smoothly, but we're 99% uninvolved.
Cheers,
-g
--
gstein@apache.org ... ASF Chairman ... http://www.apache.org/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>If you want something to be considered as ratified by the PMC
>>then the
>>PMC have to vote on it on the PMC list - otherwise its not a
>>PMC vote.
>> Its not a secrecy issue - its a procedural point. If a PMC member is
>>subscribed to the PMC list and active and attentive to PMC issues -
>>there is nothing that states that the member must also follow
>>day to day
>>procedings on the dev list. Secondly, a PMC member has to right to
>>voice a different opinion as a PMC member as compared with
>>their role as
>>a committer. I really does not matter if that makes sence or
>>not - what
>>matters is that a PMC member has responsibilites over and above a
>>committer - and those responsibiliites may result in a
>>different opinions.
>>
>>
>
>Huh?
>
>You lost me Steve. I personally don't think that releases should
>be decided on the PMC list. A release is something we all should
>be excited about, and support. That's the community side of me
>speaking.
>
>I don't recall seeing anything in writing that explicitly stated
>that all releases have to be decided on the PMC list. If it is
>stated that way in the Apache Bylaws, then that is something the
>PMC needs to take up with the board so that we can that question
>resolved. I seriously doubt that *all* PMC decisions have to
>reside on the PMC list.
>
>
>
The board is reasonably clear about the fact that it increases its
exposure at the point of release of a product. For a release to occur,
the board needs notification of this by the PMC Chair. The question is
- is a vote of the committers on a product release binding on the Chair
to notify the board, and is the Chair's notification on a non-PMC
decision binding on the Board. My impression is after reading a bunch
of really dull stuff is that it isn't - bacause the Board only
recognizes the PMC and the PMC Chair. I.e. if your want recognition of
liability by Apache - you have to push this up from the committer
community to the PMC to the Board.
>>Please don't interprit this as Steve saying he will vote different on
>>the PMC list as compared to the committer list - all I'm
>>saying is that
>>if your going to do something - di it properly based on the structure
>>that has been put in place.
>>
>>
>
>We only agreed on how to agree. We didn't outline any procedures
>that are adopted by the community on how releases work. Perhaps we
>need to address that.
>
Yep - I agree that this should be addessed - maybe January ?
Cheers, Steve.
(who is completely familiar with the process of voting for the same
thing at different levels in order to move something up and out the door)
SJM
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> If you want something to be considered as ratified by the PMC
> then the
> PMC have to vote on it on the PMC list - otherwise its not a
> PMC vote.
> Its not a secrecy issue - its a procedural point. If a PMC member is
> subscribed to the PMC list and active and attentive to PMC issues -
> there is nothing that states that the member must also follow
> day to day
> procedings on the dev list. Secondly, a PMC member has to right to
> voice a different opinion as a PMC member as compared with
> their role as
> a committer. I really does not matter if that makes sence or
> not - what
> matters is that a PMC member has responsibilites over and above a
> committer - and those responsibiliites may result in a
> different opinions.
Huh?
You lost me Steve. I personally don't think that releases should
be decided on the PMC list. A release is something we all should
be excited about, and support. That's the community side of me
speaking.
I don't recall seeing anything in writing that explicitly stated
that all releases have to be decided on the PMC list. If it is
stated that way in the Apache Bylaws, then that is something the
PMC needs to take up with the board so that we can that question
resolved. I seriously doubt that *all* PMC decisions have to
reside on the PMC list.
> Please don't interprit this as Steve saying he will vote different on
> the PMC list as compared to the committer list - all I'm
> saying is that
> if your going to do something - di it properly based on the structure
> that has been put in place.
We only agreed on how to agree. We didn't outline any procedures
that are adopted by the community on how releases work. Perhaps we
need to address that.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC votes ( Re: [Vote] Phoenix 4.0.3 release.)
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
>
>>
>> Leo Simons wrote:
>>
> [...]
>
>>> btw, this is a PMC vote is it not?
>>
>>
>>
>> Yep.
>>
>>> We should mark it as such I think.
>>
>
> A release vote is a PMC vote, no matter how it's marked.
> It can be marked as such, but there is no gain in having to do so.
> Only PMC members votes are counted anyway.
>
>> And do it on the PMC list.
>
>
> I disagree. There is no need for secrecy. We should not use that list
> if not for secrecy reasons.
>
>> There are members subscribed there that are not active here.
>
>
> If it's true that Avalon PMC members are only on that list, IMNSHO
> this it wrong. We should have that all subscribed to the PMC should be
> also subscribed to the dev list.
If you want something to be considered as ratified by the PMC then the
PMC have to vote on it on the PMC list - otherwise its not a PMC vote.
Its not a secrecy issue - its a procedural point. If a PMC member is
subscribed to the PMC list and active and attentive to PMC issues -
there is nothing that states that the member must also follow day to day
procedings on the dev list. Secondly, a PMC member has to right to
voice a different opinion as a PMC member as compared with their role as
a committer. I really does not matter if that makes sence or not - what
matters is that a PMC member has responsibilites over and above a
committer - and those responsibiliites may result in a different opinions.
Please don't interprit this as Steve saying he will vote different on
the PMC list as compared to the committer list - all I'm saying is that
if your going to do something - di it properly based on the structure
that has been put in place.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>