You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "John D. Ament" <jo...@apache.org> on 2016/12/26 15:29:35 UTC
[DISCUSS] Drop the 2013 Alternate Voting Policy
All,
I felt this required a separate discussion. The incubator maintains
something referred to as the 2013 alternate voting policy. You can find
the full details starting here:
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
This policy as far as I can tell has never been used by any podling. In
addition, it doesn't align to the ASF's policies of releases. I believe
the problem it was trying to solve was getting binding votes on releases
which has mostly been fixed (release votes would go on for 20+ days back
then).
So I was wondering, is this a policy we want to keep around?
John
Re: [DISCUSS] Drop the 2013 Alternate Voting Policy
Posted by "John D. Ament" <jo...@apache.org>.
I've taken a stab at incorporating this sentiment into a new guide I'm
working on, rather than updating the existing release guides. Explained in
the other email.
Take a look and let me know if you feel I've misstated anything.
John
On Tue, Dec 27, 2016 at 5:04 PM Stian Soiland-Reyes <st...@apache.org>
wrote:
> On 27 December 2016 at 20:44, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> > I'd rather not sanctify exceptions with a precise list, but rather stop
> at:
> >
> > "During incubation, a podling's release package may not be perfect. It
>
> ... package may not be fully in compliance with [ASF release
> policy](https://www.apache.org/dev/release.html).
>
> > will be up to mentors and IPMC members
> > to define the appropriate leeway".
>
> ... as long as it is [legal](https://www.apache.org/legal/resolved.html).
>
>
> +1 to a more abstract text - as long as the podling release is legally
> sound (e.g. does not include material we can't distribute under ASF
> license) we can still permit it, even if it's not according to policy.
>
> However it would be a judgement per podling - if a podling has been
> told for two releases for instance to fix their NOTICE, then a third
> release might be downvoted (not blocked) for that reason. It could
> also happen that an issue is not identified until later - so it's not
> easy to write it down as strict rules - and I think we've the current
> practice is about right. Some "just enough" formalizing of that
> practice, as Roman proposes, will help keep it along those lines also
> for the future.
>
> --
> Stian Soiland-Reyes
> http://orcid.org/0000-0001-9842-9718
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [DISCUSS] Drop the 2013 Alternate Voting Policy
Posted by Stian Soiland-Reyes <st...@apache.org>.
On 27 December 2016 at 20:44, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> I'd rather not sanctify exceptions with a precise list, but rather stop at:
>
> "During incubation, a podling's release package may not be perfect. It
... package may not be fully in compliance with [ASF release
policy](https://www.apache.org/dev/release.html).
> will be up to mentors and IPMC members
> to define the appropriate leeway".
... as long as it is [legal](https://www.apache.org/legal/resolved.html).
+1 to a more abstract text - as long as the podling release is legally
sound (e.g. does not include material we can't distribute under ASF
license) we can still permit it, even if it's not according to policy.
However it would be a judgement per podling - if a podling has been
told for two releases for instance to fix their NOTICE, then a third
release might be downvoted (not blocked) for that reason. It could
also happen that an issue is not identified until later - so it's not
easy to write it down as strict rules - and I think we've the current
practice is about right. Some "just enough" formalizing of that
practice, as Roman proposes, will help keep it along those lines also
for the future.
--
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Drop the 2013 Alternate Voting Policy
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
I'd rather not sanctify exceptions with a precise list, but rather stop at:
"During incubation, a podling's release package may not be perfect. It
will be up to mentors and IPMC members
to define the appropriate leeway".
Or something to that extent.
Thanks,
Roman.
On Mon, Dec 26, 2016 at 6:03 PM, John D. Ament <jo...@apache.org> wrote:
> On Mon, Dec 26, 2016 at 12:36 PM Marvin Humphrey <ma...@rectangular.com>
> wrote:
>
>> On Mon, Dec 26, 2016 at 7:29 AM, John D. Ament <jo...@apache.org>
>> wrote:
>>
>> > This policy as far as I can tell has never been used by any podling.
>>
>> It has been used once (by ODF Toolkit).
>>
>> > I believe the problem it was trying to solve was getting binding votes on
>> > releases which has mostly been fixed (release votes would go on for 20+
>> days
>> > back then).
>>
>> The initiative which culminated in the 2013 Alternate Voting Process had
>> some
>> secondary effects which turned out to be more important than the primary
>> effect.
>>
>> Most crucially, the IPMC achieved a common understanding about when to
>> approve
>> flawed release candidates that were legally OK yet not in compliance with
>> Apache policy. ("Does it put the Foundation at risk?" If not, then bias
>> towards approval.) Between that and the eventual success of a separate
>> initiative to codify and clarify official release policy, two important
>> ends
>> were achieved:
>>
>> * Arguments over release candidates ended sooner and became less
>> embittered.
>> * Podlings no longer had to cycle through so many release candidates,
>> reducing burnout for Mentors and allowing us to use the limited IPMC
>> release reviewing capacity more effectively.
>>
>
> So, would it perhaps make sense to include a blurb about what is expected
> of a release and what the goals of incubation should be? Something like:
>
> During incubation, a podling's release package may not be perfect. These
> errors may include:
> - Improper NOTICE/LICENSE files
> - Failures building from source
> - Inclusion of binaries in the source release
> - Source release not staged properly.
> - etc... (Justin any notes here?)
>
> These issues vary in severity, and may be pointed out as blocking or not
> blocking the release by the IPMC. Any blocking issues should cause the
> release to rerolled to fix the issue. Non-blocking issues should be
> entered into your issue tracker and planned to be fixed for the next
> release.
>
> John
>
>
>
>>
>> The problem of insufficient Mentor participation in release review has not
>> gone away, and we remain heavily dependent on Justin (most often) to
>> provide
>> both review and the additional vote. If Justin's involvement drops, the
>> Incubator is likely to have problems again.
>>
>> However, to address the remaining systemic flaws it seems wise to channel
>> our energies into policy and documentation streamlining, since that has
>> yielded better results.
>>
>> > So I was wondering, is this a policy we want to keep around?
>>
>> +1 to revert.
>>
>> The language was deliberately crafted as an addendum which would be easy to
>> back out. Ditching it will have no problematic consequences.
>>
>> Marvin Humphrey
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Drop the 2013 Alternate Voting Policy
Posted by "John D. Ament" <jo...@apache.org>.
On Mon, Dec 26, 2016 at 12:36 PM Marvin Humphrey <ma...@rectangular.com>
wrote:
> On Mon, Dec 26, 2016 at 7:29 AM, John D. Ament <jo...@apache.org>
> wrote:
>
> > This policy as far as I can tell has never been used by any podling.
>
> It has been used once (by ODF Toolkit).
>
> > I believe the problem it was trying to solve was getting binding votes on
> > releases which has mostly been fixed (release votes would go on for 20+
> days
> > back then).
>
> The initiative which culminated in the 2013 Alternate Voting Process had
> some
> secondary effects which turned out to be more important than the primary
> effect.
>
> Most crucially, the IPMC achieved a common understanding about when to
> approve
> flawed release candidates that were legally OK yet not in compliance with
> Apache policy. ("Does it put the Foundation at risk?" If not, then bias
> towards approval.) Between that and the eventual success of a separate
> initiative to codify and clarify official release policy, two important
> ends
> were achieved:
>
> * Arguments over release candidates ended sooner and became less
> embittered.
> * Podlings no longer had to cycle through so many release candidates,
> reducing burnout for Mentors and allowing us to use the limited IPMC
> release reviewing capacity more effectively.
>
So, would it perhaps make sense to include a blurb about what is expected
of a release and what the goals of incubation should be? Something like:
During incubation, a podling's release package may not be perfect. These
errors may include:
- Improper NOTICE/LICENSE files
- Failures building from source
- Inclusion of binaries in the source release
- Source release not staged properly.
- etc... (Justin any notes here?)
These issues vary in severity, and may be pointed out as blocking or not
blocking the release by the IPMC. Any blocking issues should cause the
release to rerolled to fix the issue. Non-blocking issues should be
entered into your issue tracker and planned to be fixed for the next
release.
John
>
> The problem of insufficient Mentor participation in release review has not
> gone away, and we remain heavily dependent on Justin (most often) to
> provide
> both review and the additional vote. If Justin's involvement drops, the
> Incubator is likely to have problems again.
>
> However, to address the remaining systemic flaws it seems wise to channel
> our energies into policy and documentation streamlining, since that has
> yielded better results.
>
> > So I was wondering, is this a policy we want to keep around?
>
> +1 to revert.
>
> The language was deliberately crafted as an addendum which would be easy to
> back out. Ditching it will have no problematic consequences.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [DISCUSS] Drop the 2013 Alternate Voting Policy
Posted by Ted Dunning <te...@gmail.com>.
On Mon, Dec 26, 2016 at 9:36 AM, Marvin Humphrey <ma...@rectangular.com>
wrote:
> > So I was wondering, is this a policy we want to keep around?
>
> +1 to revert.
>
> The language was deliberately crafted as an addendum which would be easy to
> back out. Ditching it will have no problematic consequences.
Sounds right.
Re: [DISCUSS] Drop the 2013 Alternate Voting Policy
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Dec 26, 2016 at 7:29 AM, John D. Ament <jo...@apache.org> wrote:
> This policy as far as I can tell has never been used by any podling.
It has been used once (by ODF Toolkit).
> I believe the problem it was trying to solve was getting binding votes on
> releases which has mostly been fixed (release votes would go on for 20+ days
> back then).
The initiative which culminated in the 2013 Alternate Voting Process had some
secondary effects which turned out to be more important than the primary
effect.
Most crucially, the IPMC achieved a common understanding about when to approve
flawed release candidates that were legally OK yet not in compliance with
Apache policy. ("Does it put the Foundation at risk?" If not, then bias
towards approval.) Between that and the eventual success of a separate
initiative to codify and clarify official release policy, two important ends
were achieved:
* Arguments over release candidates ended sooner and became less embittered.
* Podlings no longer had to cycle through so many release candidates,
reducing burnout for Mentors and allowing us to use the limited IPMC
release reviewing capacity more effectively.
The problem of insufficient Mentor participation in release review has not
gone away, and we remain heavily dependent on Justin (most often) to provide
both review and the additional vote. If Justin's involvement drops, the
Incubator is likely to have problems again.
However, to address the remaining systemic flaws it seems wise to channel
our energies into policy and documentation streamlining, since that has
yielded better results.
> So I was wondering, is this a policy we want to keep around?
+1 to revert.
The language was deliberately crafted as an addendum which would be easy to
back out. Ditching it will have no problematic consequences.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Drop the 2013 Alternate Voting Policy
Posted by "John D. Ament" <jo...@apache.org>.
On Sat, Dec 31, 2016 at 12:02 AM Marvin Humphrey <ma...@rectangular.com>
wrote:
> On Thu, Dec 29, 2016 at 11:46 AM, John D. Ament <jo...@apache.org>
> wrote:
> > Pssst really need you guys looking at the proposed replacement
> > documentation.
> >
>
> https://lists.apache.org/thread.html/fab8122d7695e47bacbff680b83eb4ceed98539a7815e2232abf5d2f@%3Cgeneral.incubator.apache.org%3E
>
> There's a lot here, and with social obligations of the holiday season,
> I'm having trouble finding the time to review it all. If I may suggest
> an approach, though:
>
So far, the input received has gone well. I think we're good with the first
step, updating release documentation to remove the duplication.
>
> For guides, how-to's and the like, it is nice if you summarize changes
> in advance, but we also shouldn't let anything block your way. The
> Incubator has suffered from a lack of people willing to wade in and
> actually work on documentation -- having you show up to do work is a
> real boon. So if you tell people "I'm going to work on X, and here's
> roughly what I plan", then JFDI so long as you work incrementally and
> reversibly. People have the option to review your commits.
>
> But for *policy*, specifically the Incubation_Policy.html page, please
> take a different tack. Any change to that page should be proposed as
> a patch on general@incubator in a thread with a 72 hour minimum review
> period. Furthermore, please try to make good use of our limited
> capacity for review: endeavor to make clean and minimal proposals,
> avoiding multiple revisions and large, hard-to-digest changesets.
>
> It's important to get the fine details of policy right because even
> minor wording inaccuracies can spawn brutal, bitter disputes.
> Additionally, a deliberate, inclusive drafting and review process is a
> prerequisite for community buy-in, inoculating us against crises of
> legitimacy.
>
> Does that division make sense? Careful drafting and RTC for policy,
> CTR and a higher tolerance for inaccuracy in guides, FAQs, etc.
>
> One more thing: the Proposal Guide is way more important than all the
> others, so please treat it with care if you do any work there. During
> the crafting of a proposal for incubation, that page has profound
> influence on incoming communities as they think deeply about how their
> project might fit into Apache. (In fact, maybe we should make that
> page RTC...)
>
May be we should consider calling it the Proposal Policy? I agree with you
on its importance.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [DISCUSS] Drop the 2013 Alternate Voting Policy
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Dec 29, 2016 at 11:46 AM, John D. Ament <jo...@apache.org> wrote:
> Pssst really need you guys looking at the proposed replacement
> documentation.
>
https://lists.apache.org/thread.html/fab8122d7695e47bacbff680b83eb4ceed98539a7815e2232abf5d2f@%3Cgeneral.incubator.apache.org%3E
There's a lot here, and with social obligations of the holiday season,
I'm having trouble finding the time to review it all. If I may suggest
an approach, though:
For guides, how-to's and the like, it is nice if you summarize changes
in advance, but we also shouldn't let anything block your way. The
Incubator has suffered from a lack of people willing to wade in and
actually work on documentation -- having you show up to do work is a
real boon. So if you tell people "I'm going to work on X, and here's
roughly what I plan", then JFDI so long as you work incrementally and
reversibly. People have the option to review your commits.
But for *policy*, specifically the Incubation_Policy.html page, please
take a different tack. Any change to that page should be proposed as
a patch on general@incubator in a thread with a 72 hour minimum review
period. Furthermore, please try to make good use of our limited
capacity for review: endeavor to make clean and minimal proposals,
avoiding multiple revisions and large, hard-to-digest changesets.
It's important to get the fine details of policy right because even
minor wording inaccuracies can spawn brutal, bitter disputes.
Additionally, a deliberate, inclusive drafting and review process is a
prerequisite for community buy-in, inoculating us against crises of
legitimacy.
Does that division make sense? Careful drafting and RTC for policy,
CTR and a higher tolerance for inaccuracy in guides, FAQs, etc.
One more thing: the Proposal Guide is way more important than all the
others, so please treat it with care if you do any work there. During
the crafting of a proposal for incubation, that page has profound
influence on incoming communities as they think deeply about how their
project might fit into Apache. (In fact, maybe we should make that
page RTC...)
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Drop the 2013 Alternate Voting Policy
Posted by "John D. Ament" <jo...@apache.org>.
Pssst really need you guys looking at the proposed replacement
documentation.
https://lists.apache.org/thread.html/fab8122d7695e47bacbff680b83eb4ceed98539a7815e2232abf5d2f@%3Cgeneral.incubator.apache.org%3E
On Thu, Dec 29, 2016 at 1:21 PM Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Thu, Dec 29, 2016 at 12:53 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> > On Mon, Dec 26, 2016 at 4:29 PM, John D. Ament <jo...@apache.org>
> wrote:
> >> ...is this a policy we want to keep around?...
> >
> > I'm fine with removing it - community Darwinism at work ;-)
>
> +1 for the same reason I'm always +1 on removing dead/little used code
> -- if after all
> you discover that you needed it -- it is one SCM command away.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [DISCUSS] Drop the 2013 Alternate Voting Policy
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Thu, Dec 29, 2016 at 12:53 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Mon, Dec 26, 2016 at 4:29 PM, John D. Ament <jo...@apache.org> wrote:
>> ...is this a policy we want to keep around?...
>
> I'm fine with removing it - community Darwinism at work ;-)
+1 for the same reason I'm always +1 on removing dead/little used code
-- if after all
you discover that you needed it -- it is one SCM command away.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Drop the 2013 Alternate Voting Policy
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Dec 26, 2016 at 4:29 PM, John D. Ament <jo...@apache.org> wrote:
> ...is this a policy we want to keep around?...
I'm fine with removing it - community Darwinism at work ;-)
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org