Hi,
In general you should wait a minimum of 3 days, but if there an urgent security
fix then that can be ignored. 3 days gives people in different time zones or
who don’t work full time on the project a chance to respond and be involved in
the project. A lot of releases taken more than 3 days.
Thanks Hans for the link. I knew there was a 3 day requirement, I just wasn't
sure where it was documented.
I looked at the general list again and I was incorrect. The votes seem to
always adhere to the 3 day rule.
On 2023/07/01 11:45:49 hans.van.akel...@gmail.com wrote:
> Hi PJ,
>
> If we loo
Hi PJ,
If we look at the Release policy it states that it SHOULD remain open for at
least 72 hours [1].
In case we are talking about an emergency release/patch the 72 hours rule can
be ignored.
Cheers,
Hans
[1] https://www.apache.org/legal/release-policy.html#release-approval
On 1 Jul 2023 at
Hi everyone,
I'll go with the flow on this but I've noticed that some release votes specify
details about some minimum number of days that the thread will be open for.
Some other vote threads do not specify a time line and are liable to lead to an
announcement of a result as soon
On Tue, 26 Feb 2019 at 07:43, David P Grove wrote:
>
> Or in the case of the current OpenWhisk podling voting thread [1], our only
> mentor has already voted +1, but after a week we still need two more IPMC
> votes to be able to proceed.
>
> Please help
>
As of sometime over the past day or so,
Craig,
replies inline,
> Apologies if these comments cross other discussions. It's hard to keep
> track of all the threads that have forked from the original discussion.
I'm struggling to keep up too :-/
> This is really sad, because in most of these cases the mentors have not
> voted. And
> On the one side we have lengthy discussions about non-mentors from
> resisting to interfere, but on the other hand podlings are begging for
> such "interference".
> Guess there are always two sides of the discussion.
I politely disagree with you Chris.
What I raised was that cold interfere
On Tue, 26 Feb 2019 at 20:01, Ted Dunning wrote:
>
> Kevin,
>
> Can you explain what checking you did to justify your vote?
>
> This is important so that others can know what has already been done.
IMO the +1 ought to be added to the vote thread, not here.
>
>
> On Tue, Feb 26, 2019 at 8:02 AM K
Kevin,
Can you explain what checking you did to justify your vote?
This is important so that others can know what has already been done.
On Tue, Feb 26, 2019 at 8:02 AM Kevin A. McGrail
wrote:
> On 2/26/2019 8:20 AM, David P Grove wrote:
> >
> > Or in the case of the current OpenWhisk podli
On 2/26/2019 8:20 AM, David P Grove wrote:
>
> Or in the case of the current OpenWhisk podling voting thread [1], our only
> mentor has already voted +1, but after a week we still need two more IPMC
> votes to be able to proceed.
>
> Please help
>
Sorry, I was not aware of that issue. I'm monit
Hmmm ... this is really odd ...
On the one side we have lengthy discussions about non-mentors from resisting to
interfere, but on the other hand podlings are begging for such "interference".
Guess there are always two sides of the discussion.
And I have to admit that for a short time I was hesit
"general";
Subject: Re: Incubator release votes
Craig Russell wrote on 02/25/2019 09:15:56 PM:
>
> To me, the biggest issue with incubating releases has been lack of
> engagement by mentors for release voting. Many examples from history
> have podlings begging for some
Craig Russell wrote on 02/25/2019 09:15:56 PM:
>
> To me, the biggest issue with incubating releases has been lack of
> engagement by mentors for release voting. Many examples from history
> have podlings begging for someone, anyone, to review a release that
> has already received review in th
Hi Mick,
I appreciate your taking time to document what you have experienced in the
incubator.
Apologies if these comments cross other discussions. It's hard to keep track of
all the threads that have forked from the original discussion.
> On Feb 24, 2019, at 4:35 PM, Mick Semb Wever wrote:
>
The third condition is implied by the second one.
I do not believe the second condition is implied by "Votes on whether
a package is ready to be released use majority approval -- i.e., at
least three PMC members must vote affirmatively for release, and there
must be more positive than negative vot
Gah, this is what I was trying to convey. But I don't think it's still
100% correct.
You need a minimum of 3 +1's
Your net positive votes must be 3 (e.g. if you have a -1 and 5 total votes,
the other 4 votes must be +1's)
You need more +1's than -1's
I'm not sure what is written better.
(trying
On 6/15/17 1:11 PM, Oliver B. Fischer wrote:
Please note:
This vote is a "majority approval" with a minimum of three +1 votes and
no -1’s (see [4]).
Just wanted to point out that your description of majority approval is
wrong. You need at least 3 +1's and more +1's than -1's. -1's are not
v
On Mar 19, 2014, at 10:48 AM, sebb wrote:
> On 19 March 2014 15:05, Mark Struberg wrote:
>> what has been with the rule that an ipmc must forward the VOTE to the
>> incubator pmc when it gets started, and those members can also cast a
>> binding -1 ?
>
> IPMC votes are the only ones that are b
not specifically incubator related, was wondering if someone at
>>> the incubator may provide me some insight.
>>>
>>> Right now, release votes cannot be veto'd. This seems like an
>>> oversight IMHO. If a release candidate is visibly wrong (e.g. bad
>>>
Hi all,
>>
>> While not specifically incubator related, was wondering if someone at
>> the incubator may provide me some insight.
>>
>> Right now, release votes cannot be veto'd. This seems like an
>> oversight IMHO. If a release candidate is visibly wrong (e
On Mon, Mar 17, 2014 at 1:10 PM, John D. Ament wrote:
> Hi all,
>
> While not specifically incubator related, was wondering if someone at
> the incubator may provide me some insight.
>
> Right now, release votes cannot be veto'd. This seems like an
> oversight IMHO.
lease.
That's a little too trusting for me, but I'm relatively new hereŠ
-Alex
On 3/17/14 10:10 AM, "John D. Ament" wrote:
>Hi all,
>
>While not specifically incubator related, was wondering if someone at
>the incubator may provide me some insight.
>
>Right
Hi all,
While not specifically incubator related, was wondering if someone at
the incubator may provide me some insight.
Right now, release votes cannot be veto'd. This seems like an
oversight IMHO. If a release candidate is visibly wrong (e.g. bad
licenses, or something else), surel
On 6/4/06, Leo Simons <[EMAIL PROTECTED]> wrote:
On Fri, Jun 02, 2006 at 10:17:46AM -0400, Noel J. Bergman wrote:
> Leo Simons wrote:
> > Let's write a piece of software to do the auditing for us.
>
> How do you propose to do this? How do you propose to audit the code and
> know which pieces of
On 6/3/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
On 6/2/06, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> I like the idea of automation.
>
> What would be even more helpful would be a default Apache project
> setup, with a maven release target that builds a release in the right
> format.
>
> If
On 6/2/06, Leo Simons <[EMAIL PROTECTED]> wrote:
(this is a rant and the beginnings of a proposal which has nothing to do
in particular with James, ActiveMQ, or its release)
There must be. All these little rules and policies and practices (written
or unwritten) seem like they could be some
On Fri, Jun 02, 2006 at 10:17:46AM -0400, Noel J. Bergman wrote:
> Leo Simons wrote:
> > Let's write a piece of software to do the auditing for us.
>
> How do you propose to do this? How do you propose to audit the code and
> know which pieces of code require which license and whether or not that
On 6/2/06, Paul Fremantle <[EMAIL PROTECTED]> wrote:
I like the idea of automation.
What would be even more helpful would be a default Apache project
setup, with a maven release target that builds a release in the right
format.
If the project structure started out with LICENSE, NOTICE, JAR targ
Cliff has been doing so. Frankly, I suspect that many ASF projects need to
clean up their releases to conform with the currently solidifying ASF-wide
guidelines, but the Incubator PMC is more aware of them, and more diligent
in applying them.
From the perspective of being involved in one of
Agreed. Any tools that help incubating projects get off to the right
start we be a good start. Even if it's just a check list that has all
the things that have been found to be missing before in previous
attempted releases would be a great idea.
On 6/2/06, Paul Fremantle <[EMAIL PROTECTED]> wro
I like the idea of automation.
What would be even more helpful would be a default Apache project
setup, with a maven release target that builds a release in the right
format.
If the project structure started out with LICENSE, NOTICE, JAR targets
that put those in META-INF, places to put auxiliar
On Jun 2, 2006, at 9:06 AM, Leo Simons wrote:
(this is a rant and the beginnings of a proposal which has nothing
to do
in particular with James, ActiveMQ, or its release)
On Fri, May 26, 2006 at 01:11:35PM +0100, James Strachan wrote:
In accordance with the incubator release procedure (see
Leo Simons wrote:
> People are doing stuff, trying to comply with all kinds of policies,
> and then instead of self-governing they have to go ask permission.
> When you need to ask for it, you're not self-governing.
Self-governance is a learned behavior, and one of the things that the
Incubator
(this is a rant and the beginnings of a proposal which has nothing to do
in particular with James, ActiveMQ, or its release)
On Fri, May 26, 2006 at 01:11:35PM +0100, James Strachan wrote:
> In accordance with the incubator release procedure (see below) the
> ActiveMQ community has voted on and ap
34 matches
Mail list logo
