Skip to Content.
Sympa Menu

sm-discuss - Re: [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: Robin Cook <rcook AT wyrms.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] We don't wanna cast the broken things, do we?
  • Date: Sun, 07 Sep 2008 19:18:18 -0500

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

Attachment: signature.asc
Description: This is a digitally signed message part




Archive powered by MHonArc 2.6.24.

Top of Page