> On Jun 2, 2020, at 12:26 PM, sebb <seb...@gmail.com> wrote: > > On Tue, 2 Jun 2020 at 20:23, Sam Ruby <ru...@intertwingly.net > <mailto:ru...@intertwingly.net>> wrote: >> >> On Tue, Jun 2, 2020 at 3:16 PM Craig Russell <apache....@gmail.com> wrote: >>> >>>> 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. >> >> 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 >>>>>>>>> c...@apache.org >>>>>>> >>>>>>> Craig L Russell >>>>>>> c...@apache.org >>>>> >>>>> Craig L Russell >>>>> c...@apache.org >>> >>> Craig L Russell >>> c...@apache.org Craig L Russell c...@apache.org
