OK. How about this proposal:
New directory documents/Emeritus with these directories: emeritus for accepted requests emeritus-requests-received for received requests emeritus-requests-rescinded for rescinded requests emeritus-reinstated for original requests from reinstated Members So I've come around to Sebb's thinking that we should use availid for stems. To make everything consistent, we should rename all existing entries in emeritus. This is because the reason to use availid is to avoid problems in future, and leaving the entries as is will cause problems in future for those cases where a name change causes us to be unable to find the file because it doesn't match any of the member's current stems. For duplicate file names in emeritus-requests-rescinded and emeritus-reinstated, we should use the same technique as we do today for additional ICLA: create a directory from the stem, copy the original <stem><.suffix> to <stem>/<stem><.suffix>, and create a new <stem>/<stem2><.suffix> I'd like to start debugging the new code for displaying the member's emeritus status. Would it be ok to start by copying some of the emeritus files to a new Emeritus/emeritus directory? And of course, my test emeritus-requests-received file. Later we can move the remaining emeritus files and update the secretary workbench. Craig > On Jun 1, 2020, at 4:24 AM, sebb <seb...@gmail.com> wrote: > > On Sun, 31 May 2020 at 22:18, Craig Russell <apache....@gmail.com > <mailto:apache....@gmail.com>> wrote: >> >> Hi, >> >> Here's a formal proposal for Emeritus file names: >> >> New directory documents/Emeritus with these directories: >> emeritus for accepted requests >> emeritus-requests-received for received requests >> emeritus-requests-rescinded for rescinded requests >> emeritus-reinstated for original requests from reinstated Members > > OK. > >> Contents of these directories: >> <stem><.suffix> >> Stem is full (legal) name >> suffix is .txt, .pdf, or empty for directories with e.g. .pdf and .asc, or >> historic (.eml .jpg etc.). > > The emeritus-requests-rescinded and emeritus-reinstated directories > could potentially have documents from multiple instances, so may need > a disambiguating suffix. > >> There was a comment that full name might include duplicates. I don't believe >> that these are serious enough to warrant changing the file names that we >> have historically. > > If we use availid going forward, then duplicates cannot happen. > > But it was not just about duplicates, which I agree are likely to be rare. > (However there have already been issues with ICLAs.) > > What if someone changes their Full Name? > How does one match up the old file name with the account? > >> Craig >> >>> On May 31, 2020, at 10:36 AM, Craig Russell <apache....@gmail.com >>> <mailto:apache....@gmail.com>> wrote: >>> >>> >>> >>>> On May 31, 2020, at 5:55 AM, Sam Ruby <ru...@intertwingly.net >>>> <mailto:ru...@intertwingly.net> <mailto:ru...@intertwingly.net >>>> <mailto:ru...@intertwingly.net>>> wrote: >>>> >>>> On Sun, May 31, 2020 at 12:50 AM Craig Russell <apache....@gmail.com >>>> <mailto:apache....@gmail.com> <mailto:apache....@gmail.com >>>> <mailto:apache....@gmail.com>>> wrote: >>>>> >>>>> So now I just need an example of svn code executed with no update block >>>>> and some code executed inside the update block. >>>> >>>> Publishing minutes after a board meeting involves a number of updates >>>> to different svn repositories: >>>> >>>> https://github.com/apache/whimsy/blob/master/www/board/agenda/views/actions/publish.json.rb >>>> >>>> <https://github.com/apache/whimsy/blob/master/www/board/agenda/views/actions/publish.json.rb><https://github.com/apache/whimsy/blob/master/www/board/agenda/views/actions/publish.json.rb >>>> >>>> <https://github.com/apache/whimsy/blob/master/www/board/agenda/views/actions/publish.json.rb>> >>>> >>>> This example shows issuing svn commands within the block. >>>> >>>> A few things to note: >>>> >>>> 1) If the block only takes one argument, then it is provided with a >>>> tmpdir only. It is up to you to do any and all svn commands except >>>> for the final commit. >>> >>>> >>>> 2) While you can spawn any command within the block (svn or otherwise) >>>> any way you like, wunderbar provides an _.system method that will >>>> capture the stdout and stderr and add it to the transcript provided in >>>> the response back to the client. >>>> >>>> 3) As sebb points out, a full temporary checkout of a directory like >>>> https://svn.apache.org/repos/private//documents >>>> <https://svn.apache.org/repos/private//documents> >>>> <https://svn.apache.org/repos/private//documents >>>> <https://svn.apache.org/repos/private//documents>> would be impractical. >>>> Perhaps instead of emeritus-rejoined, emeritus-requests-received, and >>>> emeritus-requests-rescinded directories that are sister directories to >>>> the emeritus directory, there could be a single emeritus directory >>>> which contains a number of subdirectories. An example of such a >>>> structure is https://svn.apache.org/repos/private/financials/Bills >>>> <https://svn.apache.org/repos/private/financials/Bills> >>>> <https://svn.apache.org/repos/private/financials/Bills >>>> <https://svn.apache.org/repos/private/financials/Bills>>. >>> >>> Here's a way forward that changes a lot but makes the technical solution >>> easier. >>> >>> svn mkdir foundation/Members >>> svn mv foundation/members.txt foundation/Members >>> svn mv documents/emeritus foundation/Members >>> svn mv documents/emeritus-requests-received foundation/Members >>> svn mv documents/emeritus-requests-rescinded foundation/Members >>> svn mv documents/emeritus-reinstated foundation/Members >>> >>> Then, the _svn.update would checkout the entire Members directory which >>> consists solely of the members.txt and the various emeritus files. And the >>> _svn.update function would commit everything or nothing. >>> >>> An alternative is to do the _svn.update of members.txt first and if >>> successful, do the move of the emeritus files, which unless something is >>> seriously messed up, will "always succeed". >>> >>> Craig >>> >>> >>>> >>>>> Thanks, >>>>> Craig >>>> >>> >>> Craig L Russell >>> c...@apache.org <mailto:c...@apache.org> <mailto:c...@apache.org >>> <mailto:c...@apache.org>> >> Craig L Russell >> c...@apache.org <mailto:c...@apache.org> Craig L Russell c...@apache.org
