Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] We don't wanna cast the broken things, do we?

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Vlad Glagolev <stealth AT sourcemage.org>
  • To: SM-Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: [SM-Discuss] We don't wanna cast the broken things, do we?
  • Date: Mon, 8 Sep 2008 02:27:48 +0400

/me freezes test grimoire on his lappy for a few secs, lol.

OK, so it's time to solve this old problem.. With the current Robin's
commits, sorry, I can't
close my eyes on this.

Though it was always a problem: forcing devel branches of the spells, where
the stable versions
of them were pretty OK. Let's see: yes, there are few exceptions like
libmikmod (3.2.0-beta2),
aalib (1.4rc5), libtheora (1.0beta3: yes, still beta) where "beta", "alpha",
"rc", etc. -labels
are used. But that works only for the spells which -stable versions are out
of date or even
dead.

Forcing the devel branches of software is a bad idea, really. If the original
developer thinks
that his software is in alpha stage -- he marks it as alpha, rc for rc, and
so on. Sorry, we
don't update linux kernel to 2.5, or python to 2.6/3.0 alpha/beta, or php.
But! In php spell
we have that sweet DEVEL word in DETAILS. If a user wants to try out the
devel version of it --
he chooses this branch and enjoys it. It's like it was done for many spells:
wesnoth, dhcpcd,
alsa-* stuff, wine, and so on.

No, I'm not against Robin and his work, but I think it's incorrect.. uh..
let's say.. a bit.

Look at the kdelibs4's DETAILS (/me pets treeve, or who created such
versioning system?) for
example. Stable, unstable, svn. PERFECT.

Prolly Treeve's not so lazy:
--
[01:47'32] CuZnDragon> I don't like maintaining the DEVEL versions.
--
j/k :)

I believe everyone knows about gnome's versioning policy: odd (e.g. 2.21) are
devel, even (e.g.
2.22) are stable versions. Yes, sometimes it doesn't work for some gnome
apps/libs (look at the
spell's history/offsite notes). But at least that works for glib2, gtk+2,
gconf2 and atk :)

Oh, look. GTK+2 is a good example. Some of such updates from 2.x to 2.(x+1)
cause API changes.
Please understand me and my words correctly :). I just don't wanna have some
things broken on
`sorcery -g'. The problem comes if we force devel versions of software just
before tagging
grimoire release. Sometimes it's not so good: no update from rc to stable
before tagging the
release-of-the-month (grimoire) => epic fail. That's a bad practice.

Everyone knows that several of us use test grimoire in production to get the
recent software
versions and to be up-to-date.. For some needs in new functionality of the
software or security
reasons. Yes, sometimes we can't wait a month or more.

So test grimoire isn't a playground. And we shouldn't force the devel
branches into it. That's
why do we have "devel?", "scm?", "svn?", "git?", "beta?", "old?" questions
for our spells.
If a user wants to play with the devel versions -- he answers to such
questions by "y" and
enjoys it.

We can create -devel branch of grimoire in the other hand.. but hey..
inventing the bicycle..
is.. ough.. :)

API changes. We have one current problem: libtool, yesterday 2.2.4 out, but
2.* out many weeks
ago. But! We still can't update it from 1.*, cause of.. yes.. AGAIN.. API
changes. Lots of
spells will be b0rked after that update. So we need to update it carefully
and check the every
spell (!). For me gtkam, libgphoto2 and hal are affected. And we're still
staying at 1.*. So
it should be smooth update, not killing the people's work and nerves :)

For now I'll just revert the commits for atk and gconf2.

Hold me, thrill me, kiss me, kill me if you agree/disagree; this is an open
discussion, and I
really wanna help to solve this problem/solve this problem with your help
globally, here, in
SMGL :).

Thanks.

--
Dont wait to die to find paradise...
--
Cheerz,
Vlad "Enqlave" Glagolev

Attachment: pgpj2xTXETqbt.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page