Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
Den ons 17 feb. 2021 19:42Daniel Shahaf skrev: > Daniel Sahlberg wrote on Wed, Feb 17, 2021 at 09:46:54 +0100: > > Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf < > d...@daniel.shahaf.name>: > > > Is it worthwhile to automate this step? doap.rdf changes rarely enough > > > that we needn't bother with "edit part of a file" logic; we can just > > > regenerate the entire file and «svnmucc put» it into place, with a > > > comment indicating it's a generated file. > > > > The doap.rdf contain references to two separate releases (at least > > right now) and when running release.py you are working on one release > > at a time. So we can't just have a template and add the current > > release number, we also need to know the other release (which could > > have been a year ago or the same day). > > Well, yes, and «release.py clean-dist» already has logic to determine > the other release's version number. > > > To automate "edit part of file", we would need to search for the same > > major.minor and replace with current relase, but when there is a new > > minor (1.15..) we would have to edit manually anyway. > > I don't think so. > > We could generate subversion-%(version)s.rdf-excerpt files, drop them in > dist/, and then use clean_dist()-like logic to cat the right subset of > them, adding a fixed header and trailer. This way, we wouldn't need to > splice lines out of and into the file, and we wouldn't need to special-case > the first release of a minor line or the EOLing of a minor line in the > logic. > > > It's a balance between the amount of work done by RM, the downside of > > having different processes for new minor and new patch release and the > > work to code to automate. I'm leaning towards having it as it is, but > > I would listen to Stefan's opinion (since he did the most recent RM). > > By and large, agreed, but see above for the details. > All this sounds good. However I'm not fluent in Python and even though learning is on my to-do, it is not high enough right now so I'll leave it to someone else. Kind regards Daniel Sahlberg >
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
Daniel Sahlberg wrote on Wed, Feb 17, 2021 at 09:46:54 +0100: > Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf : > > Is it worthwhile to automate this step? doap.rdf changes rarely enough > > that we needn't bother with "edit part of a file" logic; we can just > > regenerate the entire file and «svnmucc put» it into place, with a > > comment indicating it's a generated file. > > The doap.rdf contain references to two separate releases (at least > right now) and when running release.py you are working on one release > at a time. So we can't just have a template and add the current > release number, we also need to know the other release (which could > have been a year ago or the same day). Well, yes, and «release.py clean-dist» already has logic to determine the other release's version number. > To automate "edit part of file", we would need to search for the same > major.minor and replace with current relase, but when there is a new > minor (1.15..) we would have to edit manually anyway. I don't think so. We could generate subversion-%(version)s.rdf-excerpt files, drop them in dist/, and then use clean_dist()-like logic to cat the right subset of them, adding a fixed header and trailer. This way, we wouldn't need to splice lines out of and into the file, and we wouldn't need to special-case the first release of a minor line or the EOLing of a minor line in the logic. > It's a balance between the amount of work done by RM, the downside of > having different processes for new minor and new patch release and the > work to code to automate. I'm leaning towards having it as it is, but > I would listen to Stefan's opinion (since he did the most recent RM). By and large, agreed, but see above for the details. Cheers, Daniel
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf : > Is it worthwhile to automate this step? doap.rdf changes rarely enough > that we needn't bother with "edit part of a file" logic; we can just > regenerate the entire file and «svnmucc put» it into place, with a > comment indicating it's a generated file. The doap.rdf contain references to two separate releases (at least right now) and when running release.py you are working on one release at a time. So we can't just have a template and add the current release number, we also need to know the other release (which could have been a year ago or the same day). To automate "edit part of file", we would need to search for the same major.minor and replace with current relase, but when there is a new minor (1.15..) we would have to edit manually anyway. It's a balance between the amount of work done by RM, the downside of having different processes for new minor and new patch release and the work to code to automate. I'm leaning towards having it as it is, but I would listen to Stefan's opinion (since he did the most recent RM). Kind regards, Daniel
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
Daniel Sahlberg wrote on Tue, 16 Feb 2021 13:05 +00:00: > Den tis 16 feb. 2021 kl 13:15 skrev Stefan Sperling : > > On Tue, Feb 16, 2021 at 01:05:32PM +0100, Daniel Sahlberg wrote: > > > What do you think about this? > > > [[[ > > > List the new release on ^/subversion/site/publish/doap.rdf > > > There should be a section for each supported minor release > > > with the and being updated to the current release > > > date and patch release number. > > > Do not change anything else in the file (in particular the > > > under is the date when the Subversion project was created). > > > ]]] > > > > That is crystal clear and should avoid mistakes going forward. Thank you! > > r1886589 Is it worthwhile to automate this step? doap.rdf changes rarely enough that we needn't bother with "edit part of a file" logic; we can just regenerate the entire file and «svnmucc put» it into place, with a comment indicating it's a generated file.
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
Den tis 16 feb. 2021 kl 13:15 skrev Stefan Sperling : > > On Tue, Feb 16, 2021 at 01:05:32PM +0100, Daniel Sahlberg wrote: > > Den tis 16 feb. 2021 kl 11:34 skrev Stefan Sperling : > > > On Mon, Feb 15, 2021 at 07:46:08PM +, Daniel Shahaf wrote: > > > > The entity referred to by the tag wasn't created in 2021. > > > > So, > > > > I think the hunk is incorrect… but so was the original value, which > > > > referred to > > > > the _file_'s creation date (r1053461), rather than to the date > > > > Subversion was > > > > founded (2000), the date it was accepted into the Incubator, or the > > > > date it was > > > > promoted to TLP. > > > > Should this be reverted, maybe even back to the proper creation date > > (2000-02-29)? > > Yes please. I'm sorry for my mistake. > Could you handle that as well while committing the change below? r1886588 I've done this as a separate commit because I think we should merge this to publish quite quickly. I'll leave it until tomorrow in case someone has objections. The other changes can wait for a little bit more discussion. > > > What do you think about this? > > [[[ > > List the new release on ^/subversion/site/publish/doap.rdf > > There should be a section for each supported minor release > > with the and being updated to the current release > > date and patch release number. > > Do not change anything else in the file (in particular the > > under is the date when the Subversion project was created). > > ]]] > > That is crystal clear and should avoid mistakes going forward. Thank you! r1886589 /Daniel
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
On Tue, Feb 16, 2021 at 01:05:32PM +0100, Daniel Sahlberg wrote: > Den tis 16 feb. 2021 kl 11:34 skrev Stefan Sperling : > > On Mon, Feb 15, 2021 at 07:46:08PM +, Daniel Shahaf wrote: > > > The entity referred to by the tag wasn't created in 2021. So, > > > I think the hunk is incorrect… but so was the original value, which > > > referred to > > > the _file_'s creation date (r1053461), rather than to the date Subversion > > > was > > > founded (2000), the date it was accepted into the Incubator, or the date > > > it was > > > promoted to TLP. > > Should this be reverted, maybe even back to the proper creation date > (2000-02-29)? Yes please. I'm sorry for my mistake. Could you handle that as well while committing the change below? > What do you think about this? > [[[ > List the new release on ^/subversion/site/publish/doap.rdf > There should be a section for each supported minor release > with the and being updated to the current release > date and patch release number. > Do not change anything else in the file (in particular the > under is the date when the Subversion project was created). > ]]] That is crystal clear and should avoid mistakes going forward. Thank you!
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
Den tis 16 feb. 2021 kl 11:34 skrev Stefan Sperling : > > On Mon, Feb 15, 2021 at 07:46:08PM +, Daniel Shahaf wrote: > > s...@apache.org wrote on Wed, Feb 10, 2021 at 20:39:23 -: > > > Author: stsp > > > Date: Wed Feb 10 20:39:22 2021 > > > New Revision: 1886396 > > > > > > URL: http://svn.apache.org/viewvc?rev=1886396=rev > > > Log: > > > site/publish: Merge from staging area. > > > > For future reference, this commit should have used the "less than 24 hours > > ago" syntax: > > > > % cd site/publish > > % grep -R -h -9 | vipe > > > > % > > > > More below. > > > > > +++ subversion/site/publish/doap.rdf Wed Feb 10 20:39:22 2021 > > > @@ -22,7 +22,7 @@ > > > limitations under the License. > > > --> > > >http://subversion.apache.org/;> > > > -2010-12-28 > > > +2021-02-10 > > > > Huh? > > > > Quoting http://usefulinc.com/ns/doap: > > > > > > http://usefulinc.com/ns/doap#created;> > > > > http://usefulinc.com/ns/doap#; /> > > > > created > > > > Date when something was created, in > > > > -MM-DD form. e.g. 2004-04-05 > > > > ⋮ > > > > > > > > The entity referred to by the tag wasn't created in 2021. So, > > I think the hunk is incorrect… but so was the original value, which > > referred to > > the _file_'s creation date (r1053461), rather than to the date Subversion > > was > > founded (2000), the date it was accepted into the Incubator, or the date it > > was > > promoted to TLP. Should this be reverted, maybe even back to the proper creation date (2000-02-29)? > > > > Thanks for RMing, > > > > Daniel > > > > Thanks for checking. > > I think in both of these cases it would have helped to have more specific > instructions for how to update these files in our release manager's manual > of the community guide. What do you think about this? [[[ List the new release on ^/subversion/site/publish/doap.rdf There should be a section for each supported minor release with the and being updated to the current release date and patch release number. Do not change anything else in the file (in particular the under is the date when the Subversion project was created). ]]] Kind regards, Daniel Sahlberg
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
On Mon, Feb 15, 2021 at 07:46:08PM +, Daniel Shahaf wrote: > s...@apache.org wrote on Wed, Feb 10, 2021 at 20:39:23 -: > > Author: stsp > > Date: Wed Feb 10 20:39:22 2021 > > New Revision: 1886396 > > > > URL: http://svn.apache.org/viewvc?rev=1886396=rev > > Log: > > site/publish: Merge from staging area. > > For future reference, this commit should have used the "less than 24 hours > ago" syntax: > > % cd site/publish > % grep -R -h -9 | vipe > > % > > More below. > > > +++ subversion/site/publish/doap.rdf Wed Feb 10 20:39:22 2021 > > @@ -22,7 +22,7 @@ > > limitations under the License. > > --> > >http://subversion.apache.org/;> > > -2010-12-28 > > +2021-02-10 > > Huh? > > Quoting http://usefulinc.com/ns/doap: > > > > http://usefulinc.com/ns/doap#created;> > > > http://usefulinc.com/ns/doap#; /> > > > created > > > Date when something was created, in > > > -MM-DD form. e.g. 2004-04-05 > > > ⋮ > > > > > The entity referred to by the tag wasn't created in 2021. So, > I think the hunk is incorrect… but so was the original value, which referred > to > the _file_'s creation date (r1053461), rather than to the date Subversion was > founded (2000), the date it was accepted into the Incubator, or the date it > was > promoted to TLP. > > Thanks for RMing, > > Daniel > Thanks for checking. I think in both of these cases it would have helped to have more specific instructions for how to update these files in our release manager's manual of the community guide. Thanks, Stefan
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
s...@apache.org wrote on Wed, Feb 10, 2021 at 20:39:23 -: > Author: stsp > Date: Wed Feb 10 20:39:22 2021 > New Revision: 1886396 > > URL: http://svn.apache.org/viewvc?rev=1886396=rev > Log: > site/publish: Merge from staging area. For future reference, this commit should have used the "less than 24 hours ago" syntax: % cd site/publish % grep -R -h -9 | vipe % More below. > +++ subversion/site/publish/doap.rdf Wed Feb 10 20:39:22 2021 > @@ -22,7 +22,7 @@ > limitations under the License. > --> >http://subversion.apache.org/;> > -2010-12-28 > +2021-02-10 Huh? Quoting http://usefulinc.com/ns/doap: > > http://usefulinc.com/ns/doap#created;> > > http://usefulinc.com/ns/doap#; /> > > created > > Date when something was created, in > > -MM-DD form. e.g. 2004-04-05 > > ⋮ > > The entity referred to by the tag wasn't created in 2021. So, I think the hunk is incorrect… but so was the original value, which referred to the _file_'s creation date (r1053461), rather than to the date Subversion was founded (2000), the date it was accepted into the Incubator, or the date it was promoted to TLP. Thanks for RMing, Daniel
