Public SourceMage Discussion List

[Arjan Bouter <abouter AT sourcemage.org>]

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

You're missing the point here (or I am ;) ). It's ok to break something in 
test,
as that's what it's for. As long as you have tested it yourself and it works 
for
you.

What is troubling me as well is that more and more spells get updated to -rc
- -alpha and other such versions. That's just asking for trouble IMHO.

Unstable versions of spells should be a choice and not forced on the user
unless there's a need for it, like the stable version being so far out of date
that it won't work anymore.

IMHO if the maintainer of the spell doesn't feel like keeping up with
development releases for a multi-version spell, than we should just stick with
stable versions.

Arjan


On Sun, 07 Sep 2008 19:18:18 -0500
Robin Cook <rcook AT wyrms.net> wrote:

> Unless it was changed and I missed seeing it, test was never guaranteed
> to work.  So if you are using it on a production system, then you need
> to take responsibility and only allow updates that won't break your
> system and not just expect sorcery -g will work with the test grimoire.
> If you need fixes, etc., before they get to the stable grimoire then
> there are tools for doing that rather than as you say, "being lazy".
> 
> The whole idea of test was for testing to find out what is not working
> together properly and try to fix it, that includes downgrading it if
> that is the only solution, as there is no way one person can test every
> combination of programs together. 
> 
> I am following the procedure that has been used for the gnome section
> since 1.x to put the last beta/rc versions in test to find all the
> issues that I don't find in my basic testing.  In the past the beta/rc
> versions weren't pulled into stable-rc or were reverted right after the
> branch.  Not sure if there is an automated way with our git repository
> to exclude them automatically.
> 
> That said I have no problem changing that procedure. But if that happens
> then I will have to demand that everyone stay out the the gnome section
> during the beta/rc/release time. So that I then don't have to screw
> around trying to fix a bunch of merge conflicts when I pull in the
> spells after the official release.
> 
> Robin Cook
> CuZnDragon
> 
> On Mon, 2008-09-08 at 02:27 +0400, Vlad Glagolev wrote:
> > /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.
> > 
> > _______________________________________________
> > SM-Discuss mailing list
> > SM-Discuss AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/sm-discuss



+=======
Source Mage GNU/Linux developer,
http://www.sourcemage.org
Registered as user #310617 with the Linux Counter,
http://counter.li.org.
GnuPG Key 79D4B14E = 94AD 3FD1 E259 67ED 632E  2B06 CFBE 1154 79D4 B14E
+===
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkjFJdgACgkQz74RVHnUsU6S+ACeNHJHjNHkfsBkVACjI/m/wI7C
fw8AoI4thMsOcTVdGiE3n7KlbkSRH4Yp
=ksZu
-----END PGP SIGNATURE-----