On Tue, Jun 2, 2020 at 10:49 AM Craig Russell <apache....@gmail.com> wrote: > > > On Jun 2, 2020, at 6:35 AM, Sam Ruby <ru...@intertwingly.net> wrote: > > > > On Mon, Jun 1, 2020 at 8:50 PM Craig Russell <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 Let's take a specific example: 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'}. 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 >
