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