Public SourceMage Discussion List

[Arwed von Merkatz <v.merkatz AT gmx.net>]

On Thu, Mar 01, 2007 at 09:47:33AM -0600, Jeremy Blosser wrote:
> 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.

The new release process seems to work better than anything we had
before, so the main target is to continue doing that.
I'm not sure if we already have enough data for a decision about what
time span we want/need between releases. One of the very old timelines
we had for stable mentioned two months per cycle. That's probably a
little too long, something around 4 weeks might be a good target.
Integrations between stable releases should be limited to a) security
updates and b) critical bugs. This of course needs a definition of
"critical bug", which I'd place at "can destroy user data and or
systems", e.g. a bug causing glibc to get lost during the cast.

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

One of the main problems here is getting the info about security
problems/updates to the grimoire developers.
I was thinking of having some word matching running on the bugtraq
mailing list to forward all mails including a spell name to a dedicated
mailing list for us. Not sure how feasable that is, I'm not really
familiar with bugtraq. Overall we really need a method to get info about
those updated to _all_ developers. Once that's the case, we can tick
them off once they're in stable and send the security notice to
sm-security.
I know that this didn't work out too well with sm-spell-submit, but I
think it's a different use case. sm-spell-submit is flooded by too many
mails with too few information in it (e.g. the sourceforge mails contain
absolutely zero useful information), and version updates are just too
frequent for most things to always check sm-spell-submit.

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

I'm not a documentation person myself, so I'm really not sure about this
one. What we really need is people who can write useful documentation to
step up and start it. I'm willing to have my brain picked by them for
anything I know about how spells and the grimoire work, and I'm sure
there are other developers like me.

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

Answered that in my reply to Andraž.

> - 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'm all for moving specific things like the init handling from sorcery
into the grimoire.
The new spell file inheritance will make sharing code between spells
easier, so I'd give high priority to that too, as soon as someone has a
specific use for it in the grimoire.
Fully automated updates for spells are still mostly science-fiction to
me. I think most developers already use some scripts to do their version
updates for them, and updating a spell is more than "update the version
number, hash/sig, test cast, commit". If it was that simple, everyone
could do it ;) Having some automated testing for updates (e.g. using
prometheus) would be nice though.
Basically, anything that makes life for spell writers, sorcery coders,
spell maintainers or users easier should be done, withing reason.

> - 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.

We should make all bugs assigned to sm-grimoire-bugs by default, like it
is for the unmaintained sections. I'm not sure if we actually need a way
to reassign them to someone else, a note like "I'm working on this" in
bugzilla should be enough, and unlike an assignment, such a note has a
date associated with it, so people can poke about it or decide to work
on it themselves after a time of inactivity.

-- 
Arwed v. Merkatz                              Source Mage GNU/Linux developer
                                                    http://www.sourcemage.org