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. > 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 > >>>>>> c...@apache.org > >>>> > >>>> Craig L Russell > >>>> c...@apache.org > >> > >> Craig L Russell > >> c...@apache.org > > Craig L Russell > c...@apache.org >
