Public SourceMage Discussion List

[Bor Kraljič <pyrobor AT ver.si>]

On 31. MES 2011 19:28:26 Jeremy wrote:
> On Wed, 2011-08-31 at 09:13 +0200, Bor Kraljič wrote:
> > On 31. MES 2011 00:52:45 Remko van der Vossen wrote:
> > > Okay guys, here we go, the long awaited mail on grimoire splitting.
> > > I
> > > have to warn you though, it'll be long. Sorry about that.
> > 
> > Well long mail but I managed to read it. Ideas are nice! Realisation is
> > another thing.
> > 
> > > First, let's look at some of the major problems we are having;
> > > 
> > >   1. We have a lot of bitrot, a lot spells which have not been
> > >   touched
> > >   
> > >      in ages, spells which are simply not updated, or spells of
> > >      software which has been abandoned and left to rot.
> > >   
> > >   2. We have a lot of spells which are updated haphazardly, with
> > >   barely
> > >   
> > >      any testing, breaking a lot of peoples' boxes.
> > >   
> > >   3. We have a lot of development going on in branches, which goes
> > >   
> > >      largely untested as there is no simple way for people to
> > >      test these kinds of updates easily, leading to good
> > >      development work wasted and left to rot.
> > > 
> > > These are things that really hurt us hard. It hurts our users, which
> > > includes us developers, who are left with random breakages every now
> > > and again which consume time and cause frustration. It also hurts
> > > us as developers in another way, as it feels that our development
> > > efforts go to waste, either they are left to rot, or people either
> > > complain that nothing gets done, or they complain that you broke
> > > stuff. All of this leads, understanibly, to frustration with the
> > > distro, a feeling that we aren't going anywhere and a general
> > > apathy towards the distro.
> > > 
> > > My idea to address these issues is to split the grimoire along
> > > various,
> > > flexible dimensions. Firstly, to address the first two problems, I'd
> > > like to split the grimoire along a quality assurance dimension. I'd
> > > like for us to have a core grimoire, which contains the spells from
> > > basesystem and the spells we include on our ISO. These spells need
> > > to work *at all times*, we need to have these spells working
> > > properly to make sure that ISO generation can be maintained without
> > > cauldron having to fix stupid problems everywhere, they need to be
> > > able to concentrate on actually generating the ISO.
> > > 
> > > To guard this quality of spells in the core grimoire, I'd like to
> > > see us expand the spells in this core grimoire with proper QA
> > > scripting. This scripting should allow us to easily ensure that
> > > spells work properly, it should test casting of each of the spells
> > > from previous stable release as well as previous ISO release,
> > > although I'd like us to synchronise stable releases of this core
> > > grimoire and ISO, but that's something for later. But merely
> > > casting is not sufficient, we need to develop QA scripting to
> > > actually test the functionality of the installed software. Now,
> > > this is of course quite a bit of a task and I understand that this
> > > won't be done next week, however, if we split this core group of
> > > spells into a separate grimoire we have a clear scope of what needs
> > > to be done, we have a clear goal to reach, this should be something
> > > that we can accomplish.
> > > 
> > > The next level of our ring of QA grimoires should be a grimoire of
> > > spells with the same level of automated QA testing, however for this
> > > grimoire the contents aren't defined by what's on the ISO or any
> > > such
> > > thing, instead we just add spells to this grimoire as and when we
> > > add
> > > proper QA scripting to these spells, which we'll do after we add QA
> > > scripting to all the spells in the core grimoire.
> > > 
> > > Level three of our little ring of grimoires should be a grimoire of
> > > maintained spells, that is, spells which have been picked up by a
> > > specific maintainer who is responsible for keeping the given spell
> > > up to date and in good order. I propose we reinstate the UPDATED
> > > field in DETAILS and add a CHECKED field as well. The UPDATED field
> > > should be updated as the spell is updated. The CHECKED field should
> > > be updated when the maintainer has performed a proper check of the
> > > spell, that is, checked the spell can be properly cast, preferably
> > > from both stable as well as ISO, and that the software works
> > > properly. If both UPDATED and CHECKED are more than a year ago the
> > > software will be nominted to be bumped from the maintained grimoire
> > > in three months. If either UPDATED or CHECKED is more than three
> > > years ago, the software should also be nominated to be bumped in
> > > three months. Of course we should automate this checking and
> > > bumping.
> > > 
> > > That leaves the grimoire of unmaintained spells, which is simply
> > > everything else. This gives us four grimoires, the names of which we
> > > can make properly magical in due time;
> > > 
> > >   1. core
> > >   2. tested
> > >   3. maintained
> > >   4. unmaintaied
> > 
> > IMO we don't need maintained and tested. However that is just the matter
> > of taste more or less. But first problem I see is:
> > 
> > How do users migrate users from one grimoire (test or stable) to 4 of
> > them?
> The existing grimoire listing appears to operate as a stack,
>   the last grimoire added provides the first copy of the spell found.
> 
> so the end-result would be a larger listing of grimoires :)
I agree that the end-result is OK. But how do you add that new grimoires to 
user?

Let me explain. User has one grimoire (stable). It does "scribe update" and 
now that stable grimoire is cut half of the spells is missing. We need to 
provide that when user does that scribe update new split grimoires are added. 
Perhaps not even all. Just the ones he needs.