Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Let's make Source Mage not suck!

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: George Sherwood <pilot AT beernabeer.com>
  • To: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Let's make Source Mage not suck!
  • Date: Thu, 4 Jan 2007 21:32:36 +0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 4 Jan 2007 08:54:56 -0800
Andrew <afrayedknot AT thefrayedknot.armory.com> wrote:

>
> I dont see the advantage in dropping stable-rc entirely. I do see a
> point in treating stable-rc as a -rc. That is something we have not
> yet tried, but is core to the release process. Stable-rc absolutely
> can not sit around and become stale. its no longer an -rc at that
> point, it becomes what "test" was, when we had devel, test, and
> stable.

It becomes and is much worse then test ever was. It gets very selected
updates and becomes stale as the release drags out and out which is
something that test never did.

>
> How do we treat stable-rc as a -rc? Following our release process we
> branch from test, figure out what spells need to work, and focus our
> efforts on fixing bugs related to those spells. The breakdown occured
> because we picked too many spells, and usually had only one person
> fixing them.
>
> Howerver the process is designed to work with any number of spells,
> even just one. Whatever our resources can accomplish. Over time the
> number of spells is supposed to grow, but the process helps make that
> happen through the policy of no regressions (this is also fundamental
> to the process). The work remains the same between release cycles but
> the number of spells increases, and thus so does the stability of the
> grimoire as a whole. Or, if resources diminish, to a point, the
> over-all stability remains constant. Beyond that point the number of
> spells must be scaled back again. But the system can handle those
> situations.
>
> The release cycles we've tried, the only person helping fix spells was
> usually seth. Nobody else. That made it difficult to have the bugs
> fixed in all the spells we wanted. Also, I cant speak for seth, but I
> imagine its frustrating trying to fix tons of bugs in the grimoire
> with no one helping and most people version bumping spells left and
> right.

I have to disagree here. I have fixed close to every one of the bugs in
my section and many bugs in other sections during the release process.
I also know other section maintainers that were working diligently on
their bugs also. The frustrating part of our release process was getting
them into stable-rc after fixing the bugs. The decision was made not to
integrate some because they were not important enough and after fixing
many bugs like this, I just quit. Bugzilla is such a mess now, you
can't tell what has been fixed, what has been integrated and what
hasn't been touched. IMHO, pretty much everything there needs to just
be closed out and we start clean. It is really ugly.

The process broke down by running prometheus on every spell in the
grimoire without us ever having nearly enough manpower to fix those
bugs. It was this idea that we are making the distribution better by
finding all the corner cases of every spell instead of concentrating on
fixing the bugs that were being reported by actual users using the
distribution. Automated testing is great when you have the manpower to
deal with the output of the testing. We didn't have then, we probably
have less now and I don't see that changing anytime soon.

>
> So, if we try the process again with a few more volunteers, and a more
> realistic list of spells, we can get a new stable out in short order.
>
> I suggest for the next round, basesystem spells only. We can make
> sure all those spells work pretty easily. You can build all of them
> in a few hours. I modified all of them for install-root a year or so
> ago in an evening. I think its do-able. Of course if init.d isnt
> working, we need to either fix it, or back it out.
>
> The process will work, but we have to give it a chance, theres only
> one way to do that, which is to do the work.

No doubt about that, but will it get done? I have pretty much been
around here as long as any one and believe the list of bugs I have
fixed compares with almost any other devel and truthfully I see great
motion at times like this, but in the end run very little results.

George Sherwood
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFnTo3kVJnfkgKg60RAkvKAJ90/1U/3CY2bEU81SY+NV4eHIt9IwCfd4oj
cKiKJ7gDwD0h9PyqHAIg/9A=
=kpCY
-----END PGP SIGNATURE-----



Archive powered by MHonArc 2.6.24.

Top of Page