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: Thomas Orgis <thomas-forum AT orgis.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Let's make Source Mage not suck!
  • Date: Thu, 4 Jan 2007 09:36:36 +0100

Am Wed, 3 Jan 2007 10:05:47 -0800
schrieb Andrew <afrayedknot AT thefrayedknot.armory.com>:

> Please wrap your text to 80 characters. Thanks.

Oh, sorry, I again forgot that the web archive software is too dumb to insert
<br> at places and make the text wrappable by the browser...

> Well, the way the process is supposed to work, is there are regular
> release cycles. So when you put "regular" fixes in test you're done. Then
> within a few weeks the fixes are in stable. Only a very limited subset
> of fixes (for security and critical spells) is supposed to move immediatly
> to stable.

Thanks for clearing that up for me.

> Lets be clear. That is NOT whats happening now. What has happened is
> theres been a big backlog of bugs. Why was there a backlog? Not enough
> people got on-board with actually fixing the bugs in the core spells

Hm, for the current situation it is the init.d solely holding new
stable in -rc stage? Actually... hm, not sure if I do the querying right in
bugzilla... do we have a link in wiki or so that points directly to pages
with all pending bugs for stable / stable-rc ?
(like the bugzilla links on
http://wiki.sourcemage.org/Stable_Grimoire_Bug_Handling)
And what about a periodic bug summary to ML? Lazy people (coders) need to be
reminded of things, especially when there is some deadline (like a real
release cycle).

> (as defined by ledger) which was a requirement for a stable release.
> Instead theres been basically unending disorganized anarchy of bug-fixing,

For sure I am guilty in that respect, too. My personal motivation is often
centered around getting a working system and actually getting some work done
(work with the system, not on the system).
That means I use test grimoire, or even git directly on my main box, and fix
stuff there so that I have a working box.
Also the ISO situation is resolved by not using the iso to install... my new
laptop doesn't even have a CD/DVD drive.

Well, I should get my thesis done and grow as a smgl dev after my first year
of being sort of a power user.
Still, I think I am doing good work on smgl based on the fact that I clearly
_should_ have _no_ time _at all_ to work on it 'cause of my "real" duties;-)

> Whats happened in the past, and what continues to happen, is people look
> at the current state of things, assume that things are going according to
> the process, and then conclude the process is broken and unrepairable

There still is some truth in that interpretation. When things are not
working, it is natural to assume that things are wrong in some respect.
I am with smgl for about a year now, being a dev since May/June or so...
I cannot remember having whitnessed a single release cycle.
I have whitnessed new devs coming along - and how should they know how things
are supposed to work?
I mean by _experience_ - what's written is always a bit different from what's
happening (I should know - I lived in the German Democratic Republic;-).
So, let's get this darned stable-0.6 out! Gimme the list of bugs still
outstanding and I promise to resolve at least one of 'em.

> (or people just assume there is no process). Yet, if people simply worked
> together on the plan, things would go much more smoothly. Instead every
> few months a thread like this pops up.

It won't if there would be a stable every month. Hen and egg.
And I guess we really would need a cycle of 4 months maximum. Better every
month, or every 2...
But questioning the process is valid - we have to show that the number of
devs we have can maintain this distro in the way we want.

> Bottom line. If you want a stable grimoire. Fix the bugs.

Let the bugs come to the devs, not the devs to the bugs - push them in our
faces via nagging reminders on the ML (increasing frequency when aproaching
stable release deadline;-).
One note: I fix a stable-rc bug by making a change in test (git) and
requesting integration?

> So automate it.

> Of course, you could also automate filing a bug, its not that
> hard. Prometheus already knows how.

Well, I am new to bugzilla (and not friends with). I am new with git (and not
friends with). Stuff to lean. Time to spend.
Time for actually coding. Time for doing stuff I get paid for...
But sure, automation is the key at some point.

> Please re-consider this question after looking at our release
> process. Stable-rc is a RELEASE CANDIDATE. Meaning, its not supposed to
> sit around for months on end.

Hm, something went wrong;-) Well, the notion of stable-rc being just one of 3
normal grimoires comes from looking at what happens... I see that that
shouldn't be the case.

>
> > We also have the special problem that we rely on external upstream
> > sources (tarballs), that cause any "stable" grimoire to become unstable
> > with time (changing tarballs without version change, deleting old
> > versions form web site).
> This can be automated, most of it already *is* automated. But no one is
> stepping up to finish the task. Its more fun to complain about it on
> the mailing list.

It's not fun. I don't know of what you are talking here... I didn't know some
automation for that is in the works. People are complaining on ML because
they don't know better.
What I know is a ML discussion related to that that I started some time ago,
before being a dev, even.
About summon also checking integrity and trying a fallback mirror when
checksum fails, so that most "outdated" stable spells would succeed.
Resolution was that the whole summon/integrity check stuff has to be reworked
and that if I want to see it I'd have to do it.
Well, perhaps I am able to do it in the near or distant future...

We clearly have a problem with the "fun" in smgl coding. We have a high
pressure of stuff to do and devs are fed up with ppl. coming along and having
ideas because the old ideas are still not realized -- instead of "Hey, that
would be cool! Lemme code it". I am not blaming this on the people. I want to
repeat what I said on IRC: It is amazing what we do, when we relate the work
that is done to the number of ppl doing it (in (non-existent)free time).
But still, we have to reduce the workload that peaks in fruitless repeated ML
complaints.

> > We cannot allow the stable grimoire to grow old like Debian does.
> It wont grow old if we actually fix the bugs and drive the process forward.
Agreed and I would enjoy seeing the process progressing.

> > This someone even could take his prepared ultra-stable-server-core-system
> > and make an ISO of sorcery+spells+sources ...
> Someone, like you? :-)
Bah, do I have extra time? Do I have a CD drive for the ISO? ;-)

> > We have to get something done...
> Like fixing bugs?
Yes, like fixing bugs. And improve (*cough* after we fixed all the bugs...).

> The process is just a process,
> proesses by themseelves dont fix bugs, people fix bugs.

Tell that McKinsey & Co. ! Big companies tend to "optimize" their processes
even by firing big numbers of people. Our processes would benefit from some
more ppl, instead.

> If you feel your
> wasting your time with busy work, automate it.

I totally vote for the "gaze bugs" thing and generally for command-line bug
management... Perhaps I'd even like to work with bugzilla when I don't have
to use the web form for stuff. But that is again dreaming of features.
Having a SMGL Bug report in the ML is something that indeed would help now
IMHO.


Alrighty then,

Thomas.




Archive powered by MHonArc 2.6.24.

Top of Page