You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whimsical.apache.org by sebb <se...@gmail.com> on 2020/06/01 11:24:50 UTC
Re: bikeshedding Emeritus file names
On Sun, 31 May 2020 at 22:18, Craig Russell <ap...@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 <ap...@gmail.com> wrote:
> >
> >
> >
> >> On May 31, 2020, at 5:55 AM, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net>> wrote:
> >>
> >> On Sun, May 31, 2020 at 12:50 AM Craig Russell <apache.clr@gmail.com <ma...@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>
> >>
> >> 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> 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>.
> >
> > 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
> > clr@apache.org <ma...@apache.org>
> Craig L Russell
> clr@apache.org
>
Re: bikeshedding Emeritus file names
Posted by Craig Russell <ap...@gmail.com>.
> On Jun 2, 2020, at 12:26 PM, sebb <se...@gmail.com> wrote:
>
> On Tue, 2 Jun 2020 at 20:23, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net>> wrote:
>>
>> On Tue, Jun 2, 2020 at 3:16 PM Craig Russell <ap...@gmail.com> wrote:
>>>
>>>> On Jun 2, 2020, at 11:27 AM, sebb <se...@gmail.com> wrote:
>>>>
>>>> On Tue, 2 Jun 2020 at 19:01, Craig Russell <apache.clr@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Jun 2, 2020, at 9:06 AM, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net>> wrote:
>>>>>>
>>>>>> On Tue, Jun 2, 2020 at 10:49 AM Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>>> wrote:
>>>>>>>
>>>>>>>> On Jun 2, 2020, at 6:35 AM, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net> <mailto:rubys@intertwingly.net <ma...@intertwingly.net>>> wrote:
>>>>>>>>
>>>>>>>> On Mon, Jun 1, 2020 at 8:50 PM Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>> <mailto:apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Jun 1, 2020, at 4:58 PM, sebb <sebbaz@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Mon, 1 Jun 2020 at 23:20, Craig Russell <apache.clr@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Jun 1, 2020, at 2:42 PM, sebb <sebbaz@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@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.
>>>>>>>>>>
>>>>>>>>>> Changes to the locations of emeritus directories means changes to
>>>>>>>>>> whimsy library code as well.
>>>>>>>>>> The committer roster relies on this for showing emeritus member docs.
>>>>>>>>>> And there are scripts to check emeritus files.
>>>>>>>>>>
>>>>>>>>>> Introduction of an extra Emeritus parent is going to mean changes to
>>>>>>>>>> shared code, so lots of testing needed.
>>>>>>>>>
>>>>>>>>> Ok. I really don't care if we add two more directories if it means less work for everyone else.
>>>>>>>>>
>>>>>>>>> Anyone else with a strong opinion here? Sam?
>>>>>>>>
>>>>>>>> I, too, feel that the current structure is haphazard and disorderly,
>>>>>>>> and that the proposal would be an improvement. Minor quibble: the
>>>>>>>> redundancy of Emeritus/emeritus-* bothers me.
>>>>>>>
>>>>>>> I'm open to other ideas that avoid duplication of names.
>>>>>>>>
>>>>>>>> That being said, my bigger concern is twofold:
>>>>>>>
>>>>>>> This is in line with what Sebb has been saying, if I can read between the lines.
>>>>>>>>
>>>>>>>> 1) Effectively, the only documentation for the current structure is
>>>>>>>> contained within the whimsy code. Effectively, instead of the
>>>>>>>> secretary saying "this is where the data belongs", we make decisions
>>>>>>>> based on where a given tool places data and where other tools look for
>>>>>>>> data. There is no architecture. Ultimately, this is a failure of the
>>>>>>>> secretary. I say that as a former-secretary who both inherited this
>>>>>>>> mess and mostly left it to my successors.
>>>>>>>
>>>>>>> Well, way back in 2018 while I was secretary we started using the emeritus-requests-received directory with no real tool support. We did not architect this but just decided it was better than leaving the request in the workbench queue for later processing.
>>>>>>>>
>>>>>>>> 2) The code is unnecessarily tightly bound to the location of the
>>>>>>>> data, making changes more difficult. Once upon a time, code would
>>>>>>>> call ASF:SVN['foobar'] or perhaps ASF::SVN.find('foobar') to locate
>>>>>>>> directories, and that library routine would consult things like
>>>>>>>> ~/.whimsy.for local tailoring. Over time, there seemed to be little
>>>>>>>> interest in maintaining that mapping, and the current state is that if
>>>>>>>> you place things in any location other than /srv, things may not work.
>>>>>>>
>>>>>>> The current tooling does have a mixture of styles. This is from memstat-json.rb:
>>>>>>> # identify file to be updated
>>>>>>> members_txt = File.join(ASF::SVN['foundation'], 'members.txt')
>>>>>>>
>>>>>>> So this says that somewhere there is a foundation directory that "someone else" knows the actual location. But it does hard code the name of the file, members.txt.
>>>>>>>
>>>>>>> Is that ideal from your perspective? Or should the name of the members.txt as well as its location be abstracted to the ASF::SVN metadata?
>>>>>>>>
>>>>>>>> Ideally, there would be a token or identifier for each of these
>>>>>>>> directories, an ASF:SVN or some other place would be the only place
>>>>>>>> that knows the mapping of this identifier to the URL as well as the
>>>>>>>> location of where the local working copy associated with that URL
>>>>>>>> would be. I'd love to be in a position where the location and even
>>>>>>>> the format of the files could be changed at will, and any impact to
>>>>>>>> whimsy tooling would be contained.
>>>>>>>
>>>>>>> I'm really keen on trying to implement this. So if ASF::SVN is the canonical location for the emeritus directories, what would you suggest we use as labels? If we follow the members.txt example, we would have a single ASF::SVN['emeritus-directory'] that the code didn't know the location of, but the code would still have to know the names of the directories it contained. The svn move command would use the temp directory to do this
>>>>>>> 'svn update emeritus-requests-received/<filename>;
>>>>>>> svn move emeritus-requests-received/<filename> emeritus'
>>>>>>> And then the commit would commit both the members.txt and the tmp directory with the move commands.
>>>>>>>
>>>>>>> Or perhaps ASF::SVN['emeritus-requests-received'] would be a pointer to that directory. And now we have the question of how the svn move from emeritus-requests-received to emeritus would be done.
>>>>>>>
>>>>>>> Would it help to track down all of the scripts and tooling that currently know the location of the emeritus directories?
>>>>>>
>>>>>> You asked a lot of questions. :-)
>>>>>>
>>>>>> Let me make a concrete suggestion. Start with the following file:
>>>>>>
>>>>>> https://github.com/apache/whimsy/blob/master/repository.yml <https://github.com/apache/whimsy/blob/master/repository.yml> <https://github.com/apache/whimsy/blob/master/repository.yml <https://github.com/apache/whimsy/blob/master/repository.yml>>
>>>>>>
>>>>>> Let's take a specific example:
>>>>>>
>>>>>> https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92 <https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92><https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92 <https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92>>
>>>>>>
>>>>>> These two lines (92 and 93) associate an identifier
>>>>>> (emeritus-requests-received) with a url
>>>>>> (private/documents/emeritus-requests-received), and contains other
>>>>>> meta data used by the ASF::SVN module.
>>>>>>
>>>>>> In an ideal world, the secretary should be able to change that URL and
>>>>>> the ONLY thing that would need to be updated is that one line in that
>>>>>> one file and all whimsy tools would operate properly using the new
>>>>>> location. Everything that depends on this information should use
>>>>>> ASF::SVN['emeritus-requests-received'}.
>>>>>
>>>>> Still unanswered: If we have multiple entries (one entry for each of the four emeritus* directories) can we have svn move commands that move files from one directory to another?
>>>>
>>>> Yes, both svn and svnmucc can rename files directly within the repositories.
>>>> However only svnmucc can do multiple remote renames in a single commit.
>>>>
>>>>> I understand how to do it if we have a single ASF::SVN['documents-emeritus'] and the code knows the names of the four sub-directories. I don't know how to handle the svn mv command if we have checked out four temp directories without necessarily knowing the names of the directories. Can we somehow annotate the repository.yml with the names of the subdirectories?
>>>>
>>>> I don't think it's possible to do an svn rename across different workspaces.
>>>>
>>>> AFAIK you have to have a single workspace which includes a common parent.
>>>> If you checkout the full subtree from that parent, then you can
>>>> definitely use the svn client to do multiple renames, mkdir and
>>>> deletes locally.
>>>> A checking will then commit everything or nothing.
>>>> However that is likely to be a big/slow checkout.
>>>>
>>>> I think the workspace does not have to be a full checkout, but
>>>> obviously has to include the relevant files, and possibly the full
>>>> directories of source and destination.
>>>> This is tricky to set up, which is why I suggested svnmucc.
>>>
>>> I think we are in agreement that big/slow is not an option.
>>
>> Three options which do not require a full checkout:
>>
>> https://gist.github.com/rubys/d65a1d0ac7e168d0a9deebc86efcc43a
>>
>>> So using MultiUpdate, how do we construct the extra svn move commands from the ASF::SVN directory names for the emeritus directories?
>>
>> ASF::SVN has this information, but currently only makes it available
>> if there is a full checkout. A new method could be added.
>
> ASF::SVN.svnurl() already exists
>
>>> I don't see how to do it without the application (emeritus.json.rb) knowing the directory names.
>
> It does not need directory names, because the renames are done
> directly in the repo.
>
> There is no need for a checkout.
>
> See other thread for info on getting the URLs.
Ok. I think I have enough to finish this part of the job. If necessary, we can discuss putting all four emeritus directories under one directory and all we need to do is to change the repositories.yml to make that happen.
Later.
Craig
>
>>>
>>> Craig
>>
>> - Sam Ruby
>>
>>>>> Craig
>>>>>>
>>>>>> So the thing to track down is all of the scripts and tooling that do
>>>>>> not use ASF::SVN and the identifier specified in repository.yml to
>>>>>> access this information.
>>>>>>
>>>>>>> Craig
>>>>>>
>>>>>> - Sam Ruby
>>>>>>
>>>>>>>> But ultimately, we need people to take ownership of this decision, and
>>>>>>>> a part of that would be a willingness to make the necessary changes to
>>>>>>>> make it work.
>>>>>>>>
>>>>>>>>> Craig
>>>>>>>>
>>>>>>>> - Sam Ruby
>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> I agree that would be awkward, but that's not what I meant.
>>>>>>>>>> I am suggesting leaving them all under documents/
>>>>>>>>>
>>>>>>>>> Craig L Russell
>>>>>>>>> clr@apache.org
>>>>>>>
>>>>>>> Craig L Russell
>>>>>>> clr@apache.org
>>>>>
>>>>> Craig L Russell
>>>>> clr@apache.org
>>>
>>> Craig L Russell
>>> clr@apache.org
Craig L Russell
clr@apache.org
Re: bikeshedding Emeritus file names
Posted by sebb <se...@gmail.com>.
On Tue, 2 Jun 2020 at 20:23, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Tue, Jun 2, 2020 at 3:16 PM Craig Russell <ap...@gmail.com> wrote:
> >
> > > On Jun 2, 2020, at 11:27 AM, sebb <se...@gmail.com> wrote:
> > >
> > > On Tue, 2 Jun 2020 at 19:01, Craig Russell <apache.clr@gmail.com <ma...@gmail.com>> wrote:
> > >>
> > >>
> > >>
> > >>> On Jun 2, 2020, at 9:06 AM, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net>> wrote:
> > >>>
> > >>> On Tue, Jun 2, 2020 at 10:49 AM Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>>> wrote:
> > >>>>
> > >>>>> On Jun 2, 2020, at 6:35 AM, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net> <mailto:rubys@intertwingly.net <ma...@intertwingly.net>>> wrote:
> > >>>>>
> > >>>>> On Mon, Jun 1, 2020 at 8:50 PM Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>> <mailto:apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>>>> wrote:
> > >>>>>>
> > >>>>>>> On Jun 1, 2020, at 4:58 PM, sebb <sebbaz@gmail.com <ma...@gmail.com>> wrote:
> > >>>>>>>
> > >>>>>>> On Mon, 1 Jun 2020 at 23:20, Craig Russell <apache.clr@gmail.com <ma...@gmail.com>> wrote:
> > >>>>>>>>
> > >>>>>>>>> On Jun 1, 2020, at 2:42 PM, sebb <sebbaz@gmail.com <ma...@gmail.com>> wrote:
> > >>>>>>>>>
> > >>>>>>>>> On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@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.
> > >>>>>>>
> > >>>>>>> Changes to the locations of emeritus directories means changes to
> > >>>>>>> whimsy library code as well.
> > >>>>>>> The committer roster relies on this for showing emeritus member docs.
> > >>>>>>> And there are scripts to check emeritus files.
> > >>>>>>>
> > >>>>>>> Introduction of an extra Emeritus parent is going to mean changes to
> > >>>>>>> shared code, so lots of testing needed.
> > >>>>>>
> > >>>>>> Ok. I really don't care if we add two more directories if it means less work for everyone else.
> > >>>>>>
> > >>>>>> Anyone else with a strong opinion here? Sam?
> > >>>>>
> > >>>>> I, too, feel that the current structure is haphazard and disorderly,
> > >>>>> and that the proposal would be an improvement. Minor quibble: the
> > >>>>> redundancy of Emeritus/emeritus-* bothers me.
> > >>>>
> > >>>> I'm open to other ideas that avoid duplication of names.
> > >>>>>
> > >>>>> That being said, my bigger concern is twofold:
> > >>>>
> > >>>> This is in line with what Sebb has been saying, if I can read between the lines.
> > >>>>>
> > >>>>> 1) Effectively, the only documentation for the current structure is
> > >>>>> contained within the whimsy code. Effectively, instead of the
> > >>>>> secretary saying "this is where the data belongs", we make decisions
> > >>>>> based on where a given tool places data and where other tools look for
> > >>>>> data. There is no architecture. Ultimately, this is a failure of the
> > >>>>> secretary. I say that as a former-secretary who both inherited this
> > >>>>> mess and mostly left it to my successors.
> > >>>>
> > >>>> Well, way back in 2018 while I was secretary we started using the emeritus-requests-received directory with no real tool support. We did not architect this but just decided it was better than leaving the request in the workbench queue for later processing.
> > >>>>>
> > >>>>> 2) The code is unnecessarily tightly bound to the location of the
> > >>>>> data, making changes more difficult. Once upon a time, code would
> > >>>>> call ASF:SVN['foobar'] or perhaps ASF::SVN.find('foobar') to locate
> > >>>>> directories, and that library routine would consult things like
> > >>>>> ~/.whimsy.for local tailoring. Over time, there seemed to be little
> > >>>>> interest in maintaining that mapping, and the current state is that if
> > >>>>> you place things in any location other than /srv, things may not work.
> > >>>>
> > >>>> The current tooling does have a mixture of styles. This is from memstat-json.rb:
> > >>>> # identify file to be updated
> > >>>> members_txt = File.join(ASF::SVN['foundation'], 'members.txt')
> > >>>>
> > >>>> So this says that somewhere there is a foundation directory that "someone else" knows the actual location. But it does hard code the name of the file, members.txt.
> > >>>>
> > >>>> Is that ideal from your perspective? Or should the name of the members.txt as well as its location be abstracted to the ASF::SVN metadata?
> > >>>>>
> > >>>>> Ideally, there would be a token or identifier for each of these
> > >>>>> directories, an ASF:SVN or some other place would be the only place
> > >>>>> that knows the mapping of this identifier to the URL as well as the
> > >>>>> location of where the local working copy associated with that URL
> > >>>>> would be. I'd love to be in a position where the location and even
> > >>>>> the format of the files could be changed at will, and any impact to
> > >>>>> whimsy tooling would be contained.
> > >>>>
> > >>>> I'm really keen on trying to implement this. So if ASF::SVN is the canonical location for the emeritus directories, what would you suggest we use as labels? If we follow the members.txt example, we would have a single ASF::SVN['emeritus-directory'] that the code didn't know the location of, but the code would still have to know the names of the directories it contained. The svn move command would use the temp directory to do this
> > >>>> 'svn update emeritus-requests-received/<filename>;
> > >>>> svn move emeritus-requests-received/<filename> emeritus'
> > >>>> And then the commit would commit both the members.txt and the tmp directory with the move commands.
> > >>>>
> > >>>> Or perhaps ASF::SVN['emeritus-requests-received'] would be a pointer to that directory. And now we have the question of how the svn move from emeritus-requests-received to emeritus would be done.
> > >>>>
> > >>>> Would it help to track down all of the scripts and tooling that currently know the location of the emeritus directories?
> > >>>
> > >>> You asked a lot of questions. :-)
> > >>>
> > >>> Let me make a concrete suggestion. Start with the following file:
> > >>>
> > >>> https://github.com/apache/whimsy/blob/master/repository.yml <https://github.com/apache/whimsy/blob/master/repository.yml> <https://github.com/apache/whimsy/blob/master/repository.yml <https://github.com/apache/whimsy/blob/master/repository.yml>>
> > >>>
> > >>> Let's take a specific example:
> > >>>
> > >>> https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92 <https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92><https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92 <https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92>>
> > >>>
> > >>> These two lines (92 and 93) associate an identifier
> > >>> (emeritus-requests-received) with a url
> > >>> (private/documents/emeritus-requests-received), and contains other
> > >>> meta data used by the ASF::SVN module.
> > >>>
> > >>> In an ideal world, the secretary should be able to change that URL and
> > >>> the ONLY thing that would need to be updated is that one line in that
> > >>> one file and all whimsy tools would operate properly using the new
> > >>> location. Everything that depends on this information should use
> > >>> ASF::SVN['emeritus-requests-received'}.
> > >>
> > >> Still unanswered: If we have multiple entries (one entry for each of the four emeritus* directories) can we have svn move commands that move files from one directory to another?
> > >
> > > Yes, both svn and svnmucc can rename files directly within the repositories.
> > > However only svnmucc can do multiple remote renames in a single commit.
> > >
> > >> I understand how to do it if we have a single ASF::SVN['documents-emeritus'] and the code knows the names of the four sub-directories. I don't know how to handle the svn mv command if we have checked out four temp directories without necessarily knowing the names of the directories. Can we somehow annotate the repository.yml with the names of the subdirectories?
> > >
> > > I don't think it's possible to do an svn rename across different workspaces.
> > >
> > > AFAIK you have to have a single workspace which includes a common parent.
> > > If you checkout the full subtree from that parent, then you can
> > > definitely use the svn client to do multiple renames, mkdir and
> > > deletes locally.
> > > A checking will then commit everything or nothing.
> > > However that is likely to be a big/slow checkout.
> > >
> > > I think the workspace does not have to be a full checkout, but
> > > obviously has to include the relevant files, and possibly the full
> > > directories of source and destination.
> > > This is tricky to set up, which is why I suggested svnmucc.
> >
> > I think we are in agreement that big/slow is not an option.
>
> Three options which do not require a full checkout:
>
> https://gist.github.com/rubys/d65a1d0ac7e168d0a9deebc86efcc43a
>
> > So using MultiUpdate, how do we construct the extra svn move commands from the ASF::SVN directory names for the emeritus directories?
>
> ASF::SVN has this information, but currently only makes it available
> if there is a full checkout. A new method could be added.
ASF::SVN.svnurl() already exists
> > I don't see how to do it without the application (emeritus.json.rb) knowing the directory names.
It does not need directory names, because the renames are done
directly in the repo.
There is no need for a checkout.
See other thread for info on getting the URLs.
> >
> > Craig
>
> - Sam Ruby
>
> > >> Craig
> > >>>
> > >>> So the thing to track down is all of the scripts and tooling that do
> > >>> not use ASF::SVN and the identifier specified in repository.yml to
> > >>> access this information.
> > >>>
> > >>>> Craig
> > >>>
> > >>> - Sam Ruby
> > >>>
> > >>>>> But ultimately, we need people to take ownership of this decision, and
> > >>>>> a part of that would be a willingness to make the necessary changes to
> > >>>>> make it work.
> > >>>>>
> > >>>>>> Craig
> > >>>>>
> > >>>>> - Sam Ruby
> > >>>>>
> > >>>>>>>>>
> > >>>>>>>>> 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.
> > >>>>>>>
> > >>>>>>> I agree that would be awkward, but that's not what I meant.
> > >>>>>>> I am suggesting leaving them all under documents/
> > >>>>>>
> > >>>>>> Craig L Russell
> > >>>>>> clr@apache.org
> > >>>>
> > >>>> Craig L Russell
> > >>>> clr@apache.org
> > >>
> > >> Craig L Russell
> > >> clr@apache.org
> >
> > Craig L Russell
> > clr@apache.org
> >
Re: bikeshedding Emeritus file names
Posted by Sam Ruby <ru...@intertwingly.net>.
On Tue, Jun 2, 2020 at 3:16 PM Craig Russell <ap...@gmail.com> wrote:
>
> > On Jun 2, 2020, at 11:27 AM, sebb <se...@gmail.com> wrote:
> >
> > On Tue, 2 Jun 2020 at 19:01, Craig Russell <apache.clr@gmail.com <ma...@gmail.com>> wrote:
> >>
> >>
> >>
> >>> On Jun 2, 2020, at 9:06 AM, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net>> wrote:
> >>>
> >>> On Tue, Jun 2, 2020 at 10:49 AM Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>>> wrote:
> >>>>
> >>>>> On Jun 2, 2020, at 6:35 AM, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net> <mailto:rubys@intertwingly.net <ma...@intertwingly.net>>> wrote:
> >>>>>
> >>>>> On Mon, Jun 1, 2020 at 8:50 PM Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>> <mailto:apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>>>> wrote:
> >>>>>>
> >>>>>>> On Jun 1, 2020, at 4:58 PM, sebb <sebbaz@gmail.com <ma...@gmail.com>> wrote:
> >>>>>>>
> >>>>>>> On Mon, 1 Jun 2020 at 23:20, Craig Russell <apache.clr@gmail.com <ma...@gmail.com>> wrote:
> >>>>>>>>
> >>>>>>>>> On Jun 1, 2020, at 2:42 PM, sebb <sebbaz@gmail.com <ma...@gmail.com>> wrote:
> >>>>>>>>>
> >>>>>>>>> On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@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.
> >>>>>>>
> >>>>>>> Changes to the locations of emeritus directories means changes to
> >>>>>>> whimsy library code as well.
> >>>>>>> The committer roster relies on this for showing emeritus member docs.
> >>>>>>> And there are scripts to check emeritus files.
> >>>>>>>
> >>>>>>> Introduction of an extra Emeritus parent is going to mean changes to
> >>>>>>> shared code, so lots of testing needed.
> >>>>>>
> >>>>>> Ok. I really don't care if we add two more directories if it means less work for everyone else.
> >>>>>>
> >>>>>> Anyone else with a strong opinion here? Sam?
> >>>>>
> >>>>> I, too, feel that the current structure is haphazard and disorderly,
> >>>>> and that the proposal would be an improvement. Minor quibble: the
> >>>>> redundancy of Emeritus/emeritus-* bothers me.
> >>>>
> >>>> I'm open to other ideas that avoid duplication of names.
> >>>>>
> >>>>> That being said, my bigger concern is twofold:
> >>>>
> >>>> This is in line with what Sebb has been saying, if I can read between the lines.
> >>>>>
> >>>>> 1) Effectively, the only documentation for the current structure is
> >>>>> contained within the whimsy code. Effectively, instead of the
> >>>>> secretary saying "this is where the data belongs", we make decisions
> >>>>> based on where a given tool places data and where other tools look for
> >>>>> data. There is no architecture. Ultimately, this is a failure of the
> >>>>> secretary. I say that as a former-secretary who both inherited this
> >>>>> mess and mostly left it to my successors.
> >>>>
> >>>> Well, way back in 2018 while I was secretary we started using the emeritus-requests-received directory with no real tool support. We did not architect this but just decided it was better than leaving the request in the workbench queue for later processing.
> >>>>>
> >>>>> 2) The code is unnecessarily tightly bound to the location of the
> >>>>> data, making changes more difficult. Once upon a time, code would
> >>>>> call ASF:SVN['foobar'] or perhaps ASF::SVN.find('foobar') to locate
> >>>>> directories, and that library routine would consult things like
> >>>>> ~/.whimsy.for local tailoring. Over time, there seemed to be little
> >>>>> interest in maintaining that mapping, and the current state is that if
> >>>>> you place things in any location other than /srv, things may not work.
> >>>>
> >>>> The current tooling does have a mixture of styles. This is from memstat-json.rb:
> >>>> # identify file to be updated
> >>>> members_txt = File.join(ASF::SVN['foundation'], 'members.txt')
> >>>>
> >>>> So this says that somewhere there is a foundation directory that "someone else" knows the actual location. But it does hard code the name of the file, members.txt.
> >>>>
> >>>> Is that ideal from your perspective? Or should the name of the members.txt as well as its location be abstracted to the ASF::SVN metadata?
> >>>>>
> >>>>> Ideally, there would be a token or identifier for each of these
> >>>>> directories, an ASF:SVN or some other place would be the only place
> >>>>> that knows the mapping of this identifier to the URL as well as the
> >>>>> location of where the local working copy associated with that URL
> >>>>> would be. I'd love to be in a position where the location and even
> >>>>> the format of the files could be changed at will, and any impact to
> >>>>> whimsy tooling would be contained.
> >>>>
> >>>> I'm really keen on trying to implement this. So if ASF::SVN is the canonical location for the emeritus directories, what would you suggest we use as labels? If we follow the members.txt example, we would have a single ASF::SVN['emeritus-directory'] that the code didn't know the location of, but the code would still have to know the names of the directories it contained. The svn move command would use the temp directory to do this
> >>>> 'svn update emeritus-requests-received/<filename>;
> >>>> svn move emeritus-requests-received/<filename> emeritus'
> >>>> And then the commit would commit both the members.txt and the tmp directory with the move commands.
> >>>>
> >>>> Or perhaps ASF::SVN['emeritus-requests-received'] would be a pointer to that directory. And now we have the question of how the svn move from emeritus-requests-received to emeritus would be done.
> >>>>
> >>>> Would it help to track down all of the scripts and tooling that currently know the location of the emeritus directories?
> >>>
> >>> You asked a lot of questions. :-)
> >>>
> >>> Let me make a concrete suggestion. Start with the following file:
> >>>
> >>> https://github.com/apache/whimsy/blob/master/repository.yml <https://github.com/apache/whimsy/blob/master/repository.yml> <https://github.com/apache/whimsy/blob/master/repository.yml <https://github.com/apache/whimsy/blob/master/repository.yml>>
> >>>
> >>> Let's take a specific example:
> >>>
> >>> https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92 <https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92><https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92 <https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92>>
> >>>
> >>> These two lines (92 and 93) associate an identifier
> >>> (emeritus-requests-received) with a url
> >>> (private/documents/emeritus-requests-received), and contains other
> >>> meta data used by the ASF::SVN module.
> >>>
> >>> In an ideal world, the secretary should be able to change that URL and
> >>> the ONLY thing that would need to be updated is that one line in that
> >>> one file and all whimsy tools would operate properly using the new
> >>> location. Everything that depends on this information should use
> >>> ASF::SVN['emeritus-requests-received'}.
> >>
> >> Still unanswered: If we have multiple entries (one entry for each of the four emeritus* directories) can we have svn move commands that move files from one directory to another?
> >
> > Yes, both svn and svnmucc can rename files directly within the repositories.
> > However only svnmucc can do multiple remote renames in a single commit.
> >
> >> I understand how to do it if we have a single ASF::SVN['documents-emeritus'] and the code knows the names of the four sub-directories. I don't know how to handle the svn mv command if we have checked out four temp directories without necessarily knowing the names of the directories. Can we somehow annotate the repository.yml with the names of the subdirectories?
> >
> > I don't think it's possible to do an svn rename across different workspaces.
> >
> > AFAIK you have to have a single workspace which includes a common parent.
> > If you checkout the full subtree from that parent, then you can
> > definitely use the svn client to do multiple renames, mkdir and
> > deletes locally.
> > A checking will then commit everything or nothing.
> > However that is likely to be a big/slow checkout.
> >
> > I think the workspace does not have to be a full checkout, but
> > obviously has to include the relevant files, and possibly the full
> > directories of source and destination.
> > This is tricky to set up, which is why I suggested svnmucc.
>
> I think we are in agreement that big/slow is not an option.
Three options which do not require a full checkout:
https://gist.github.com/rubys/d65a1d0ac7e168d0a9deebc86efcc43a
> So using MultiUpdate, how do we construct the extra svn move commands from the ASF::SVN directory names for the emeritus directories?
ASF::SVN has this information, but currently only makes it available
if there is a full checkout. A new method could be added.
> I don't see how to do it without the application (emeritus.json.rb) knowing the directory names.
>
> Craig
- Sam Ruby
> >> Craig
> >>>
> >>> So the thing to track down is all of the scripts and tooling that do
> >>> not use ASF::SVN and the identifier specified in repository.yml to
> >>> access this information.
> >>>
> >>>> Craig
> >>>
> >>> - Sam Ruby
> >>>
> >>>>> But ultimately, we need people to take ownership of this decision, and
> >>>>> a part of that would be a willingness to make the necessary changes to
> >>>>> make it work.
> >>>>>
> >>>>>> Craig
> >>>>>
> >>>>> - Sam Ruby
> >>>>>
> >>>>>>>>>
> >>>>>>>>> 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.
> >>>>>>>
> >>>>>>> I agree that would be awkward, but that's not what I meant.
> >>>>>>> I am suggesting leaving them all under documents/
> >>>>>>
> >>>>>> Craig L Russell
> >>>>>> clr@apache.org
> >>>>
> >>>> Craig L Russell
> >>>> clr@apache.org
> >>
> >> Craig L Russell
> >> clr@apache.org
>
> Craig L Russell
> clr@apache.org
>
Re: bikeshedding Emeritus file names
Posted by Craig Russell <ap...@gmail.com>.
> On Jun 2, 2020, at 11:27 AM, sebb <se...@gmail.com> wrote:
>
> On Tue, 2 Jun 2020 at 19:01, Craig Russell <apache.clr@gmail.com <ma...@gmail.com>> wrote:
>>
>>
>>
>>> On Jun 2, 2020, at 9:06 AM, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net>> wrote:
>>>
>>> On Tue, Jun 2, 2020 at 10:49 AM Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>>> wrote:
>>>>
>>>>> On Jun 2, 2020, at 6:35 AM, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net> <mailto:rubys@intertwingly.net <ma...@intertwingly.net>>> wrote:
>>>>>
>>>>> On Mon, Jun 1, 2020 at 8:50 PM Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>> <mailto:apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>>>> wrote:
>>>>>>
>>>>>>> On Jun 1, 2020, at 4:58 PM, sebb <sebbaz@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>
>>>>>>> On Mon, 1 Jun 2020 at 23:20, Craig Russell <apache.clr@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>
>>>>>>>>> On Jun 1, 2020, at 2:42 PM, sebb <sebbaz@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>> On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@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.
>>>>>>>
>>>>>>> Changes to the locations of emeritus directories means changes to
>>>>>>> whimsy library code as well.
>>>>>>> The committer roster relies on this for showing emeritus member docs.
>>>>>>> And there are scripts to check emeritus files.
>>>>>>>
>>>>>>> Introduction of an extra Emeritus parent is going to mean changes to
>>>>>>> shared code, so lots of testing needed.
>>>>>>
>>>>>> Ok. I really don't care if we add two more directories if it means less work for everyone else.
>>>>>>
>>>>>> Anyone else with a strong opinion here? Sam?
>>>>>
>>>>> I, too, feel that the current structure is haphazard and disorderly,
>>>>> and that the proposal would be an improvement. Minor quibble: the
>>>>> redundancy of Emeritus/emeritus-* bothers me.
>>>>
>>>> I'm open to other ideas that avoid duplication of names.
>>>>>
>>>>> That being said, my bigger concern is twofold:
>>>>
>>>> This is in line with what Sebb has been saying, if I can read between the lines.
>>>>>
>>>>> 1) Effectively, the only documentation for the current structure is
>>>>> contained within the whimsy code. Effectively, instead of the
>>>>> secretary saying "this is where the data belongs", we make decisions
>>>>> based on where a given tool places data and where other tools look for
>>>>> data. There is no architecture. Ultimately, this is a failure of the
>>>>> secretary. I say that as a former-secretary who both inherited this
>>>>> mess and mostly left it to my successors.
>>>>
>>>> Well, way back in 2018 while I was secretary we started using the emeritus-requests-received directory with no real tool support. We did not architect this but just decided it was better than leaving the request in the workbench queue for later processing.
>>>>>
>>>>> 2) The code is unnecessarily tightly bound to the location of the
>>>>> data, making changes more difficult. Once upon a time, code would
>>>>> call ASF:SVN['foobar'] or perhaps ASF::SVN.find('foobar') to locate
>>>>> directories, and that library routine would consult things like
>>>>> ~/.whimsy.for local tailoring. Over time, there seemed to be little
>>>>> interest in maintaining that mapping, and the current state is that if
>>>>> you place things in any location other than /srv, things may not work.
>>>>
>>>> The current tooling does have a mixture of styles. This is from memstat-json.rb:
>>>> # identify file to be updated
>>>> members_txt = File.join(ASF::SVN['foundation'], 'members.txt')
>>>>
>>>> So this says that somewhere there is a foundation directory that "someone else" knows the actual location. But it does hard code the name of the file, members.txt.
>>>>
>>>> Is that ideal from your perspective? Or should the name of the members.txt as well as its location be abstracted to the ASF::SVN metadata?
>>>>>
>>>>> Ideally, there would be a token or identifier for each of these
>>>>> directories, an ASF:SVN or some other place would be the only place
>>>>> that knows the mapping of this identifier to the URL as well as the
>>>>> location of where the local working copy associated with that URL
>>>>> would be. I'd love to be in a position where the location and even
>>>>> the format of the files could be changed at will, and any impact to
>>>>> whimsy tooling would be contained.
>>>>
>>>> I'm really keen on trying to implement this. So if ASF::SVN is the canonical location for the emeritus directories, what would you suggest we use as labels? If we follow the members.txt example, we would have a single ASF::SVN['emeritus-directory'] that the code didn't know the location of, but the code would still have to know the names of the directories it contained. The svn move command would use the temp directory to do this
>>>> 'svn update emeritus-requests-received/<filename>;
>>>> svn move emeritus-requests-received/<filename> emeritus'
>>>> And then the commit would commit both the members.txt and the tmp directory with the move commands.
>>>>
>>>> Or perhaps ASF::SVN['emeritus-requests-received'] would be a pointer to that directory. And now we have the question of how the svn move from emeritus-requests-received to emeritus would be done.
>>>>
>>>> Would it help to track down all of the scripts and tooling that currently know the location of the emeritus directories?
>>>
>>> You asked a lot of questions. :-)
>>>
>>> Let me make a concrete suggestion. Start with the following file:
>>>
>>> https://github.com/apache/whimsy/blob/master/repository.yml <https://github.com/apache/whimsy/blob/master/repository.yml> <https://github.com/apache/whimsy/blob/master/repository.yml <https://github.com/apache/whimsy/blob/master/repository.yml>>
>>>
>>> Let's take a specific example:
>>>
>>> https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92 <https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92><https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92 <https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92>>
>>>
>>> These two lines (92 and 93) associate an identifier
>>> (emeritus-requests-received) with a url
>>> (private/documents/emeritus-requests-received), and contains other
>>> meta data used by the ASF::SVN module.
>>>
>>> In an ideal world, the secretary should be able to change that URL and
>>> the ONLY thing that would need to be updated is that one line in that
>>> one file and all whimsy tools would operate properly using the new
>>> location. Everything that depends on this information should use
>>> ASF::SVN['emeritus-requests-received'}.
>>
>> Still unanswered: If we have multiple entries (one entry for each of the four emeritus* directories) can we have svn move commands that move files from one directory to another?
>
> Yes, both svn and svnmucc can rename files directly within the repositories.
> However only svnmucc can do multiple remote renames in a single commit.
>
>> I understand how to do it if we have a single ASF::SVN['documents-emeritus'] and the code knows the names of the four sub-directories. I don't know how to handle the svn mv command if we have checked out four temp directories without necessarily knowing the names of the directories. Can we somehow annotate the repository.yml with the names of the subdirectories?
>
> I don't think it's possible to do an svn rename across different workspaces.
>
> AFAIK you have to have a single workspace which includes a common parent.
> If you checkout the full subtree from that parent, then you can
> definitely use the svn client to do multiple renames, mkdir and
> deletes locally.
> A checking will then commit everything or nothing.
> However that is likely to be a big/slow checkout.
>
> I think the workspace does not have to be a full checkout, but
> obviously has to include the relevant files, and possibly the full
> directories of source and destination.
> This is tricky to set up, which is why I suggested svnmucc.
I think we are in agreement that big/slow is not an option.
So using MultiUpdate, how do we construct the extra svn move commands from the ASF::SVN directory names for the emeritus directories?
I don't see how to do it without the application (emeritus.json.rb) knowing the directory names.
Craig
>
>> Craig
>>>
>>> So the thing to track down is all of the scripts and tooling that do
>>> not use ASF::SVN and the identifier specified in repository.yml to
>>> access this information.
>>>
>>>> Craig
>>>
>>> - Sam Ruby
>>>
>>>>> But ultimately, we need people to take ownership of this decision, and
>>>>> a part of that would be a willingness to make the necessary changes to
>>>>> make it work.
>>>>>
>>>>>> Craig
>>>>>
>>>>> - Sam Ruby
>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>
>>>>>>> I agree that would be awkward, but that's not what I meant.
>>>>>>> I am suggesting leaving them all under documents/
>>>>>>
>>>>>> Craig L Russell
>>>>>> clr@apache.org
>>>>
>>>> Craig L Russell
>>>> clr@apache.org
>>
>> Craig L Russell
>> clr@apache.org
Craig L Russell
clr@apache.org
Re: bikeshedding Emeritus file names
Posted by sebb <se...@gmail.com>.
On Tue, 2 Jun 2020 at 19:01, Craig Russell <ap...@gmail.com> wrote:
>
>
>
> > On Jun 2, 2020, at 9:06 AM, Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > On Tue, Jun 2, 2020 at 10:49 AM Craig Russell <apache.clr@gmail.com <ma...@gmail.com>> wrote:
> >>
> >>> On Jun 2, 2020, at 6:35 AM, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net>> wrote:
> >>>
> >>> On Mon, Jun 1, 2020 at 8:50 PM Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>>> wrote:
> >>>>
> >>>>> On Jun 1, 2020, at 4:58 PM, sebb <se...@gmail.com> wrote:
> >>>>>
> >>>>> On Mon, 1 Jun 2020 at 23:20, Craig Russell <ap...@gmail.com> wrote:
> >>>>>>
> >>>>>>> On Jun 1, 2020, at 2:42 PM, sebb <se...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache.clr@gmail.com <ma...@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.
> >>>>>
> >>>>> Changes to the locations of emeritus directories means changes to
> >>>>> whimsy library code as well.
> >>>>> The committer roster relies on this for showing emeritus member docs.
> >>>>> And there are scripts to check emeritus files.
> >>>>>
> >>>>> Introduction of an extra Emeritus parent is going to mean changes to
> >>>>> shared code, so lots of testing needed.
> >>>>
> >>>> Ok. I really don't care if we add two more directories if it means less work for everyone else.
> >>>>
> >>>> Anyone else with a strong opinion here? Sam?
> >>>
> >>> I, too, feel that the current structure is haphazard and disorderly,
> >>> and that the proposal would be an improvement. Minor quibble: the
> >>> redundancy of Emeritus/emeritus-* bothers me.
> >>
> >> I'm open to other ideas that avoid duplication of names.
> >>>
> >>> That being said, my bigger concern is twofold:
> >>
> >> This is in line with what Sebb has been saying, if I can read between the lines.
> >>>
> >>> 1) Effectively, the only documentation for the current structure is
> >>> contained within the whimsy code. Effectively, instead of the
> >>> secretary saying "this is where the data belongs", we make decisions
> >>> based on where a given tool places data and where other tools look for
> >>> data. There is no architecture. Ultimately, this is a failure of the
> >>> secretary. I say that as a former-secretary who both inherited this
> >>> mess and mostly left it to my successors.
> >>
> >> Well, way back in 2018 while I was secretary we started using the emeritus-requests-received directory with no real tool support. We did not architect this but just decided it was better than leaving the request in the workbench queue for later processing.
> >>>
> >>> 2) The code is unnecessarily tightly bound to the location of the
> >>> data, making changes more difficult. Once upon a time, code would
> >>> call ASF:SVN['foobar'] or perhaps ASF::SVN.find('foobar') to locate
> >>> directories, and that library routine would consult things like
> >>> ~/.whimsy.for local tailoring. Over time, there seemed to be little
> >>> interest in maintaining that mapping, and the current state is that if
> >>> you place things in any location other than /srv, things may not work.
> >>
> >> The current tooling does have a mixture of styles. This is from memstat-json.rb:
> >> # identify file to be updated
> >> members_txt = File.join(ASF::SVN['foundation'], 'members.txt')
> >>
> >> So this says that somewhere there is a foundation directory that "someone else" knows the actual location. But it does hard code the name of the file, members.txt.
> >>
> >> Is that ideal from your perspective? Or should the name of the members.txt as well as its location be abstracted to the ASF::SVN metadata?
> >>>
> >>> Ideally, there would be a token or identifier for each of these
> >>> directories, an ASF:SVN or some other place would be the only place
> >>> that knows the mapping of this identifier to the URL as well as the
> >>> location of where the local working copy associated with that URL
> >>> would be. I'd love to be in a position where the location and even
> >>> the format of the files could be changed at will, and any impact to
> >>> whimsy tooling would be contained.
> >>
> >> I'm really keen on trying to implement this. So if ASF::SVN is the canonical location for the emeritus directories, what would you suggest we use as labels? If we follow the members.txt example, we would have a single ASF::SVN['emeritus-directory'] that the code didn't know the location of, but the code would still have to know the names of the directories it contained. The svn move command would use the temp directory to do this
> >> 'svn update emeritus-requests-received/<filename>;
> >> svn move emeritus-requests-received/<filename> emeritus'
> >> And then the commit would commit both the members.txt and the tmp directory with the move commands.
> >>
> >> Or perhaps ASF::SVN['emeritus-requests-received'] would be a pointer to that directory. And now we have the question of how the svn move from emeritus-requests-received to emeritus would be done.
> >>
> >> Would it help to track down all of the scripts and tooling that currently know the location of the emeritus directories?
> >
> > You asked a lot of questions. :-)
> >
> > Let me make a concrete suggestion. Start with the following file:
> >
> > https://github.com/apache/whimsy/blob/master/repository.yml <https://github.com/apache/whimsy/blob/master/repository.yml>
> >
> > Let's take a specific example:
> >
> > https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92 <https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92>
> >
> > These two lines (92 and 93) associate an identifier
> > (emeritus-requests-received) with a url
> > (private/documents/emeritus-requests-received), and contains other
> > meta data used by the ASF::SVN module.
> >
> > In an ideal world, the secretary should be able to change that URL and
> > the ONLY thing that would need to be updated is that one line in that
> > one file and all whimsy tools would operate properly using the new
> > location. Everything that depends on this information should use
> > ASF::SVN['emeritus-requests-received'}.
>
> Still unanswered: If we have multiple entries (one entry for each of the four emeritus* directories) can we have svn move commands that move files from one directory to another?
Yes, both svn and svnmucc can rename files directly within the repositories.
However only svnmucc can do multiple remote renames in a single commit.
> I understand how to do it if we have a single ASF::SVN['documents-emeritus'] and the code knows the names of the four sub-directories. I don't know how to handle the svn mv command if we have checked out four temp directories without necessarily knowing the names of the directories. Can we somehow annotate the repository.yml with the names of the subdirectories?
I don't think it's possible to do an svn rename across different workspaces.
AFAIK you have to have a single workspace which includes a common parent.
If you checkout the full subtree from that parent, then you can
definitely use the svn client to do multiple renames, mkdir and
deletes locally.
A checking will then commit everything or nothing.
However that is likely to be a big/slow checkout.
I think the workspace does not have to be a full checkout, but
obviously has to include the relevant files, and possibly the full
directories of source and destination.
This is tricky to set up, which is why I suggested svnmucc.
> Craig
> >
> > So the thing to track down is all of the scripts and tooling that do
> > not use ASF::SVN and the identifier specified in repository.yml to
> > access this information.
> >
> >> Craig
> >
> > - Sam Ruby
> >
> >>> But ultimately, we need people to take ownership of this decision, and
> >>> a part of that would be a willingness to make the necessary changes to
> >>> make it work.
> >>>
> >>>> Craig
> >>>
> >>> - Sam Ruby
> >>>
> >>>>>>>
> >>>>>>> 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.
> >>>>>
> >>>>> I agree that would be awkward, but that's not what I meant.
> >>>>> I am suggesting leaving them all under documents/
> >>>>
> >>>> Craig L Russell
> >>>> clr@apache.org
> >>
> >> Craig L Russell
> >> clr@apache.org
>
> Craig L Russell
> clr@apache.org
>
Re: bikeshedding Emeritus file names
Posted by Craig Russell <ap...@gmail.com>.
> On Jun 2, 2020, at 9:06 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Tue, Jun 2, 2020 at 10:49 AM Craig Russell <apache.clr@gmail.com <ma...@gmail.com>> wrote:
>>
>>> On Jun 2, 2020, at 6:35 AM, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net>> wrote:
>>>
>>> On Mon, Jun 1, 2020 at 8:50 PM Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>>> wrote:
>>>>
>>>>> On Jun 1, 2020, at 4:58 PM, sebb <se...@gmail.com> wrote:
>>>>>
>>>>> On Mon, 1 Jun 2020 at 23:20, Craig Russell <ap...@gmail.com> wrote:
>>>>>>
>>>>>>> On Jun 1, 2020, at 2:42 PM, sebb <se...@gmail.com> wrote:
>>>>>>>
>>>>>>> On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache.clr@gmail.com <ma...@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.
>>>>>
>>>>> Changes to the locations of emeritus directories means changes to
>>>>> whimsy library code as well.
>>>>> The committer roster relies on this for showing emeritus member docs.
>>>>> And there are scripts to check emeritus files.
>>>>>
>>>>> Introduction of an extra Emeritus parent is going to mean changes to
>>>>> shared code, so lots of testing needed.
>>>>
>>>> Ok. I really don't care if we add two more directories if it means less work for everyone else.
>>>>
>>>> Anyone else with a strong opinion here? Sam?
>>>
>>> I, too, feel that the current structure is haphazard and disorderly,
>>> and that the proposal would be an improvement. Minor quibble: the
>>> redundancy of Emeritus/emeritus-* bothers me.
>>
>> I'm open to other ideas that avoid duplication of names.
>>>
>>> That being said, my bigger concern is twofold:
>>
>> This is in line with what Sebb has been saying, if I can read between the lines.
>>>
>>> 1) Effectively, the only documentation for the current structure is
>>> contained within the whimsy code. Effectively, instead of the
>>> secretary saying "this is where the data belongs", we make decisions
>>> based on where a given tool places data and where other tools look for
>>> data. There is no architecture. Ultimately, this is a failure of the
>>> secretary. I say that as a former-secretary who both inherited this
>>> mess and mostly left it to my successors.
>>
>> Well, way back in 2018 while I was secretary we started using the emeritus-requests-received directory with no real tool support. We did not architect this but just decided it was better than leaving the request in the workbench queue for later processing.
>>>
>>> 2) The code is unnecessarily tightly bound to the location of the
>>> data, making changes more difficult. Once upon a time, code would
>>> call ASF:SVN['foobar'] or perhaps ASF::SVN.find('foobar') to locate
>>> directories, and that library routine would consult things like
>>> ~/.whimsy.for local tailoring. Over time, there seemed to be little
>>> interest in maintaining that mapping, and the current state is that if
>>> you place things in any location other than /srv, things may not work.
>>
>> The current tooling does have a mixture of styles. This is from memstat-json.rb:
>> # identify file to be updated
>> members_txt = File.join(ASF::SVN['foundation'], 'members.txt')
>>
>> So this says that somewhere there is a foundation directory that "someone else" knows the actual location. But it does hard code the name of the file, members.txt.
>>
>> Is that ideal from your perspective? Or should the name of the members.txt as well as its location be abstracted to the ASF::SVN metadata?
>>>
>>> Ideally, there would be a token or identifier for each of these
>>> directories, an ASF:SVN or some other place would be the only place
>>> that knows the mapping of this identifier to the URL as well as the
>>> location of where the local working copy associated with that URL
>>> would be. I'd love to be in a position where the location and even
>>> the format of the files could be changed at will, and any impact to
>>> whimsy tooling would be contained.
>>
>> I'm really keen on trying to implement this. So if ASF::SVN is the canonical location for the emeritus directories, what would you suggest we use as labels? If we follow the members.txt example, we would have a single ASF::SVN['emeritus-directory'] that the code didn't know the location of, but the code would still have to know the names of the directories it contained. The svn move command would use the temp directory to do this
>> 'svn update emeritus-requests-received/<filename>;
>> svn move emeritus-requests-received/<filename> emeritus'
>> And then the commit would commit both the members.txt and the tmp directory with the move commands.
>>
>> Or perhaps ASF::SVN['emeritus-requests-received'] would be a pointer to that directory. And now we have the question of how the svn move from emeritus-requests-received to emeritus would be done.
>>
>> Would it help to track down all of the scripts and tooling that currently know the location of the emeritus directories?
>
> You asked a lot of questions. :-)
>
> Let me make a concrete suggestion. Start with the following file:
>
> https://github.com/apache/whimsy/blob/master/repository.yml <https://github.com/apache/whimsy/blob/master/repository.yml>
>
> Let's take a specific example:
>
> https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92 <https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92>
>
> These two lines (92 and 93) associate an identifier
> (emeritus-requests-received) with a url
> (private/documents/emeritus-requests-received), and contains other
> meta data used by the ASF::SVN module.
>
> In an ideal world, the secretary should be able to change that URL and
> the ONLY thing that would need to be updated is that one line in that
> one file and all whimsy tools would operate properly using the new
> location. Everything that depends on this information should use
> ASF::SVN['emeritus-requests-received'}.
Still unanswered: If we have multiple entries (one entry for each of the four emeritus* directories) can we have svn move commands that move files from one directory to another?
I understand how to do it if we have a single ASF::SVN['documents-emeritus'] and the code knows the names of the four sub-directories. I don't know how to handle the svn mv command if we have checked out four temp directories without necessarily knowing the names of the directories. Can we somehow annotate the repository.yml with the names of the subdirectories?
Craig
>
> So the thing to track down is all of the scripts and tooling that do
> not use ASF::SVN and the identifier specified in repository.yml to
> access this information.
>
>> Craig
>
> - Sam Ruby
>
>>> But ultimately, we need people to take ownership of this decision, and
>>> a part of that would be a willingness to make the necessary changes to
>>> make it work.
>>>
>>>> Craig
>>>
>>> - Sam Ruby
>>>
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>> I agree that would be awkward, but that's not what I meant.
>>>>> I am suggesting leaving them all under documents/
>>>>
>>>> Craig L Russell
>>>> clr@apache.org
>>
>> Craig L Russell
>> clr@apache.org
Craig L Russell
clr@apache.org
Re: bikeshedding Emeritus file names
Posted by Sam Ruby <ru...@intertwingly.net>.
On Tue, Jun 2, 2020 at 10:49 AM Craig Russell <ap...@gmail.com> wrote:
>
> > On Jun 2, 2020, at 6:35 AM, Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > On Mon, Jun 1, 2020 at 8:50 PM Craig Russell <apache.clr@gmail.com <ma...@gmail.com>> wrote:
> >>
> >>> On Jun 1, 2020, at 4:58 PM, sebb <se...@gmail.com> wrote:
> >>>
> >>> On Mon, 1 Jun 2020 at 23:20, Craig Russell <ap...@gmail.com> wrote:
> >>>>
> >>>>> On Jun 1, 2020, at 2:42 PM, sebb <se...@gmail.com> wrote:
> >>>>>
> >>>>> On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache.clr@gmail.com <ma...@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.
> >>>
> >>> Changes to the locations of emeritus directories means changes to
> >>> whimsy library code as well.
> >>> The committer roster relies on this for showing emeritus member docs.
> >>> And there are scripts to check emeritus files.
> >>>
> >>> Introduction of an extra Emeritus parent is going to mean changes to
> >>> shared code, so lots of testing needed.
> >>
> >> Ok. I really don't care if we add two more directories if it means less work for everyone else.
> >>
> >> Anyone else with a strong opinion here? Sam?
> >
> > I, too, feel that the current structure is haphazard and disorderly,
> > and that the proposal would be an improvement. Minor quibble: the
> > redundancy of Emeritus/emeritus-* bothers me.
>
> I'm open to other ideas that avoid duplication of names.
> >
> > That being said, my bigger concern is twofold:
>
> This is in line with what Sebb has been saying, if I can read between the lines.
> >
> > 1) Effectively, the only documentation for the current structure is
> > contained within the whimsy code. Effectively, instead of the
> > secretary saying "this is where the data belongs", we make decisions
> > based on where a given tool places data and where other tools look for
> > data. There is no architecture. Ultimately, this is a failure of the
> > secretary. I say that as a former-secretary who both inherited this
> > mess and mostly left it to my successors.
>
> Well, way back in 2018 while I was secretary we started using the emeritus-requests-received directory with no real tool support. We did not architect this but just decided it was better than leaving the request in the workbench queue for later processing.
> >
> > 2) The code is unnecessarily tightly bound to the location of the
> > data, making changes more difficult. Once upon a time, code would
> > call ASF:SVN['foobar'] or perhaps ASF::SVN.find('foobar') to locate
> > directories, and that library routine would consult things like
> > ~/.whimsy.for local tailoring. Over time, there seemed to be little
> > interest in maintaining that mapping, and the current state is that if
> > you place things in any location other than /srv, things may not work.
>
> The current tooling does have a mixture of styles. This is from memstat-json.rb:
> # identify file to be updated
> members_txt = File.join(ASF::SVN['foundation'], 'members.txt')
>
> So this says that somewhere there is a foundation directory that "someone else" knows the actual location. But it does hard code the name of the file, members.txt.
>
> Is that ideal from your perspective? Or should the name of the members.txt as well as its location be abstracted to the ASF::SVN metadata?
> >
> > Ideally, there would be a token or identifier for each of these
> > directories, an ASF:SVN or some other place would be the only place
> > that knows the mapping of this identifier to the URL as well as the
> > location of where the local working copy associated with that URL
> > would be. I'd love to be in a position where the location and even
> > the format of the files could be changed at will, and any impact to
> > whimsy tooling would be contained.
>
> I'm really keen on trying to implement this. So if ASF::SVN is the canonical location for the emeritus directories, what would you suggest we use as labels? If we follow the members.txt example, we would have a single ASF::SVN['emeritus-directory'] that the code didn't know the location of, but the code would still have to know the names of the directories it contained. The svn move command would use the temp directory to do this
> 'svn update emeritus-requests-received/<filename>;
> svn move emeritus-requests-received/<filename> emeritus'
> And then the commit would commit both the members.txt and the tmp directory with the move commands.
>
> Or perhaps ASF::SVN['emeritus-requests-received'] would be a pointer to that directory. And now we have the question of how the svn move from emeritus-requests-received to emeritus would be done.
>
> Would it help to track down all of the scripts and tooling that currently know the location of the emeritus directories?
You asked a lot of questions. :-)
Let me make a concrete suggestion. Start with the following file:
https://github.com/apache/whimsy/blob/master/repository.yml
Let's take a specific example:
https://github.com/apache/whimsy/blob/28c2df1c46090ef504a2fa0227ee5bed94429abc/repository.yml#L92
These two lines (92 and 93) associate an identifier
(emeritus-requests-received) with a url
(private/documents/emeritus-requests-received), and contains other
meta data used by the ASF::SVN module.
In an ideal world, the secretary should be able to change that URL and
the ONLY thing that would need to be updated is that one line in that
one file and all whimsy tools would operate properly using the new
location. Everything that depends on this information should use
ASF::SVN['emeritus-requests-received'}.
So the thing to track down is all of the scripts and tooling that do
not use ASF::SVN and the identifier specified in repository.yml to
access this information.
> Craig
- Sam Ruby
> > But ultimately, we need people to take ownership of this decision, and
> > a part of that would be a willingness to make the necessary changes to
> > make it work.
> >
> >> Craig
> >
> > - Sam Ruby
> >
> >>>>>
> >>>>> 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.
> >>>
> >>> I agree that would be awkward, but that's not what I meant.
> >>> I am suggesting leaving them all under documents/
> >>
> >> Craig L Russell
> >> clr@apache.org
>
> Craig L Russell
> clr@apache.org
>
Re: bikeshedding Emeritus file names
Posted by Craig Russell <ap...@gmail.com>.
> On Jun 2, 2020, at 6:35 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Mon, Jun 1, 2020 at 8:50 PM Craig Russell <apache.clr@gmail.com <ma...@gmail.com>> wrote:
>>
>>> On Jun 1, 2020, at 4:58 PM, sebb <se...@gmail.com> wrote:
>>>
>>> On Mon, 1 Jun 2020 at 23:20, Craig Russell <ap...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>> On Jun 1, 2020, at 2:42 PM, sebb <se...@gmail.com> wrote:
>>>>>
>>>>> On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache.clr@gmail.com <ma...@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.
>>>
>>> Changes to the locations of emeritus directories means changes to
>>> whimsy library code as well.
>>> The committer roster relies on this for showing emeritus member docs.
>>> And there are scripts to check emeritus files.
>>>
>>> Introduction of an extra Emeritus parent is going to mean changes to
>>> shared code, so lots of testing needed.
>>
>> Ok. I really don't care if we add two more directories if it means less work for everyone else.
>>
>> Anyone else with a strong opinion here? Sam?
>
> I, too, feel that the current structure is haphazard and disorderly,
> and that the proposal would be an improvement. Minor quibble: the
> redundancy of Emeritus/emeritus-* bothers me.
I'm open to other ideas that avoid duplication of names.
>
> That being said, my bigger concern is twofold:
This is in line with what Sebb has been saying, if I can read between the lines.
>
> 1) Effectively, the only documentation for the current structure is
> contained within the whimsy code. Effectively, instead of the
> secretary saying "this is where the data belongs", we make decisions
> based on where a given tool places data and where other tools look for
> data. There is no architecture. Ultimately, this is a failure of the
> secretary. I say that as a former-secretary who both inherited this
> mess and mostly left it to my successors.
Well, way back in 2018 while I was secretary we started using the emeritus-requests-received directory with no real tool support. We did not architect this but just decided it was better than leaving the request in the workbench queue for later processing.
>
> 2) The code is unnecessarily tightly bound to the location of the
> data, making changes more difficult. Once upon a time, code would
> call ASF:SVN['foobar'] or perhaps ASF::SVN.find('foobar') to locate
> directories, and that library routine would consult things like
> ~/.whimsy.for local tailoring. Over time, there seemed to be little
> interest in maintaining that mapping, and the current state is that if
> you place things in any location other than /srv, things may not work.
The current tooling does have a mixture of styles. This is from memstat-json.rb:
# identify file to be updated
members_txt = File.join(ASF::SVN['foundation'], 'members.txt')
So this says that somewhere there is a foundation directory that "someone else" knows the actual location. But it does hard code the name of the file, members.txt.
Is that ideal from your perspective? Or should the name of the members.txt as well as its location be abstracted to the ASF::SVN metadata?
>
> Ideally, there would be a token or identifier for each of these
> directories, an ASF:SVN or some other place would be the only place
> that knows the mapping of this identifier to the URL as well as the
> location of where the local working copy associated with that URL
> would be. I'd love to be in a position where the location and even
> the format of the files could be changed at will, and any impact to
> whimsy tooling would be contained.
I'm really keen on trying to implement this. So if ASF::SVN is the canonical location for the emeritus directories, what would you suggest we use as labels? If we follow the members.txt example, we would have a single ASF::SVN['emeritus-directory'] that the code didn't know the location of, but the code would still have to know the names of the directories it contained. The svn move command would use the temp directory to do this
'svn update emeritus-requests-received/<filename>;
svn move emeritus-requests-received/<filename> emeritus'
And then the commit would commit both the members.txt and the tmp directory with the move commands.
Or perhaps ASF::SVN['emeritus-requests-received'] would be a pointer to that directory. And now we have the question of how the svn move from emeritus-requests-received to emeritus would be done.
Would it help to track down all of the scripts and tooling that currently know the location of the emeritus directories?
Craig
>
> But ultimately, we need people to take ownership of this decision, and
> a part of that would be a willingness to make the necessary changes to
> make it work.
>
>> Craig
>
> - Sam Ruby
>
>>>>>
>>>>> 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.
>>>
>>> I agree that would be awkward, but that's not what I meant.
>>> I am suggesting leaving them all under documents/
>>
>> Craig L Russell
>> clr@apache.org
Craig L Russell
clr@apache.org
Re: bikeshedding Emeritus file names
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Jun 1, 2020 at 8:50 PM Craig Russell <ap...@gmail.com> wrote:
>
> > On Jun 1, 2020, at 4:58 PM, sebb <se...@gmail.com> wrote:
> >
> > On Mon, 1 Jun 2020 at 23:20, Craig Russell <ap...@gmail.com> wrote:
> >>
> >>
> >>
> >>> On Jun 1, 2020, at 2:42 PM, sebb <se...@gmail.com> wrote:
> >>>
> >>> On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache.clr@gmail.com <ma...@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.
> >
> > Changes to the locations of emeritus directories means changes to
> > whimsy library code as well.
> > The committer roster relies on this for showing emeritus member docs.
> > And there are scripts to check emeritus files.
> >
> > Introduction of an extra Emeritus parent is going to mean changes to
> > shared code, so lots of testing needed.
>
> Ok. I really don't care if we add two more directories if it means less work for everyone else.
>
> Anyone else with a strong opinion here? Sam?
I, too, feel that the current structure is haphazard and disorderly,
and that the proposal would be an improvement. Minor quibble: the
redundancy of Emeritus/emeritus-* bothers me.
That being said, my bigger concern is twofold:
1) Effectively, the only documentation for the current structure is
contained within the whimsy code. Effectively, instead of the
secretary saying "this is where the data belongs", we make decisions
based on where a given tool places data and where other tools look for
data. There is no architecture. Ultimately, this is a failure of the
secretary. I say that as a former-secretary who both inherited this
mess and mostly left it to my successors.
2) The code is unnecessarily tightly bound to the location of the
data, making changes more difficult. Once upon a time, code would
call ASF:SVN['foobar'] or perhaps ASF::SVN.find('foobar') to locate
directories, and that library routine would consult things like
~/.whimsy.for local tailoring. Over time, there seemed to be little
interest in maintaining that mapping, and the current state is that if
you place things in any location other than /srv, things may not work.
Ideally, there would be a token or identifier for each of these
directories, an ASF:SVN or some other place would be the only place
that knows the mapping of this identifier to the URL as well as the
location of where the local working copy associated with that URL
would be. I'd love to be in a position where the location and even
the format of the files could be changed at will, and any impact to
whimsy tooling would be contained.
But ultimately, we need people to take ownership of this decision, and
a part of that would be a willingness to make the necessary changes to
make it work.
> Craig
- Sam Ruby
> >>>
> >>> 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.
> >
> > I agree that would be awkward, but that's not what I meant.
> > I am suggesting leaving them all under documents/
>
> Craig L Russell
> clr@apache.org
>
Re: bikeshedding Emeritus file names
Posted by sebb <se...@gmail.com>.
On Tue, 2 Jun 2020 at 01:50, Craig Russell <ap...@gmail.com> wrote:
>
>
>
> > On Jun 1, 2020, at 4:58 PM, sebb <se...@gmail.com> wrote:
> >
> > On Mon, 1 Jun 2020 at 23:20, Craig Russell <ap...@gmail.com> wrote:
> >>
> >>
> >>
> >>> On Jun 1, 2020, at 2:42 PM, sebb <se...@gmail.com> wrote:
> >>>
> >>> On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache.clr@gmail.com <ma...@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.
> >
> > Changes to the locations of emeritus directories means changes to
> > whimsy library code as well.
> > The committer roster relies on this for showing emeritus member docs.
> > And there are scripts to check emeritus files.
> >
> > Introduction of an extra Emeritus parent is going to mean changes to
> > shared code, so lots of testing needed.
>
> Ok. I really don't care if we add two more directories if it means less work for everyone else.
Not sure what these two more directories are?
Currently documents/ has the following emeritus dirs:
emeritus/
emeritus-rejoined/
emeritus-requests-received/
emeritus-requests-rescinded/
AIUI you were proposing to move all of these to be under the new directory:
documents/Emeritus
I think that's unnecessary, and will hardly reduce the coding needed.
> Anyone else with a strong opinion here? Sam?
>
> Craig
> >
> >>>
> >>> 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.
> >
> > I agree that would be awkward, but that's not what I meant.
> > I am suggesting leaving them all under documents/
>
> Craig L Russell
> clr@apache.org
>
Re: bikeshedding Emeritus file names
Posted by Craig Russell <ap...@gmail.com>.
> On Jun 1, 2020, at 4:58 PM, sebb <se...@gmail.com> wrote:
>
> On Mon, 1 Jun 2020 at 23:20, Craig Russell <ap...@gmail.com> wrote:
>>
>>
>>
>>> On Jun 1, 2020, at 2:42 PM, sebb <se...@gmail.com> wrote:
>>>
>>> On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache.clr@gmail.com <ma...@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.
>
> Changes to the locations of emeritus directories means changes to
> whimsy library code as well.
> The committer roster relies on this for showing emeritus member docs.
> And there are scripts to check emeritus files.
>
> Introduction of an extra Emeritus parent is going to mean changes to
> shared code, so lots of testing needed.
Ok. I really don't care if we add two more directories if it means less work for everyone else.
Anyone else with a strong opinion here? Sam?
Craig
>
>>>
>>> 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.
>
> I agree that would be awkward, but that's not what I meant.
> I am suggesting leaving them all under documents/
Craig L Russell
clr@apache.org
Re: bikeshedding Emeritus file names
Posted by sebb <se...@gmail.com>.
On Mon, 1 Jun 2020 at 23:20, Craig Russell <ap...@gmail.com> wrote:
>
>
>
> > On Jun 1, 2020, at 2:42 PM, sebb <se...@gmail.com> wrote:
> >
> > On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache.clr@gmail.com <ma...@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.
Changes to the locations of emeritus directories means changes to
whimsy library code as well.
The committer roster relies on this for showing emeritus member docs.
And there are scripts to check emeritus files.
Introduction of an extra Emeritus parent is going to mean changes to
shared code, so lots of testing needed.
> >
> > 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.
I agree that would be awkward, but that's not what I meant.
I am suggesting leaving them all under documents/
Re: bikeshedding Emeritus file names
Posted by Craig Russell <ap...@gmail.com>.
> On Jun 1, 2020, at 2:42 PM, sebb <se...@gmail.com> wrote:
>
> On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache.clr@gmail.com <ma...@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 <sebbaz@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> On Sun, 31 May 2020 at 22:18, Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@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.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On May 31, 2020, at 5:55 AM, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net> <mailto:rubys@intertwingly.net <ma...@intertwingly.net>> <mailto:rubys@intertwingly.net <ma...@intertwingly.net><mailto:rubys@intertwingly.net <ma...@intertwingly.net>>>> wrote:
>>>>>>
>>>>>> On Sun, May 31, 2020 at 12:50 AM Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@gmail.com>> <mailto:apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@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
>>>>> clr@apache.org <ma...@apache.org> <mailto:clr@apache.org <ma...@apache.org>> <mailto:clr@apache.org <ma...@apache.org> <mailto:clr@apache.org <ma...@apache.org>>>
>>>> Craig L Russell
>>>> clr@apache.org <ma...@apache.org> <mailto:clr@apache.org <ma...@apache.org>>
>> Craig L Russell
>> clr@apache.org <ma...@apache.org>
Craig L Russell
clr@apache.org
Re: bikeshedding Emeritus file names
Posted by sebb <se...@gmail.com>.
On Mon, 1 Jun 2020 at 22:30, Craig Russell <ap...@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 <se...@gmail.com> wrote:
> >
> > On Sun, 31 May 2020 at 22:18, Craig Russell <apache.clr@gmail.com <ma...@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.clr@gmail.com <ma...@gmail.com>> wrote:
> >>>
> >>>
> >>>
> >>>> On May 31, 2020, at 5:55 AM, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net> <mailto:rubys@intertwingly.net <ma...@intertwingly.net>>> wrote:
> >>>>
> >>>> On Sun, May 31, 2020 at 12:50 AM Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@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
> >>> clr@apache.org <ma...@apache.org> <mailto:clr@apache.org <ma...@apache.org>>
> >> Craig L Russell
> >> clr@apache.org <ma...@apache.org>
> Craig L Russell
> clr@apache.org
>
Re: bikeshedding Emeritus file names
Posted by Craig Russell <ap...@gmail.com>.
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 <se...@gmail.com> wrote:
>
> On Sun, 31 May 2020 at 22:18, Craig Russell <apache.clr@gmail.com <ma...@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.clr@gmail.com <ma...@gmail.com>> wrote:
>>>
>>>
>>>
>>>> On May 31, 2020, at 5:55 AM, Sam Ruby <rubys@intertwingly.net <ma...@intertwingly.net> <mailto:rubys@intertwingly.net <ma...@intertwingly.net>>> wrote:
>>>>
>>>> On Sun, May 31, 2020 at 12:50 AM Craig Russell <apache.clr@gmail.com <ma...@gmail.com> <mailto:apache.clr@gmail.com <ma...@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
>>> clr@apache.org <ma...@apache.org> <mailto:clr@apache.org <ma...@apache.org>>
>> Craig L Russell
>> clr@apache.org <ma...@apache.org>
Craig L Russell
clr@apache.org