> On Jun 1, 2020, at 2:42 PM, sebb <seb...@gmail.com> wrote: > > On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache....@gmail.com > <mailto: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.
The only Whimsy code that needs to change is secretary workbench which currently stores requests in documents/emeritus-requests-received. All other code is the stuff I'm working on. > > Is it really necessary to have a common parent? If we don't, then we would have documents/emeritus and documents/emeritus-requests-received and documents/Emeritus/emeritus-requests-rescinded and documents/Emeritus/emeritus-reinstated. I just think that this would be awkward. > >> 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. All of these changes are to the Emeritus files which currently either do not exist or have a single tool that knows anything about them. > >> 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. Again the only directories are emeritus which historically has no tooling, and the emeritus-requests received which has workbench tooling. Consistency is the hobgoblin of small minds but in this case I find the argument compelling. Craig > >> Craig >> >>> On Jun 1, 2020, at 4:24 AM, sebb <seb...@gmail.com >>> <mailto:seb...@gmail.com>> wrote: >>> >>> On Sun, 31 May 2020 at 22:18, Craig Russell <apache....@gmail.com >>> <mailto:apache....@gmail.com> <mailto: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> <mailto: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>> <mailto: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>> <mailto: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>><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>> >>>>>> <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>> >>>>>> <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>> <mailto: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> <mailto:c...@apache.org >>>> <mailto:c...@apache.org>> >> Craig L Russell >> c...@apache.org <mailto:c...@apache.org> Craig L Russell c...@apache.org
