Change to Subversion PMC rule for approving backports

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Change to Subversion PMC rule for approving backports

Julian Foad-5
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

Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Branko Čibej
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

Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Julian Foad-5
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. [...]
Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Nathan Hartman
On Thu, Aug 29, 2019 at 11:36 AM Julian Foad <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Mark Phippard-3
In reply to this post by Julian Foad-5
On Thu, Aug 29, 2019 at 11:36 AM Julian Foad <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Julian Foad-5
In reply to this post by Nathan Hartman
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
Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Daniel Shahaf-2
In reply to this post by Julian Foad-5
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
Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Julian Foad-5
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

Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Nathan Hartman
On Fri, Aug 30, 2019 at 2:54 AM Julian Foad <[hidden email]> 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?

Reply | Threaded
Open this post in threaded view
|

Simplifying our documentation

Julian Foad-5
(Updated subject)

Nathan Hartman wrote in thread "Change to Subversion PMC rule for
approving backports":
> 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?

In line with current transition to emphasise stabilization and
availability, I suppose these user-facing docs should take priority:

   * finding/downloading/installing svn from *binaries*:
     - http://subversion.apache.org/packages

   * how to contact us; reduce/combine some of these?
     - http://subversion.apache.org/reporting-issues
     - http://subversion.apache.org/docs/community-guide/issues
     - http://subversion.apache.org/mailing-lists
     - http://subversion.apache.org/docs/community-guide/mailing-lists
     - http://subversion.apache.org/faq#more-information
     - http://subversion.apache.org/security/

   * and the home page should make those things extremely easy to find:
     - http://subversion.apache.org/

If you or anyone wants to help, I think any of those would be an
excellent place to do so.

The various contact info is particularly scattered, and pointers often
state "users@" email with no hint of the IRC/Matrix alternative. Could
we make a good "contact us" landing page which directs users
appropriately to all forms of contact?

- Julian
Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Daniel Shahaf-2
In reply to this post by Julian Foad-5
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
Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Julian Foad-5
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
Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Julian Foad-5
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

[[[
-<p>A change is approved if it receives three +1s and no vetoes.  (Only
-binding votes count; see above.)</p>
+<p>For a non-LTS ("regular") release line, a change is approved if it
+receives one binding +1 vote and no vetoes.</p>
 
-<p>Notwithstanding the above, a change that affects only areas that are not
+<p>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 <em>not</em> affect the build system,
 can go in with a +1 from a full committer or a
]]]

committed:
  http://svn.apache.org/r1866313


- Julian
Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Julian Foad-5
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:

[[[
+<p><b>For a non-LTS ("regular") release line</b></p>
+
+<p>A change is approved if it receives one +1 vote and no vetoes.  (Only
+binding votes count; see above.)</p>
+
+<p><b>For an LTS release line</b></p>
+
 <p>A change is approved if it receives three +1s and no vetoes.  (Only

]]]

- Julian
Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Bert Huijben-5
In reply to this post by Julian Foad-5
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 <[hidden email]> 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. [...]
Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Julian Foad-5


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





Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

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. 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

Reply | Threaded
Open this post in threaded view
|

Re: Change to Subversion PMC rule for approving backports

Julian Foad-6


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

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying our documentation

Nathan Hartman
In reply to this post by Julian Foad-5
On Fri, Aug 30, 2019 at 11:09 AM Julian Foad <[hidden email]> wrote:
> Nathan Hartman wrote in thread "Change to Subversion PMC rule for
> approving backports":
> > 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?
>
> In line with current transition to emphasise stabilization and
> availability, I suppose these user-facing docs should take priority:
>
>    * finding/downloading/installing svn from *binaries*:
>      - http://subversion.apache.org/packages
>
>    * how to contact us; reduce/combine some of these?
>      - http://subversion.apache.org/reporting-issues
>      - http://subversion.apache.org/docs/community-guide/issues
>      - http://subversion.apache.org/mailing-lists
>      - http://subversion.apache.org/docs/community-guide/mailing-lists
>      - http://subversion.apache.org/faq#more-information
>      - http://subversion.apache.org/security/
>
>    * and the home page should make those things extremely easy to find:
>      - http://subversion.apache.org/
>
> If you or anyone wants to help, I think any of those would be an
> excellent place to do so.
>
> The various contact info is particularly scattered, and pointers often
> state "users@" email with no hint of the IRC/Matrix alternative. Could
> we make a good "contact us" landing page which directs users
> appropriately to all forms of contact?

I've been studying the site and there is a site-ng branch created 2015. I remember a discussion about it around that time but I can't find it in the archives now.

Since there are no commits on site-ng beyond branch creation / readme, would it be agreeable if I catch it up to the present and use it?

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying our documentation

Julian Foad-5

Nathan Hartman wrote:
> I've been studying the site and there is a site-ng branch created 2015. I remember a discussion about it around that time but I can't find it in the archives now.
> Since there are no commits on site-ng beyond branch creation / readme, would it be agreeable if I catch it up to the present and use it?
 
It would be better to use the site/staging branch which you can find alongside site/publish and which is served at http://subversion-staging.apache.org
 
- Julian





12