svn commit: r1900566 - in /subversion/site/publish: ./ docs/community-guide/releasing.part.html docs/community-guide/roles.part.html docs/release-notes/1.8.html
Author: dsahlberg Date: Wed May 4 21:16:38 2022 New Revision: 1900566 URL: http://svn.apache.org/viewvc?rev=1900566=rev Log: Merge 1899393, 1899419, 1899468, 1900565 site/staging * publish/docs/community-guide/releasing.part.html (#backport-merge-bot): Document new svn-qavm2 * publish/docs/community-guide/roles.part.html (#partial-commit-access): Fix typo * publish/docs/release-notes/1.8.html (#fsfs-stats): Fix typo Modified: subversion/site/publish/ (props changed) subversion/site/publish/docs/community-guide/releasing.part.html subversion/site/publish/docs/community-guide/roles.part.html subversion/site/publish/docs/release-notes/1.8.html Propchange: subversion/site/publish/ -- Merged /subversion/site/staging:r1899393,1899419,1899468,1900565 Modified: subversion/site/publish/docs/community-guide/releasing.part.html URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/community-guide/releasing.part.html?rev=1900566=1900565=1900566=diff == --- subversion/site/publish/docs/community-guide/releasing.part.html (original) +++ subversion/site/publish/docs/community-guide/releasing.part.html Wed May 4 21:16:38 2022 @@ -1631,7 +1631,7 @@ using release.py to automate most of the #backport-merge-bot" title="Link to this section"> -The backport merge bot runs nightly on the svn-qavm machine, +The backport merge bot runs nightly on the svn-qavm2 machine, under the svnsvn local user account, making commits using the svn-role Subversion account name. This configuration currently requires someone with admin access to @@ -1659,10 +1659,11 @@ sudo -H -u svnsvn svn up ~svnsvn/src/sv sudo -H -u svnsvn svn up -r0 ~svnsvn/src/svn/Z.Z.x -[Historical notes can be found in machines/svn-qavm/ and - machines/svn-qavm2/ in the Subversion PMC's +More notes on the setup can be found in machines/svn-qavm2/ and + in the Subversion PMC's https://svn.apache.org/repos/private/pmc/subversion;> - private repository.] + private repository. There are also historical notes on previous + incarnations in the history of machines/. Modified: subversion/site/publish/docs/community-guide/roles.part.html URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/community-guide/roles.part.html?rev=1900566=1900565=1900566=diff == --- subversion/site/publish/docs/community-guide/roles.part.html (original) +++ subversion/site/publish/docs/community-guide/roles.part.html Wed May 4 21:16:38 2022 @@ -85,7 +85,7 @@ means the full committer has applied sev from the proposed partial committer, and realizes things would be easier if the person were just committing directly. It is customary and recommended for the sponsor to float the prospect by private@ before -issueing an invitation, but not required; sponsors are trusted to use +issuing an invitation, but not required; sponsors are trusted to use good judgement. The sponsor watches the partial committer's first few commits to ensure Modified: subversion/site/publish/docs/release-notes/1.8.html URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/1.8.html?rev=1900566=1900565=1900566=diff == --- subversion/site/publish/docs/release-notes/1.8.html (original) +++ subversion/site/publish/docs/release-notes/1.8.html Wed May 4 21:16:38 2022 @@ -1458,7 +1458,7 @@ The statistics include: Administrators may use this information to decide whether directory deltification should be enabled (ratio of directory representation vs. file representation sizes) or whether commit policies might to -be revised (e.g. large .zip files accout for most of the repository). +be revised (e.g. large .zip files account for most of the repository). Some of the data, however, is useful for performance analysis by SVN developers only.
svn commit: r1900565 - /subversion/site/staging/docs/community-guide/releasing.part.html
Author: dsahlberg Date: Wed May 4 21:13:22 2022 New Revision: 1900565 URL: http://svn.apache.org/viewvc?rev=1900565=rev Log: In site/staging: * docs/community-guide/releasing.part.html (#backport-merge-bot): The machine is svn-qavm2. It was not possible to rename it. See mail in private@ https://lists.apache.org/thread/qb4v1pzynvbxwc1mkqhk7fnc9br4b3ql Modified: subversion/site/staging/docs/community-guide/releasing.part.html Modified: subversion/site/staging/docs/community-guide/releasing.part.html URL: http://svn.apache.org/viewvc/subversion/site/staging/docs/community-guide/releasing.part.html?rev=1900565=1900564=1900565=diff == --- subversion/site/staging/docs/community-guide/releasing.part.html (original) +++ subversion/site/staging/docs/community-guide/releasing.part.html Wed May 4 21:13:22 2022 @@ -1635,7 +1635,7 @@ using release.py to automate most of the #backport-merge-bot" title="Link to this section"> -The backport merge bot runs nightly on the svn-qavm machine, +The backport merge bot runs nightly on the svn-qavm2 machine, under the svnsvn local user account, making commits using the svn-role Subversion account name. This configuration currently requires someone with admin access to @@ -1663,7 +1663,7 @@ sudo -H -u svnsvn svn up ~svnsvn/src/sv sudo -H -u svnsvn svn up -r0 ~svnsvn/src/svn/Z.Z.x -More notes on the setup can be found in machines/svn-qavm/ and +More notes on the setup can be found in machines/svn-qavm2/ and in the Subversion PMC's https://svn.apache.org/repos/private/pmc/subversion;> private repository. There are also historical notes on previous
Re: svn commit: r1900404 - in /subversion/site/staging: docs/community-guide/releasing.part.html roadmap.html
Den tis 3 maj 2022 kl 22:39 skrev Daniel Sahlberg < daniel.l.sahlb...@gmail.com>: > Den mån 2 maj 2022 23:01Daniel Shahaf skrev: > >> Daniel Sahlberg wrote on Mon, 02 May 2022 20:12 +00:00: >> > Thanks to everyone for discussing this and moving it forward! I'm sorry >> I >> > wasn't able to be more active last week but life got in the way. >> > >> > One small point below... >> > >> > Den lör 30 apr. 2022 kl 00:04 skrev : >> > [...] >> > >> >> +LTS releases are supported for four years from the date >> of >> >> their >> >> +initial release. For instance, 1.15.x will supported until four years >> >> after >> >> +the announcement of 1.15.0. >> >> >> > >> > Should we really declare 1.15 an LTS release at this stage? >> >> No. Deciding whether 1.15 should be LTS or Regular deserves a thread of >> its own. As far as this thread is concerned, the documentation should >> reflect the status quo: that it has not been decided yet whether 1.15 >> will be LTS or Regular. >> >> Good catch. >> >> If someone could please update the text staging/ that would be great. >> > > r1900528 > > >> > I would also suggest to remove the "Transition to LTS and Regular >> > Releases" >> > section ( >> > >> https://subversion-staging.apache.org/roadmap.html#transition-lts-regular-releases >> ) >> > since it seems to concern the fixed-time release schedule. I can do >> > this, >> > just wanting to check that I don't missread something. >> >> The description of what we backport is "general backports and thereafter >> high priority fixes" in this section, and "high priority issues such as >> … and sometimes also other issues" in the section above. We might want >> to clarify the "other issues" part of the latter sentence when we delete >> this section. >> > > Oh. I read this too quick and skipped over this part of the mail in the > commit above. I'll circle back on this tomorrow. > r1900561. I mostly copied from the old text describing why to do regular releases, while reusing the old rules what kind of backports should go into "lastest" and "older" releases. > >> Also, might want to explicitly spell out that 1.10 is now EOL: someone >> might think that 1.10 would be supported with security fixes until the >> LTS _after 1.14_ is released, as that would have been the case under our >> pre-1.11 policy if there hadn't been Regular releases at all. >> > > Did we reach consensus on this yet? Of course it follows the new policy, > on the other hand 1.10 predates even the fixed time release policy. > > >> Also, to answer your question in the OP, we'll want to remove 1.10 from >> the download page and from dist/release/. >> > > Will do, after some input on the point above. > > >> Cheers, >> >> Daniel >> >
svn commit: r1900562 - /subversion/site/staging/roadmap.html
Author: dsahlberg Date: Wed May 4 20:07:27 2022 New Revision: 1900562 URL: http://svn.apache.org/viewvc?rev=1900562=rev Log: Followup to r1900561 * roadmap.html (#release-planning): We use double space between sentences Modified: subversion/site/staging/roadmap.html Modified: subversion/site/staging/roadmap.html URL: http://svn.apache.org/viewvc/subversion/site/staging/roadmap.html?rev=1900562=1900561=1900562=diff == --- subversion/site/staging/roadmap.html (original) +++ subversion/site/staging/roadmap.html Wed May 4 20:07:27 2022 @@ -97,7 +97,7 @@ Regular releases are supported for six months from the date of their initial release. For instance, 1.11.x was supported until six months -after the announcement of 1.11.0. A regular release may be used to get new +after the announcement of 1.11.0. A regular release may be used to get new features out sooner without having to support a particular release for an extended period of time, to make feature development more appealing, rewarding and faster for both the contributors and the users.
svn commit: r1900561 - /subversion/site/staging/roadmap.html
Author: dsahlberg Date: Wed May 4 20:03:56 2022 New Revision: 1900561 URL: http://svn.apache.org/viewvc?rev=1900561=rev Log: Recover part of the text removed in r1900528 describing the difference between Regular and LTS releases. * roadmap.html (#release-planning): As above... Modified: subversion/site/staging/roadmap.html Modified: subversion/site/staging/roadmap.html URL: http://svn.apache.org/viewvc/subversion/site/staging/roadmap.html?rev=1900561=1900560=1900561=diff == --- subversion/site/staging/roadmap.html (original) +++ subversion/site/staging/roadmap.html Wed May 4 20:03:56 2022 @@ -97,7 +97,10 @@ Regular releases are supported for six months from the date of their initial release. For instance, 1.11.x was supported until six months -after the announcement of 1.11.0. +after the announcement of 1.11.0. A regular release may be used to get new +features out sooner without having to support a particular release for an +extended period of time, to make feature development more appealing, rewarding +and faster for both the contributors and the users. LTS releases are supported for four years from the date of their initial release. For instance, 1.14.x will be supported until four years after @@ -119,7 +122,9 @@ months for upgrading installations. In until, say, 2048-01-01, the lifetime of 1.42 will automatically be extended until 2048-03-31. -At any given time there will be at least one supported LTS release. +At any given time there will be at least one supported LTS release. The +most current LTS release will be supported with general backports and any +older release(s) will receive high priority fixes.
