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 <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. > > > > 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 > >
