On Mon, Jun 1, 2020 at 8:50 PM Craig Russell <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.
That being said, my bigger concern is twofold:
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.
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.
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.
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
>
