> On Jun 2, 2020, at 11:27 AM, sebb <seb...@gmail.com> wrote: > > On Tue, 2 Jun 2020 at 19:01, Craig Russell <apache....@gmail.com > <mailto:apache....@gmail.com>> wrote: >> >> >> >>> On Jun 2, 2020, at 9:06 AM, Sam Ruby <ru...@intertwingly.net >>> <mailto:ru...@intertwingly.net>> wrote: >>> >>> On Tue, Jun 2, 2020 at 10:49 AM Craig Russell <apache....@gmail.com >>> <mailto:apache....@gmail.com> <mailto:apache....@gmail.com >>> <mailto:apache....@gmail.com>>> wrote: >>>> >>>>> On Jun 2, 2020, at 6:35 AM, Sam Ruby <ru...@intertwingly.net >>>>> <mailto:ru...@intertwingly.net> <mailto:ru...@intertwingly.net >>>>> <mailto:ru...@intertwingly.net>>> wrote: >>>>> >>>>> On Mon, Jun 1, 2020 at 8:50 PM Craig Russell <apache....@gmail.com >>>>> <mailto:apache....@gmail.com> <mailto:apache....@gmail.com >>>>> <mailto:apache....@gmail.com>> <mailto:apache....@gmail.com >>>>> <mailto:apache....@gmail.com> <mailto:apache....@gmail.com >>>>> <mailto:apache....@gmail.com>>>> wrote: >>>>>> >>>>>>> On Jun 1, 2020, at 4:58 PM, sebb <seb...@gmail.com >>>>>>> <mailto:seb...@gmail.com>> wrote: >>>>>>> >>>>>>> On Mon, 1 Jun 2020 at 23:20, Craig Russell <apache....@gmail.com >>>>>>> <mailto:apache....@gmail.com>> wrote: >>>>>>>> >>>>>>>>> On Jun 1, 2020, at 2:42 PM, sebb <seb...@gmail.com >>>>>>>>> <mailto:seb...@gmail.com>> wrote: >>>>>>>>> >>>>>>>>> On Mon, 1 Jun 2020 at 22:30, Craig Russell <apache....@gmail.com >>>>>>>>> <mailto:apache....@gmail.com> <mailto:apache....@gmail.com >>>>>>>>> <mailto:apache....@gmail.com>>> wrote: >>>>>>>>>> >>>>>>>>>> OK. >>>>>>>>>> >>>>>>>>>> How about this proposal: >>>>>>>>>> >>>>>>>>>> New directory documents/Emeritus with these directories: >>>>>>>>>> emeritus for accepted requests >>>>>>>>>> emeritus-requests-received for received requests >>>>>>>>>> emeritus-requests-rescinded for rescinded requests >>>>>>>>>> emeritus-reinstated for original requests from reinstated Members >>>>>>>>> >>>>>>>>> This will mean changes to Whimsy code, and could result in temporary >>>>>>>>> breakage as well as needing extra testing. >>>>>>>> >>>>>>>> The only Whimsy code that needs to change is secretary workbench which >>>>>>>> currently stores requests in documents/emeritus-requests-received. All >>>>>>>> other code is the stuff I'm working on. >>>>>>> >>>>>>> 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 >>>>>> c...@apache.org >>>> >>>> Craig L Russell >>>> c...@apache.org >> >> Craig L Russell >> c...@apache.org Craig L Russell c...@apache.org
