Re: Change to Subversion PMC rule for approving backports
+1 Thanks Julian! On Tue, Sep 17, 2019 at 5:11 PM Branko Čibej wrote: > On 17.09.2019 16:53, Julian Foad wrote: > > Bert Huijben wrote: > > +1 on reducing the number of required votes to just 2 +1s. > > > > We have consensus in this thread for reducing the requirement for > > regular (non-LTS) releases to two "+1" votes, but not to just one. > > Thanks for pushing this through, Julian. > > -- Brane > >
Re: Change to Subversion PMC rule for approving backports
On 17.09.2019 16:53, Julian Foad wrote: > Bert Huijben wrote: > +1 on reducing the number of required votes to just 2 +1s. > > We have consensus in this thread for reducing the requirement for > regular (non-LTS) releases to two "+1" votes, but not to just one. Thanks for pushing this through, Julian. -- Brane
Re: Change to Subversion PMC rule for approving backports
Bert Huijben wrote: +1 on reducing the number of required votes to just 2 +1s. We have consensus in this thread for reducing the requirement for regular (non-LTS) releases to two "+1" votes, but not to just one. Published in http://svn.apache.org/r1867064 - Julian
Re: Change to Subversion PMC rule for approving backports
Fri Sep 06 07:14:56 GMT+01:00 2019 Branko Čibej : > On 06.09.2019 07:49, Julian Foad wrote: > > > > Bert Huijben wrote: > >> Why just one +1? > >> I like the second eye rule we currently have, so one +1 from the nominator > >> and one additional eye. > >> For bindings we have +- the same rule, but one of the eyes can be someone > >> else than a full committer. (Not sure if we still have any active partial > >> committers though) > >> > >> As always, feel free to ping me if you need an additional review for > >> something. I don't follow the dev@ list on a daily basis any more :( > >> > >> +1 on reducing the number of required votes to just 2 +1s. > > > > The thing is, every trunk change goes in to the next regular release, and > > the next LTS release, anyway with no extra eyes required. > > Well that's not really true, is it. You're assuming that people don't > read commit logs. I'm referring to "extra eyes" in the sense of deliberate, requested, and recorded. Commit review is already possible anyway. > And I think you're oversimplifying things a bit > because ... > > > If certain changes should have more review, we should be managing that on > > trunk. > > ... there's a crucial difference here: we're allowed to make changes on > trunk that are forbidden on release branches. That was always the reason > for having an extra review step for backports. That's a true distinction. Sent with FairEmail [https://email.faircode.eu/] , an open source, privacy friendly email app for Android
Re: Change to Subversion PMC rule for approving backports
On 06.09.2019 07:49, Julian Foad wrote: > > Bert Huijben wrote: >> Why just one +1? >> I like the second eye rule we currently have, so one +1 from the nominator >> and one additional eye. >> For bindings we have +- the same rule, but one of the eyes can be someone >> else than a full committer. (Not sure if we still have any active partial >> committers though) >> >> As always, feel free to ping me if you need an additional review for >> something. I don't follow the dev@ list on a daily basis any more :( >> >> +1 on reducing the number of required votes to just 2 +1s. > > The thing is, every trunk change goes in to the next regular release, and the > next LTS release, anyway with no extra eyes required. Well that's not really true, is it. You're assuming that people don't read commit logs. And I think you're oversimplifying things a bit because ... > If certain changes should have more review, we should be managing that on > trunk. ... there's a crucial difference here: we're allowed to make changes on trunk that are forbidden on release branches. That was always the reason for having an extra review step for backports. -- Brane
Re: Change to Subversion PMC rule for approving backports
Bert Huijben wrote: > Why just one +1? > I like the second eye rule we currently have, so one +1 from the nominator > and one additional eye. > For bindings we have +- the same rule, but one of the eyes can be someone > else than a full committer. (Not sure if we still have any active partial > committers though) > > As always, feel free to ping me if you need an additional review for > something. I don't follow the dev@ list on a daily basis any more :( > > +1 on reducing the number of required votes to just 2 +1s. The thing is, every trunk change goes in to the next regular release, and the next LTS release, anyway with no extra eyes required. If certain changes should have more review, we should be managing that on trunk. Then it would make sense to have a policy that says only changes having had extra review can be back ported. - Julian
Re: Change to Subversion PMC rule for approving backports
Why just one +1? I like the second eye rule we currently have, so one +1 from the nominator and one additional eye. For bindings we have +- the same rule, but one of the eyes can be someone else than a full committer. (Not sure if we still have any active partial committers though) As always, feel free to ping me if you need an additional review for something. I don't follow the dev@ list on a daily basis any more :( +1 on reducing the number of required votes to just 2 +1s. Bert On Thu, Aug 29, 2019 at 5:36 PM Julian Foad wrote: > To all devs: > > Proposal for a permanent change to our backport rules [1]: > >* For non-LTS releases, each backport nomination only requires one +1 > vote (instead of three). > > Specific diff to the text of [1]: > > - A change needs three +1 votes from full committers (or partial > committers for the involved areas), and no vetoes, to go into A.B.x. > + A change needs three +1 votes (for an LTS release line) or one +1 vote > (for a non-LTS release line) from full committers (or partial committers > for the involved areas), and no vetoes, to go into A.B.x. > > - (If a change affects the build system, however, it is considered a > core change, and needs three +1's.) > + (If a change affects the build system, however, it is considered a > core change, and so for an LTS release line needs three +1's.) > > Agreements? > > > [1] > > http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization > > - Julian > > > > Branko Čibej wrote: > > On 18.07.2019 14:09, Julian Foad wrote: > >> Recently there have not been enough developers willing and able to > >> test and approve proposed fixes for back-port to the supported release > >> branches. > >> > >> We have just been discussing this on #svn-dev [1]. Rather than delay > >> forever, myself, stsp and brane decided that in line with "silence > >> implies consent", we can go ahead with merging the proposed backports > >> even if they have fewer than 3 votes. > >> > >> We will go ahead now. > > > > Thanks for the heads-up, Julian, and for pushing the releases. [...] >
Re: Change to Subversion PMC rule for approving backports
Julian Foad wrote:
> The proposed change now looks like this:
>
> old:
>
> http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization-how-many-votes
>
> new:
>
> http://subversion-staging.apache.org/docs/community-guide/releasing.html#release-stabilization-how-many-votes
Improved in http://svn.apache.org/r1866320 ; the overall change is now:
[[[
+For a non-LTS ("regular") release line
+
+A change is approved if it receives one +1 vote and no vetoes. (Only
+binding votes count; see above.)
+
+For an LTS release line
+
A change is approved if it receives three +1s and no vetoes. (Only
]]]
- Julian
Re: Change to Subversion PMC rule for approving backports
The proposed change now looks like this:
old:
http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization-how-many-votes
new:
http://subversion-staging.apache.org/docs/community-guide/releasing.html#release-stabilization-how-many-votes
[[[
-A change is approved if it receives three +1s and no vetoes. (Only
-binding votes count; see above.)
+For a non-LTS ("regular") release line, a change is approved if it
+receives one binding +1 vote and no vetoes.
-Notwithstanding the above, a change that affects only areas that are not
+For an LTS release line, a change that affects core code or the build
+system is approved if it receives three binding +1s and no vetoes.
+A change that affects only areas that are not
core code (for example, tools/, packages/, bindings/, test scripts, etc.),
and that does not affect the build system,
can go in with a +1 from a full committer or a
]]]
committed:
http://svn.apache.org/r1866313
- Julian
Re: Change to Subversion PMC rule for approving backports
Daniel Shahaf wrote: Julian Foad wrote on Fri, 30 Aug 2019 06:54 +00:00: Daniel Shahaf wrote: I think that section as it stands (before your change) is pretty hard to follow: it jumps back and forth between different topics. I might take a shot at clarifying it (without semantic changes), if that won't conflict with patches you have in flight. Yes please! I strongly urge that we simplify any and all of our documentation at any opportunity. Nearly all of it is much too long. It would be much better to state the facts in a few bullet points, and move the discussion of rationale and history to a dedicated subsection so readers just wanting the facts can easily skip that part. I've had a go, see staging/. Feel free to take it from here. You've improved the information content and clarity. Thank you. We can publish that as it is, even with the unresolved TODO about defining "veto". I notice it's now ~32 lines longer, not counting section headers. I wish we could somehow take out more than we add in. What do you propose to do about the rule that changes to tools/ or bindings/ require 1×+1 and 1×+0? It would be odd if changes to tools/ required more votes than changes to core. Good catch. Should require just one +1 vote (removing the additional +0 vote). While editing on staging/ I noticed there was an explicit bit of rationale there about getting two pairs of eyes on every change. I guess you should change that part too (make it applicable to LTS lines only)? Yes, that would be in accordance with the proposal. Or alternatively, require at least a +1 and a +0 on core changes to non-LTS lines. I don't mind exactly what rules we end up with, just so long as it is lighter weight than for LTS releases. Thanks, - Julian
Re: Change to Subversion PMC rule for approving backports
Julian Foad wrote on Fri, 30 Aug 2019 06:54 +00:00: > Daniel Shahaf wrote: > > I think that section as it stands (before your change) is pretty hard to > > follow: it jumps back and forth between different topics. I might take > > a shot at clarifying it (without semantic changes), if that won't > > conflict with patches you have in flight. > > Yes please! > > I strongly urge that we simplify any and all of our documentation at any > opportunity. Nearly all of it is much too long. It would be much better > to state the facts in a few bullet points, and move the discussion of > rationale and history to a dedicated subsection so readers just wanting > the facts can easily skip that part. I've had a go, see staging/. Feel free to take it from here. > > What do you propose to do about the rule that changes to tools/ or > > bindings/ require 1×+1 and 1×+0? It would be odd if changes to tools/ > > required more votes than changes to core. > > Good catch. Should require just one +1 vote (removing the additional +0 > vote). While editing on staging/ I noticed there was an explicit bit of rationale there about getting two pairs of eyes on every change. I guess you should change that part too (make it applicable to LTS lines only)? Or alternatively, require at least a +1 and a +0 on core changes to non-LTS lines. Cheers, Daniel
Re: Change to Subversion PMC rule for approving backports
On Fri, Aug 30, 2019 at 2:54 AM Julian Foad wrote: > I strongly urge that we simplify any and all of our documentation at any > opportunity. Nearly all of it is much too long. It would be much better > to state the facts in a few bullet points, and move the discussion of > rationale and history to a dedicated subsection so readers just wanting > the facts can easily skip that part. > Which document would you consider most important to fix the soonest?
Re: Change to Subversion PMC rule for approving backports
Daniel Shahaf wrote: Julian Foad wrote on Thu, 29 Aug 2019 15:36 +00:00: To all devs: Proposal for a permanent change to our backport rules [1]: * For non-LTS releases, each backport nomination only requires one +1 vote (instead of three). Specific diff to the text of [1]: - A change needs three +1 votes from full committers (or partial committers for the involved areas), and no vetoes, to go into A.B.x. + A change needs three +1 votes (for an LTS release line) or one +1 vote (for a non-LTS release line) from full committers (or partial committers for the involved areas), and no vetoes, to go into A.B.x. - (If a change affects the build system, however, it is considered a core change, and needs three +1's.) + (If a change affects the build system, however, it is considered a core change, and so for an LTS release line needs three +1's.) Agreements? What do you propose to do about the rule that changes to tools/ or bindings/ require 1×+1 and 1×+0? It would be odd if changes to tools/ required more votes than changes to core. Good catch. Should require just one +1 vote (removing the additional +0 vote). I think that section as it stands (before your change) is pretty hard to follow: it jumps back and forth between different topics. I might take a shot at clarifying it (without semantic changes), if that won't conflict with patches you have in flight. Yes please! I strongly urge that we simplify any and all of our documentation at any opportunity. Nearly all of it is much too long. It would be much better to state the facts in a few bullet points, and move the discussion of rationale and history to a dedicated subsection so readers just wanting the facts can easily skip that part. - Julian
Re: Change to Subversion PMC rule for approving backports
Julian Foad wrote on Thu, 29 Aug 2019 15:36 +00:00: > To all devs: > > Proposal for a permanent change to our backport rules [1]: > >* For non-LTS releases, each backport nomination only requires one +1 > vote (instead of three). > > Specific diff to the text of [1]: > > - A change needs three +1 votes from full committers (or partial > committers for the involved areas), and no vetoes, to go into A.B.x. > + A change needs three +1 votes (for an LTS release line) or one +1 vote > (for a non-LTS release line) from full committers (or partial committers > for the involved areas), and no vetoes, to go into A.B.x. > > - (If a change affects the build system, however, it is considered a > core change, and needs three +1's.) > + (If a change affects the build system, however, it is considered a > core change, and so for an LTS release line needs three +1's.) > > Agreements? What do you propose to do about the rule that changes to tools/ or bindings/ require 1×+1 and 1×+0? It would be odd if changes to tools/ required more votes than changes to core. I think that section as it stands (before your change) is pretty hard to follow: it jumps back and forth between different topics. I might take a shot at clarifying it (without semantic changes), if that won't conflict with patches you have in flight. Cheers, Daniel
Re: Change to Subversion PMC rule for approving backports
Nathan Hartman wrote: + A change needs three +1 votes (for an LTS release line) or one +1 vote (for a non-LTS release line) from full committers (or partial committers for the involved areas), and no vetoes, to go into A.B.x. snip - (If a change affects the build system, however, it is considered a core change, and needs three +1's.) + (If a change affects the build system, however, it is considered a core change, and so for an LTS release line needs three +1's.) Just proofreading... Is this 2nd change correct or was the intention three +1s for build system changes regardless if LTS or not? It's correct... I'm asking because the 1st change already says that changes to LTS require three +1s. I quoted it here out of its context. In its context it makes sense. - Julian
Re: Change to Subversion PMC rule for approving backports
On Thu, Aug 29, 2019 at 11:36 AM Julian Foad wrote: > > + A change needs three +1 votes (for an LTS release line) or one +1 vote > (for a non-LTS release line) from full committers (or partial committers > for the involved areas), and no vetoes, to go into A.B.x. snip - (If a change affects the build system, however, it is considered a > core change, and needs three +1's.) > + (If a change affects the build system, however, it is considered a > core change, and so for an LTS release line needs three +1's.) Just proofreading... Is this 2nd change correct or was the intention three +1s for build system changes regardless if LTS or not? I'm asking because the 1st change already says that changes to LTS require three +1s.
Re: Change to Subversion PMC rule for approving backports
On Thu, Aug 29, 2019 at 11:36 AM Julian Foad wrote: > To all devs: > > Proposal for a permanent change to our backport rules [1]: > >* For non-LTS releases, each backport nomination only requires one +1 > vote (instead of three). > > Specific diff to the text of [1]: > > - A change needs three +1 votes from full committers (or partial > committers for the involved areas), and no vetoes, to go into A.B.x. > + A change needs three +1 votes (for an LTS release line) or one +1 vote > (for a non-LTS release line) from full committers (or partial committers > for the involved areas), and no vetoes, to go into A.B.x. > > - (If a change affects the build system, however, it is considered a > core change, and needs three +1's.) > + (If a change affects the build system, however, it is considered a > core change, and so for an LTS release line needs three +1's.) > > Agreements? > > Makes sense, +1 -- Thanks Mark Phippard
Re: Change to Subversion PMC rule for approving backports
To all devs: Proposal for a permanent change to our backport rules [1]: * For non-LTS releases, each backport nomination only requires one +1 vote (instead of three). Specific diff to the text of [1]: - A change needs three +1 votes from full committers (or partial committers for the involved areas), and no vetoes, to go into A.B.x. + A change needs three +1 votes (for an LTS release line) or one +1 vote (for a non-LTS release line) from full committers (or partial committers for the involved areas), and no vetoes, to go into A.B.x. - (If a change affects the build system, however, it is considered a core change, and needs three +1's.) + (If a change affects the build system, however, it is considered a core change, and so for an LTS release line needs three +1's.) Agreements? [1] http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization - Julian Branko Čibej wrote: On 18.07.2019 14:09, Julian Foad wrote: Recently there have not been enough developers willing and able to test and approve proposed fixes for back-port to the supported release branches. We have just been discussing this on #svn-dev [1]. Rather than delay forever, myself, stsp and brane decided that in line with "silence implies consent", we can go ahead with merging the proposed backports even if they have fewer than 3 votes. We will go ahead now. Thanks for the heads-up, Julian, and for pushing the releases. [...]
Re: Change to Subversion PMC rule for approving backports
On 18.07.2019 14:09, Julian Foad wrote: > Recently there have not been enough developers willing and able to > test and approve proposed fixes for back-port to the supported release > branches. > > We have just been discussing this on #svn-dev [1]. Rather than delay > forever, myself, stsp and brane decided that in line with "silence > implies consent", we can go ahead with merging the proposed backports > even if they have fewer than 3 votes. > > We will go ahead now. Thanks for the heads-up, Julian, and for pushing the releases. Sorry for not taking more time to review the backports. FWIW, I don't think there was anything controversial in the proposals, just ... boring paperwork. :) -- Brane
Change to Subversion PMC rule for approving backports
Recently there have not been enough developers willing and able to test and approve proposed fixes for back-port to the supported release branches. We have just been discussing this on #svn-dev [1]. Rather than delay forever, myself, stsp and brane decided that in line with "silence implies consent", we can go ahead with merging the proposed backports even if they have fewer than 3 votes. We will go ahead now. [1] discussion around https://colabti.org/irclogger/irclogger_log/svn-dev?date=2019-07-18#l80 - Julian
