> 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?
Craig
>
> 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
