Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

On Thursday 01 March 2007 07:47:33 Jeremy Blosser wrote:
<snip>
> Topics I would like to see possible candidates discuss:
>
> - Approach to release cycle.  The project has basically started doing these
>   on our own, but I expect the control to go back to the Grimoire Lead at
>   some point, even if that's just to make sure the current process
>   continues.  There are open policy questions around the current process
>   that need to be addresses as well, including target release cycle
>   timeline, policy and timeline for adding new siupported spells, policy
>   for integrations to stable between releases, etc.

Our current progress here has been phenomimal for the number of people 
participating, but I would like to slow it down to a 4-week release cycle as 
that will give us more time to catch bugs and fix them.

> - Policy and proposal for making sure we do security updates in a timely
>   manner.

As I see it, we have two options, in order of feasability:
  1. Parse security lists and use bug_cli to file appropriate bugs, checking 
if the spell version in any grimoire is affected.
  2. Find a volunteer to monitor these lists and file appropriate bugs. This 
person will *not* be required to do any of the fixing.

The main issue with security updates is getting the information to our 
developers, once that's done we seem to update fairly quickly.

> - Plan for getting our documentation current relative to the grimoire.

I've already started on updating the Grimoire Guru Handbook (GGH) for this, 
but I haven't kept up with this. It is available in the tome/rdp.git 
repository for those interested in helping out. The first order of business 
for our documentation is to have our GGH up-to-date for spell writers, as 
this will help clear up a lot of confusion and will give us One True 
Place(TM) to refer to when we have questions as to what is proper. Whether or 
not I become the Grimoire Component Lead, I would like to work on this 
(provided the current GL doesn't have other plans ;)).

> - Your expected availability, and how you'll make plans to let things move
>   forward in your absence.

I'm available most weekdays all day I am available on IRC and e-mail, and 
sometimes on IM. Weekends I tend to be offline, but can arrange to be online. 
I would setup assistants (most likely the other GL candidates, if they'd 
accept) with the same authority as I when I am absent (either announced or 
MIA).

> - Priorities for other kinds of changes in the Grimoire.  Grimoire
>   organization, support for sorcery proposals like moving init functions
>   into the grimoire and the modified spell inheritance plan, automated
>   updates for spells, etc.

I plan on moving for more code reuse, where possible, for spells and 
sections. 
This means that some sections will be heavily modified, while others stay as 
is (such as utils). The use of keywords will replace the need to organize our 
sections by category, which means keywords will need to be implemented before 
reorganizing sections.

I would like several functions moved into the grimoire, if possible:
  1. Mirror lists
  These become outdated quite quickly and, IMO, are a burden on the Sorcery 
Component developers to keep updated. Generating a new Sorcery release for 
this seems a bit heavy, IMO. A better approach would be to separate this out 
much like the pubkeys or archspecs and update as a spell.

  2. init
  Moving the init system into the grimoire would allow our developers an 
easier ability to try new init methods and implementing various schemas.

There are probably other functions the Sorcery Component developers would 
like 
to move into the grimoire and I would be enthusiastic to facilitate them. 
Without Sorcery, we don't have much. ;)

> - Possible bugzilla usage changes; this one is probably minor for this kind
>   of discussion but it's on my mind because as I'm filling in doing
>   triaging or whatever I'm finding it's difficult to follow things that are
>   assigned all over the place, half the time to devs that aren't around
>   anymore.  I think sorcery and cauldron have a better approach to this and
>   would like the grimoire to consider adopting the way they do it.

Simplification. There are many flags we do not necessarily need (e.g. OS) and 
a few "features" that would make finding information easier:
  * Default query links, such as "Stable Integration Requests"
  * Search for similar bug information when a new bug is filed (e.g. 
http://bugs.kde.org/wizard.cgi)
  * A bug creation wizard for new users (e.g. http://bugs.kde.org/wizard.cgi)
  * Pretty graphs/tables to show where the majority of our bugs are so we 
know 
what areas need more attention

-sandalle

PS: Sorry this is late, went to the coast with the fiance for about a week.

-- 
Eric Sandall                     |  Source Mage GNU/Linux Developer
eric AT sandall.us PGP: 0xA8EFDD61  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  http://counter.li.org/  #196285

Attachment: pgpplEuV_NdU3.pgp
Description: PGP signature