On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache....@gmail.com> wrote: > > 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
This will mean changes to Whimsy code, and could result in temporary breakage as well as needing extra testing. Is it really necessary to have a common parent? > 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. OK. Need to make sure that the various 'find' methods allow for searching by availid as well as full name until changeover is complete. > 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> OK > 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. I don't think we need to move any existing directories. > 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 >
