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: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Let's make Source Mage not suck!
  • Date: Wed, 3 Jan 2007 10:05:47 -0800

On Wed, Jan 03, 2007 at 12:53:01PM +0100, Thomas Orgis wrote:
> Am Tue, 02 Jan 2007 18:41:22 -0800
> schrieb Eric Sandall <eric AT sandall.us>:
>
> > All current integration requests for stable-rc and stable are taken
> > care of (other than 3 tricky ones for stable). The main problem now is
> > getting bugs fixed and the integration requests filed. I've done my
> > best to stay on top of approving/commenting on integration requests.
> >
> > git integrations are fairly easy and I even enjoy doing them (most of
> > the time ;)).

Please wrap your text to 80 characters. Thanks.

>
> That is an area where I feel kinda blind... being always tight on time, I
> tend to fix stuff so that my box compiles stuff and I have working
> software and am already fighting to get these properly into git -> test
> grimoire.
> How preemtive are you on looking for stuff to integrate?
> Is it only bugzilla requests (that would mean that only a tiny part of my
> work goes the way to stable... wouldn't it be for stable-rc being freshly
> branched off test some time ago)?
> Is a good part of integration also done by devs who fix stuff and integrate
> it themselves?

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.

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
(as defined by ledger) which was a requirement for a stable release.
Instead theres been basically unending disorganized anarchy of bug-fixing,
bug integration requests and version bumps. Integrations requests are
supposed to be the *exception*, not the rule. Given the number of them,
thats hardly the case.

The counter-argument goes as follows "well this fix is trivial, and we
should put it in stable because it doesnt break anything, and stable is
unstable, and this would make stable more stable". Why is that argument
wrong? Because it assumes that there wont be another stable release
soon. Why wont there be another stable release soon? Because we keep
changing stable! The narrow minded counter-argument stands opposed to
the core idea of the stable release process, which is that we release
it often, and we dont change it drastically in between. A short release
cycle will have fewer new bugs introduced and therefore require *less*
work. We dont have to make *all* the spells work, just the core spells.

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
(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. Then some of us have to defend
the stable release process we completely and utterly failed to follow,
and at the same time form a logical argument against some other new plan
that would supposedly solve all our problems.

Bottom line. If you want a stable grimoire. Fix the bugs.
If you want a new stable release, Fix the bugs in the core spells. Help
with the release process. Run the stable grimoire, if theres a problem
in a spell you use, fix it. Changing around our process in arbitrary
whimsical ways is not going to fix anything.

>
> For me it is already straining my time resources (and nerves) to make
> commits with valid comments and also edit HISTORY file manually, which
> gives me a redundancy feel.
So automate it.

>Then having to open a new bug for every small fix and requesting integration
>(open webbrowser, logging into bugzilla)... plus waiting for that
>integration to happen for the boxen that actually use stable grimoire (none
>for me:-( ) - that looks like a long way around a small problem (supposed
>the fix was about changing one line in BUILD or so).
If the fix is trivial, then you probably dont need to worry about it
getting integrated. The whole process of filing a bug and requesting an
integration is for important bugs in important spells.

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

>
> I guess it could be shorter if devs generally integrated stuff themselves
> (do they? I am really not aware of the real situation), but I know that
> that wouldn't be fun for me ... I guess I'll never be friend with git --
> Even cogito plays tricks on me:-(
No, having all devs integrate stuff themselves is a Bad Thing
(tm). Everyone makes mistakes, forcing fixes through a review process
helps ensure quality. Please review the mailing lists if this answer is
insufficient, this topic has been talked about extensively.

>
> Well, fun or not, having at least two grimoires and careful integrations
> happening between them is a minimum of stability to ask for IMHO.
> But what about the number of these grimoires, actually? I'd like to raise
> again the request to consider dropping the stable-rc grimoire.
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. Its supposed to be a temporary staging and
testing area for the next stable. Its no use looking at things frozen
in time. The process can work, but people wont do the work necessary
to make it work. A new process wont fix that, we've tried several "new
processes" and none of them change the fundamental fact that if people
dont fix bugs, things dont get more stable.

Fix the bugs, and the problem goes away.

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

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

>It's a main issue unless we settle for enhancing our mirrors and ensure
>having always every source for stable grimoire at hand and also modify the
>summon stage to fall back to our mirrors also on checksum failure -- or add
>an option to use the smgl server as safe source to begin with.
> But part of our philosophy is that we don't actually distribute the stuff;
> that we provide scripts for users to get stuff from upstream. For that we
> have to closely track upstream and have a high pressure to stay up to date.
Which can be automated.
>
> Having one stable grimoire that gets safe version upgrades and bug fixes
> integrated asap and one test grimoire for experiments and bigger upgrades
> like getting glibc-2.4 / gcc-4.1 to work looks like the obvious solution to
> me.
Thats what stable is supposed to be. Those are the only fixes that are
*supposed* to go directly into stable.

>
> And if someone wants a really tested, stable software environment that he
> trusts on, he can make a private grimoire (of limited number of interesting
> spells) with his set of preferred spell versions and download all needed
> sources and have them handy for any installation on a later day where
> upstream may have changed.
> This someone even could take his prepared ultra-stable-server-core-system
> and make an ISO of sorcery+spells+sources ...
Someone, like you? :-)

>
> Well, to conclude, I really would like to see a future where we can
> actually tell a new user to start off a recent stable ISO / grimoire and
> have fun with that. But many new ppl. seem to be interested in x86-64, were
> we don't have _any_ standard install ISO (only the one with the chroot
> tarball).
> We have to get something done...
Like fixing bugs?

Sorry if this is a harsh reality. The bottom line is that changing our
process around or adding layers of abstraction doesnt fix the underlying
fact that if we want a stable grimoire, we have to work on things that
directly effect the stability of it. The process is just a process,
proesses by themseelves dont fix bugs, people fix bugs. If you feel your
wasting your time with busy work, automate it.

-Andrew

--
_________________________________________________________________________
| Andrew D. Stitt | acedit at armory.com | astitt at sourcemage.org |
| irc: afrayedknot | Sorcery Team Lead | ftp://t.armory.com/ |
| 1024D/D39B096C | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C |
-------------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page