Re: Returned post for annou...@apache.org
On Sat, Feb 13, 2021 at 2:21 PM Daniel Sahlberg wrote: > Den lör 13 feb. 2021 kl 12:57 skrev Private List Moderation < > mod-priv...@gsuite.cloud.apache.org>: > > And what rules would you expect to see? >> > > Maybe this is too obvious but "the rules used by the moderators when > deciding to reject a message". I don't think that the community would care > too much about what these rules are as long as the rules are known > beforehand (I'm speaking as community member, not being part of the PMC). > The reason of the whole discussion as I understand it is a feeling that > messages are arbitrary rejected. If there are clear rules, there can be a > clear template for the RM to minimize the risk or rejection. > Exactly. The moderators know what they check and when they accept or reject a message. All we're asking is to have clarity on that, to make everyone's lives easier. Cheers, Nathan
Re: Returned post for annou...@apache.org
Den tors 11 feb. 2021 kl 10:31 skrev Daniel Sahlberg < daniel.l.sahlb...@gmail.com>: > Den tors 11 feb. 2021 kl 10:11 skrev Stefan Sperling : > >> On Thu, Feb 11, 2021 at 09:57:23AM +0100, Daniel Sahlberg wrote: >> > It is indeed a chicken-and-egg problem. However I would suggest to split >> > this "updating the website" into two separate parts: >> > 1. Updating the download page and possibly also adding a news item >> (with a >> > placeholder link to the release announcement) before the announcement. >> > 2. After the release announcement has landed in lists.a.o, update the >> news >> > item with a proper link. >> > >> > If the website is updated in one batch after the announcement someone >> might >> > receive the announcement, immediately heading to the download page and >> then >> > not finding the announced release. >> >> Yes, that makes sense. Would you have time to update the web site >> accordingly? >> > > Sure, I'll make a suggestion in staging. Not today though. > I've committed an initial suggestion in r1886494 ( http://subversion-staging.apache.org/docs/community-guide/releasing.html#releasing-release ). Kind regards, Daniel Sahlberg >
Re: Returned post for annou...@apache.org
Den lör 13 feb. 2021 kl 12:57 skrev Private List Moderation < mod-priv...@gsuite.cloud.apache.org>: > I agree that this would be useful. > > Where would you expect to find such information? > I've searched and I can't find a really logical place. Maybe there is a place with information for the projects that I can't find otherwise Cwiki might be a good place. I would say it is most important that it is suitable for the moderators. Wherever it is, we will link to it from our ( http://subversion.apache.org/docs/community-guide/releasing.html#releasing-release ). And what rules would you expect to see? > Maybe this is too obvious but "the rules used by the moderators when deciding to reject a message". I don't think that the community would care too much about what these rules are as long as the rules are known beforehand (I'm speaking as community member, not being part of the PMC). The reason of the whole discussion as I understand it is a feeling that messages are arbitrary rejected. If there are clear rules, there can be a clear template for the RM to minimize the risk or rejection. Remember that the announce@ list is ASF-wide, so emails need to be worded > accordingly. > Absolutely, guidelines on appropriate messages are of course welcome. Kind regards Daniel Sahlberg
Re: svn commit: r1886490 - in /subversion/trunk/subversion: include/private/ libsvn_subr/ libsvn_wc/ tests/cmdline/ tests/libsvn_subr/ tests/libsvn_wc/
On Sat, Feb 13, 2021 at 04:50:10PM +0100, Branko Čibej wrote: > On 13.02.2021 15:32, Evgeny Kotkov wrote: > > My attempt to fix this is by making checkout stream data to both pristine > > and > > the (projected) working file, so that the actual install would then happen > > as > > just an atomic rename. Since we now never stop reading from the connection, > > the timeouts should no longer be an issue. The new approach also has > > several > > nice properties, such as not having to re-read the pristine files, not > > interfering with the network-level buffering, TCP slow starts, and etc. > > I see that it reduces the amount of both read and write I/O during all > > checkouts, which should give a mild overall increase of how fast the > > checkouts work. > > I like this concept very much indeed. Agreed, yes! I believe I've seen reports of connections timing out during checkout/update, which weren't understood and couldn't be solved in other ways than bumping up server-side limits. This might explain what was going on there. Thanks Evgeny!
Re: svn commit: r1886490 - in /subversion/trunk/subversion: include/private/ libsvn_subr/ libsvn_wc/ tests/cmdline/ tests/libsvn_subr/ tests/libsvn_wc/
On 13.02.2021 15:32, Evgeny Kotkov wrote: Evgeny Kotkov writes: URL: http://svn.apache.org/viewvc?rev=1886490&view=rev Log: In the update editor, stream data to both pristine and working files. ... Several quick benchmarks: - Checking out subversion/trunk over https:// Total time: 3.861 s → 2.812 s Read IO: 57322 KB → 316 KB Write IO: 455013 KB → 359977 KB - Checking out 4 large binary files (7.4 GB) over https:// Total time: 91.594 s → 70.214 s Read IO: 7798883 KB → 19 KB Write IO: 15598167 KB → 15598005 KB Hey everyone, Here's an improvement I have been working on recently. Apparently, the client has an (implicit) limit on the size of directories that can be safely checked out over HTTP without hitting a timeout. The problem is that when the client installs the new working files, it does so in a separate step. This step happens per-directory and involves copying and possibly translating the pristine contents into new working files. While that happens, nothing is read from the connection. So the amount of work that can be done without hitting a timeout is limited. Assuming the default HTTP timeout = 60 seconds of httpd 2.4.x and a relatively fast disk, that puts the limit at around 6 GB for any directory. Not cool. My attempt to fix this is by making checkout stream data to both pristine and the (projected) working file, so that the actual install would then happen as just an atomic rename. Since we now never stop reading from the connection, the timeouts should no longer be an issue. The new approach also has several nice properties, such as not having to re-read the pristine files, not interfering with the network-level buffering, TCP slow starts, and etc. I see that it reduces the amount of both read and write I/O during all checkouts, which should give a mild overall increase of how fast the checkouts work. I like this concept very much indeed. Noting that this change only fixes "svn checkout", but not "svn export". It also affects 'svn update', right, since 'checkout' is implemented as an update of an empty working copy. Export uses a separate implementation of the delta editor, and it should be possible to update it in a similar way — but I'm leaving that for future work for now. The only thing that mildly worries me about the implementation is that the wc-db code is now responsible for installing working files. There's a bit of an abstraction leak here. On the other hand, you need to make the whole operation transactional with the sqlite updates, so ... maybe it's better this way. -- Brane
Re: svn commit: r1886490 - in /subversion/trunk/subversion: include/private/ libsvn_subr/ libsvn_wc/ tests/cmdline/ tests/libsvn_subr/ tests/libsvn_wc/
Evgeny Kotkov writes: > URL: http://svn.apache.org/viewvc?rev=1886490&view=rev > Log: > In the update editor, stream data to both pristine and working files. ... > Several quick benchmarks: > > - Checking out subversion/trunk over https:// > > Total time: 3.861 s → 2.812 s >Read IO: 57322 KB → 316 KB > Write IO: 455013 KB → 359977 KB > > - Checking out 4 large binary files (7.4 GB) over https:// > > Total time: 91.594 s → 70.214 s >Read IO: 7798883 KB → 19 KB > Write IO: 15598167 KB → 15598005 KB Hey everyone, Here's an improvement I have been working on recently. Apparently, the client has an (implicit) limit on the size of directories that can be safely checked out over HTTP without hitting a timeout. The problem is that when the client installs the new working files, it does so in a separate step. This step happens per-directory and involves copying and possibly translating the pristine contents into new working files. While that happens, nothing is read from the connection. So the amount of work that can be done without hitting a timeout is limited. Assuming the default HTTP timeout = 60 seconds of httpd 2.4.x and a relatively fast disk, that puts the limit at around 6 GB for any directory. Not cool. My attempt to fix this is by making checkout stream data to both pristine and the (projected) working file, so that the actual install would then happen as just an atomic rename. Since we now never stop reading from the connection, the timeouts should no longer be an issue. The new approach also has several nice properties, such as not having to re-read the pristine files, not interfering with the network-level buffering, TCP slow starts, and etc. I see that it reduces the amount of both read and write I/O during all checkouts, which should give a mild overall increase of how fast the checkouts work. Noting that this change only fixes "svn checkout", but not "svn export". Export uses a separate implementation of the delta editor, and it should be possible to update it in a similar way — but I'm leaving that for future work for now. Thanks, Evgeny Kotkov
Re: Returned post for annou...@apache.org
On Thu, 11 Feb 2021 at 19:24, Nathan Hartman wrote: > On Thu, Feb 11, 2021 at 11:33 AM Daniel Sahlberg > wrote: > > > > *thread reply* > > > > I think everyone should take a deep breath and then we should re-start > the conversation with the purpose of learning and improving because at the > moment it seems that emotions are way to high. > > > > As I see it - and as usual, I'm new to the party so I don't have > historical context: > > > > * Subversion release process dictate to announce first, update website > later. There is a reason for it but we can improve on the process. I've > raised this at dev@ and received positive feedback from stsp. > > * The RM an honest mistake and forgot to update the download page on the > website. He has admitted and apologized. No problem, we all make mistakes, > right? > > * Moderation rejected the announce mail quite harshly. I would agree > that the missing links was reasonable cause to /hold back/ the > announcement, but I think it was done in a way (tone and outright rejection > instead of reaching out "hey, did you forget to update the download page?") > that didn't invite to further communication. (I'm not comenting on the KEYS > file issue, I wasn't around last time and I don't have the time to look up > the policy, but from what I understand this was a minor issue). > > > > As far as I understand everyone in the Subversion project are > volunteers. I don't know about the moderators but I assume they are as > well. We need to treat eachother with respect and try to find the most > efficient way for the community as a whole and not just "looking from the > perspectiv of ". > > > > Kind regards, > > Daniel Sahlberg > > > I agree that there needs to be respect and appreciation for everyone's > volunteer efforts here, and in the spirit of openness and cooperation > I have a suggestion to make: > > Since it seems that "not being spam" isn't enough to make an > announcement, and this is a long standing issue (it goes back farther > than last May), it would be immensely helpful, both for us and for the > moderators, if there were publicly posted rules that clearly outline: > "this is what moderators check; this is the criteria moderators use to > accept or reject an email to this list." This would clearly set > expectations and help to prevent the repeating issues that I'm sure > are frustrating to the list operators, and I know are frustrating for > us. > > I agree that this would be useful. Where would you expect to find such information? And what rules would you expect to see? Remember that the announce@ list is ASF-wide, so emails need to be worded accordingly. Thanks to everyone for your support. > > Nathan >
