Public SourceMage Discussion List

["Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>]

On Apr 05, Jeremy Blosser (emrys) [jblosser-smgl AT firinn.org] wrote:
> On Apr 05, Seth Alan Woolley [seth AT positivism.org] wrote:
> > On Tue, Apr 05, 2005 at 01:03:42PM -0500, Jeremy Blosser (emrys) wrote:
> > > 1) As already suggested, continue to sort the grimoire by a taxonomy, 
> > > but
> > >    add a MAINTAINER back to individual spells.  The section maintainer 
> > > wins
> > >    if the spell doesn't have one, but if the spell has one it wins.  
> > > Then
> > >    go a step farther and create some guru-tools that make it easy for
> > >    maintainers to grab just their own spells into a work area and go 
> > > from
> > >    there.  This is the right place for new tools, stuff that just
> > >    maintainers have to worry about.  This avoids the turnover problem as
> > >    well and is probably the right way to do it if we can figure out what
> > >    tools we need for the maintainers.
> > 
> > We got rid of MAINTAINERS for a reason -- they were never accurate.
> 
> Hrm, this should tell us something.  :-)

I want to get back to this one because it's the one the most people have
indicated some kind of favor toward.  The main objection has been that the
MAINTAINERS variable didn't work; without knowing the history I'll take
your word for it, but let's see if we can solve that problem so we can just
move on with fixing the overloaded sections.

Taking some hints for the other thread about per-maintainer "grimoires",
what if we suggest something similar to the following:

1) maintainers scribe the devel/test/stable grimoires (they do this already)

2) they also scribe a local grimoire (most probably do this too)

3) they use scribbler to link the spells they maintain from devel to their
   local grimoire (a lot are probably doing something like this already)

It seems to me then the main thing we're missing is a way to automagically
detect what's being maintained and by whom.  We just need a way to
formalize #3 above and make the matainainence information flow upstream.

One way to do this would be to go ahead and add per-maintainer grimoires in
p4, instead of it just being local.  People who wanted to maintain a
certain spell could do so by moving it from devel to their named grimoire.
This makes devel the "unmaintained" section, and makes it easy for people
to see who is maintaining what.  Code promotion goes from devel or
maintainer grimoires to test as it does now, which is the point at which
the maintainer distinction disappears for users.

Taking this a step further (and closer to what we have now), devel isn't
"unmaintained", it's maintained by the section maintainers as we have
today.  They're responsible at the section level for federating out
individual spells to the people that want to use/maintain them, and then
tracking if that person dies and they need to bring that spell back in and
take care of it themselves.  We also keep MAINTAINER at a section level
because the section maintainers are really the ones responsible for those
spells in a QA/bugzilla perspective.

Does this make sense?  Basically we do exactly what we do now, but we clean
up and standardize the grimoire sections some and let the general gurus
have their own grimoire-level area in p4 and request specific spells they
want to maintain be assigned to them there.  This requires basically no
changes to what we conceptually have now but allows for what I think you
guys are after.  As main maintainer I'm already farming out the MTAs to
those that use them, I would love it if I could actually let them take it
this way but still be able to track the level of QC they're getting.

I realize it doesn't address Andrew's concerns with moving spells around
and breaking the existing inheritance.

Also, one modifications on this would be to make some tools so they don't
actually move the spell from devel to their grimoire, they just somehow
mark it there (like scribbler but in a way that supports p4 and what we
need).  I'm not sure if we actually need this, though.

Attachment: pgpVXgyViGVsU.pgp
Description: PGP signature