You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@apache.org> on 2019/07/18 12:09:20 UTC
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
Re: Change to Subversion PMC rule for approving backports
Posted by Julian Foad <ju...@apache.org>.
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
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Aug 29, 2019 at 11:36 AM Julian Foad <ju...@apache.org> 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
Posted by Bert Huijben <be...@qqmail.nl>.
+1 Thanks Julian!
On Tue, Sep 17, 2019 at 5:11 PM Branko Čibej <br...@apache.org> 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
Posted by Branko Čibej <br...@apache.org>.
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
Posted by Julian Foad <ju...@apache.org>.
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
Posted by Julian Foad <ju...@foad.me.uk>.
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
Posted by Branko Čibej <br...@apache.org>.
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
Posted by Julian Foad <ju...@apache.org>.
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
Posted by Bert Huijben <be...@qqmail.nl>.
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 <ju...@apache.org> 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
Posted by Julian Foad <ju...@apache.org>.
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
Re: Change to Subversion PMC rule for approving backports
Posted by Julian Foad <ju...@apache.org>.
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
Re: Change to Subversion PMC rule for approving backports
Posted by Julian Foad <ju...@apache.org>.
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
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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: Simplifying our documentation
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Sep 13, 2019 at 8:18 AM Branko Čibej <br...@apache.org> wrote:
> On 13.09.2019 14:16, Nathan Hartman wrote:
>> If there are no objections I'll remove site-ng and create a branch
>> from staging called staging-ng. I think it should be under site,
>> adjacent to staging and publish, and not under subversion root?
>
> Yes, that's correct.
Deleted site-ng in r1866904.
Added site/staging-ng in r1866905.
Re: Simplifying our documentation
Posted by Branko Čibej <br...@apache.org>.
On 13.09.2019 14:16, Nathan Hartman wrote:
> On Fri, Sep 13, 2019 at 3:08 AM Branko Čibej <brane@apache.org
> <ma...@apache.org>> wrote:
>
> On 13.09.2019 09:00, Julian Foad wrote:
> > Nathan Hartman wrote:
> >> Once there's actually something to show we can cross the bridge
> of either asking Infra (nicely of course) or moving it to a
> subdirectory of staging, with a link to coming soon, preview the
> new site. But let's not get ahead of ourselves.
> >
> > That all sounds good. Just one thing: a new branch that is a
> sibling of 'publish' and 'staging' would seem to be the right
> level. The existing 'site-ng' branch contains virtual copies of
> both, which seems the wrong level, and also catching up and
> re-purposing an old branch makes slightly confusing (and slightly
> inefficient) history. Create a new one!
>
> Yes indeed ... and maybe even create a copy of staging/, not publish/,
> to make future merge history clearer.
>
> -- Brane
>
> Yes. I reached this conclusion also when I ran the merge and realized
> that this is a branch that contains branches. So I didn't commit that
> mess.
>
> If there are no objections I'll remove site-ng and create a branch
> from staging called staging-ng. I think it should be under site,
> adjacent to staging and publish, and not under subversion root?
Yes, that's correct.
-- Brane
Re: Simplifying our documentation
Posted by Nathan Hartman <ha...@gmail.com>.
On Sun, Sep 29, 2019 at 11:56 AM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> Nathan Hartman wrote on Sun, 29 Sep 2019 15:48 +00:00:
> > html5boilerplate is under a MIT license:
> > https://github.com/h5bp/html5-boilerplate/blob/master/LICENSE.txt
> >
> > Can this (or snippets from it) be used for Subversion's website?
>
> Yes. https://www.apache.org/legal/resolved#category-a
Thank you.
Re: Simplifying our documentation
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Sun, 29 Sep 2019 15:48 +00:00:
> html5boilerplate is under a MIT license:
> https://github.com/h5bp/html5-boilerplate/blob/master/LICENSE.txt
>
> Can this (or snippets from it) be used for Subversion's website?
Yes. https://www.apache.org/legal/resolved#category-a
Re: Simplifying our documentation
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Sep 13, 2019 at 9:40 AM Nathan Hartman <ha...@gmail.com> wrote:
> Deleted site-ng in r1866904.
>
> Added site/staging-ng in r1866905.Regarding the site/staging-ng branch:
Regarding the site/staging-ng branch:
In the past, I've used two files from html5boilerplate.com:
normalize.css and main.css for other projects.
html5boilerplate is under a MIT license:
https://github.com/h5bp/html5-boilerplate/blob/master/LICENSE.txt
Can this (or snippets from it) be used for Subversion's website?
(Asking because one of my objectives is better display on mobile.)
Matrix [was: Simplifying our documentation]
Posted by Julian Foad <ju...@apache.org>.
Nathan Hartman wrote:
> Are you on Matrix or IRC? [...]
>
> Haven't reached my desk yet today. I'm emailing from my phone. :-)
>
> <https://matrix.to/#/%23freenode_%23svn-dev:matrix.org>
No problem: these Matrix clients work well on mobile:
https://f-droid.org/repository/browse/?fdid=im.vector.alpha
https://play.google.com/store/apps/details?id=im.vector.app
https://itunes.apple.com/us/app/vector.im/id1083446067
- Julian
Re: Simplifying our documentation
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Sep 13, 2019 at 8:21 AM Julian Foad <ju...@foad.me.uk> wrote:
> Are you on Matrix or IRC? It's easier to continue this kind of
> conversation there, if you are. Freenode #svn-dev, or
> https://matrix.to/#/#freenode_#svn-dev:matrix.org
Haven't reached my desk yet today. I'm emailing from my phone. :-)
<https://matrix.to/#/%23freenode_%23svn-dev:matrix.org>
Re: Simplifying our documentation
Posted by Julian Foad <ju...@foad.me.uk>.
Nathan Hartman wrote:
> If there are no objections I'll remove site-ng and create a branch from
> staging called staging-ng. I think it should be under site, adjacent to
> staging and publish, and not under subversion root?
Are you on Matrix or IRC? It's easier to continue this kind of
conversation there, if you are. Freenode #svn-dev, or
https://matrix.to/#/#freenode_#svn-dev:matrix.org
- Julian
Re: Simplifying our documentation
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Sep 13, 2019 at 3:08 AM Branko Čibej <br...@apache.org> wrote:
> On 13.09.2019 09:00, Julian Foad wrote:
> > Nathan Hartman wrote:
> >> Once there's actually something to show we can cross the bridge of
> either asking Infra (nicely of course) or moving it to a subdirectory of
> staging, with a link to coming soon, preview the new site. But let's not
> get ahead of ourselves.
> >
> > That all sounds good. Just one thing: a new branch that is a sibling of
> 'publish' and 'staging' would seem to be the right level. The existing
> 'site-ng' branch contains virtual copies of both, which seems the wrong
> level, and also catching up and re-purposing an old branch makes slightly
> confusing (and slightly inefficient) history. Create a new one!
>
> Yes indeed ... and maybe even create a copy of staging/, not publish/,
> to make future merge history clearer.
>
> -- Brane
>
> Yes. I reached this conclusion also when I ran the merge and realized that
this is a branch that contains branches. So I didn't commit that mess.
If there are no objections I'll remove site-ng and create a branch from
staging called staging-ng. I think it should be under site, adjacent to
staging and publish, and not under subversion root?
Re: Simplifying our documentation
Posted by Branko Čibej <br...@apache.org>.
On 13.09.2019 09:00, Julian Foad wrote:
> Nathan Hartman wrote:
>> Once there's actually something to show we can cross the bridge of either asking Infra (nicely of course) or moving it to a subdirectory of staging, with a link to coming soon, preview the new site. But let's not get ahead of ourselves.
>
> That all sounds good. Just one thing: a new branch that is a sibling of 'publish' and 'staging' would seem to be the right level. The existing 'site-ng' branch contains virtual copies of both, which seems the wrong level, and also catching up and re-purposing an old branch makes slightly confusing (and slightly inefficient) history. Create a new one!
Yes indeed ... and maybe even create a copy of staging/, not publish/,
to make future merge history clearer.
-- Brane
Re: Simplifying our documentation
Posted by Julian Foad <ju...@foad.me.uk>.
Nathan Hartman wrote:
> Once there's actually something to show we can cross the bridge of either asking Infra (nicely of course) or moving it to a subdirectory of staging, with a link to coming soon, preview the new site. But let's not get ahead of ourselves.
That all sounds good. Just one thing: a new branch that is a sibling of 'publish' and 'staging' would seem to be the right level. The existing 'site-ng' branch contains virtual copies of both, which seems the wrong level, and also catching up and re-purposing an old branch makes slightly confusing (and slightly inefficient) history. Create a new one!
- Julian
Sent with FairEmail [https://email.faircode.eu/] , an open source, privacy friendly email app for Android
Re: Simplifying our documentation
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Sep 12, 2019 at 10:45 PM Branko Čibej <br...@apache.org> wrote:
> On 13.09.2019 04:18, Nathan Hartman wrote:
> > On Thu, Sep 12, 2019 at 3:12 AM Branko Čibej <brane@apache.org
> > <ma...@apache.org>> wrote:
> >
> > On 12.09.2019 05:00, 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?
> >
> > site-ng was a misguided attempt at changing how our site
> > implementation
> > works (from server-side includes to generated static pages). If we
> > ever
> > do that overhaul, we'll probably use the new templating automation
> > that
> > Infra is working on.
> >
> > I'd prefer to *delete* the site-ng branch. The staging branch is
> there
> > for preparing content changes.
> >
> > -- Brane
> >
> >
> > I know about staging and it's convenient that it's served. But I'd
> > like to experiment without worrying about breaking things. I hope to
> > achieve three things:
> >
> > * Reorganize the information so visitors find what they want with
> > minimal reading and searching
> >
> > * A more modern look
> >
> > * Improve display on mobile phones
> >
> > I'd like to emphasize that I am *not* thinking about changing the
> > implementation (SSI vs something else) at this time. Nor am I thinking
> > about removing or rewriting the text. The information we have on the
> > site is good and thorough. I just want to reorganize it and make a
> > good first impression on visitors with an attractive home page -- and
> > make sure we're all happy with it before it moves to staging.
>
> Oh, then sure, either use site-ng or create another branch, whatever
> suits you best. The only (minor) issue is that you'll have to cook up a
> local server for testing. Or of course we could ask Infra nicely to
> publish yet another branch of our site.
>
> -- Brane
That's the easy part. I have a virtual machine with a LAMP stack. :-)
Once there's actually something to show we can cross the bridge of either
asking Infra (nicely of course) or moving it to a subdirectory of staging,
with a link to coming soon, preview the new site. But let's not get ahead
of ourselves.
Re: Simplifying our documentation
Posted by Branko Čibej <br...@apache.org>.
On 13.09.2019 04:18, Nathan Hartman wrote:
> On Thu, Sep 12, 2019 at 3:12 AM Branko Čibej <brane@apache.org
> <ma...@apache.org>> wrote:
>
> On 12.09.2019 05:00, 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?
>
> site-ng was a misguided attempt at changing how our site
> implementation
> works (from server-side includes to generated static pages). If we
> ever
> do that overhaul, we'll probably use the new templating automation
> that
> Infra is working on.
>
> I'd prefer to *delete* the site-ng branch. The staging branch is there
> for preparing content changes.
>
> -- Brane
>
>
> I know about staging and it's convenient that it's served. But I'd
> like to experiment without worrying about breaking things. I hope to
> achieve three things:
>
> * Reorganize the information so visitors find what they want with
> minimal reading and searching
>
> * A more modern look
>
> * Improve display on mobile phones
>
> I'd like to emphasize that I am *not* thinking about changing the
> implementation (SSI vs something else) at this time. Nor am I thinking
> about removing or rewriting the text. The information we have on the
> site is good and thorough. I just want to reorganize it and make a
> good first impression on visitors with an attractive home page -- and
> make sure we're all happy with it before it moves to staging.
Oh, then sure, either use site-ng or create another branch, whatever
suits you best. The only (minor) issue is that you'll have to cook up a
local server for testing. Or of course we could ask Infra nicely to
publish yet another branch of our site.
-- Brane
Re: Simplifying our documentation
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Sep 12, 2019 at 3:12 AM Branko Čibej <br...@apache.org> wrote:
> On 12.09.2019 05:00, 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?
>
> site-ng was a misguided attempt at changing how our site implementation
> works (from server-side includes to generated static pages). If we ever
> do that overhaul, we'll probably use the new templating automation that
> Infra is working on.
>
> I'd prefer to *delete* the site-ng branch. The staging branch is there
> for preparing content changes.
>
> -- Brane
I know about staging and it's convenient that it's served. But I'd like to
experiment without worrying about breaking things. I hope to achieve three
things:
* Reorganize the information so visitors find what they want with minimal
reading and searching
* A more modern look
* Improve display on mobile phones
I'd like to emphasize that I am *not* thinking about changing the
implementation (SSI vs something else) at this time. Nor am I thinking
about removing or rewriting the text. The information we have on the site
is good and thorough. I just want to reorganize it and make a good first
impression on visitors with an attractive home page -- and make sure we're
all happy with it before it moves to staging.
Thoughts?
Re: Simplifying our documentation
Posted by Branko Čibej <br...@apache.org>.
On 12.09.2019 05:00, Nathan Hartman wrote:
> On Fri, Aug 30, 2019 at 11:09 AM Julian Foad <julianfoad@apache.org
> <ma...@apache.org>> 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?
site-ng was a misguided attempt at changing how our site implementation
works (from server-side includes to generated static pages). If we ever
do that overhaul, we'll probably use the new templating automation that
Infra is working on.
I'd prefer to *delete* the site-ng branch. The staging branch is there
for preparing content changes.
-- Brane
Re: Simplifying our documentation
Posted by Julian Foad <ju...@apache.org>.
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
Re: Simplifying our documentation
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Aug 30, 2019 at 11:09 AM Julian Foad <ju...@apache.org> 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?
Simplifying our documentation
Posted by Julian Foad <ju...@apache.org>.
(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
Re: Change to Subversion PMC rule for approving backports
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Aug 30, 2019 at 2:54 AM Julian Foad <ju...@apache.org> 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
Posted by Julian Foad <ju...@apache.org>.
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
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Aug 29, 2019 at 11:36 AM Julian Foad <ju...@apache.org> 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
Posted by Julian Foad <ju...@apache.org>.
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
Posted by Branko Čibej <br...@apache.org>.
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