Skip to Content.
Sympa Menu

sm-grimoire - Re: [SM-Grimoire]Unfiled spells

sm-grimoire AT lists.ibiblio.org

Subject: Discussion of Spells and Grimoire items

List archive

Chronological Thread  
  • From: "Eric Sandall" <eric AT sandall.us>
  • To: <sm-grimoire AT lists.ibiblio.org>
  • Subject: Re: [SM-Grimoire]Unfiled spells
  • Date: Fri, 6 Sep 2002 11:43:11 -0700 (PDT)

Ryan Abrams said:
> I have been thinking about this as well. Since I spent most of yesterday
> on an epic crawl through 100+ open bugs it has been on my mind. See.. i
> found several bugs from July with spells attached that hadnt even been
> touched.. and that ain't good.
>
> Here is what I was thinking:
>
> When laying out the grimoire team in the constitution, define sections
> as "subteams" - with the guru being the team leader.. so there would be
> a KDE team, a GNOME team, etc. Most of these teams would be 1 person..
> some larger sections could have more developers in them working with the
> leader.

This sounds like a good idea. We already have something of this for the
games and disk sections.

> Then the MAIN grimoire team would have a leader, and some developers.
> Those grimoire team developers would consist of 4-5 people who are the
> most dedicated / have the most time and ability. They would be required
> to work with the grimoire team lead to keep up to date on what is
> happening in ALL sections. In exchange for that commitment in time, they
> would also have the ability to add and update spells within
> subteams/sections. Obviously common courtesy would be to check with the
> section teams first, but "grimoire team" developers would essentially be
> grimoire-wide gurus.

This is similar enough to what I was saying for me to say that this being
said is a good saying. :) This sounds like a good solution.

> The "grimoire" team would also have a security auditor or two, who would
> also have the power to modify spells in whatever section. But i think we
> will limit them to the following: "take over a spell when it is patched
> for a security hole. maintain it. as soon as the fix makes it into the
> standard tarball, remove the patch(es), update the spell to the fixed
> version, and hand control back to the guru"

We've needed a security auditor for a while, though so far the GGs have
been keeping up fairly well with this, it would be nice to have someone
(or even better, a group) dedicated just to security.

> Obviously Section Team Gurus could be Security Auditors could be
> Grimoire Team Gurus. But as we grow, this would help distribute the
> weight.
>
> If this system makes sense to everyone, there is no reason to wait for
> me to write it up all fancy in our constitution.. go ahead and set it
> up. But I leave that to Eric Schabell to determine.

Shall we have this setup by Monday, Eric? ;)

> Oh.. and as far as spell count/growth.. i actually think we are doing
> pretty good on getting new spells in when things are released (the
> fontconfig spell that came through today was pretty timely, and dont get
> me started on the 5 minute turnaround on jfs tools. ;P). I dont think we
> need to actively go find stuff to make spells for just to boost our
> count. That will happen over time. I would focus on new releases of cool
> stuff, and on quick turn around for spell requests (spell requests being
> an area that could use some work)

I don't mean that we need to go looking for extra spells, what I was
mostly talking about is that many _submitted_ spells don't make it in
(sorry if I confused anyone on that). As for JFS, well, I try and keep on
top of things. :)

> In any case.. it's quality, not quantity.

I wholeheartily agree. So, shall we open up the grimoire this weekend (at
least) so that myself, and others, can go on another bug-fixing spree? :)

> -Ryan

<snip>

-One of Four
a.k.a. sandalle

--
Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us | http://www.sourcemage.org
http://www.sandall.us/~sandalle | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org #196285 | http://www.shock.wsu.edu/






Archive powered by MHonArc 2.6.24.

Top of Page