Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Grimoire Lead Vote 2007

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Eric Sandall <eric AT sandall.us>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Grimoire Lead Vote 2007
  • Date: Wed, 14 Mar 2007 08:58:42 -0800

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




Archive powered by MHonArc 2.6.24.

Top of Page