sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
- 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: Thu, 4 Jan 2007 13:25:47 -0800
On Thu, Jan 04, 2007 at 11:26:22PM +0400, George Sherwood wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, 4 Jan 2007 10:27:48 -0800
> Andrew <afrayedknot AT thefrayedknot.armory.com> wrote:
>
> >
> > I think that you have a good insight in that people work better when
> > guided. So paraphrasing, maybe a little more micro-management would
> > help? My previous post alluded to this, with everyone picking one
> > spell to shepard through the process.
>
> How about any type of management? :) I see you making snipes here
> about version bumps. So what is the process? Are we not to bump
> spells in test? If so who decides what gets bumped? Here are three
> examples.
>
> I ran bash 3.2.x for a month or so. Saw a few problems, waited for
> them to be fixed upstream and then moved it into test. It was reverted
> because the "process" wasn't followed. So what is the process? What
> is broken with bash 3.2.x and sorcery? How and when does bash 3.2.x get
> into test? I really have no idea. I know the last time for 3.1.x you
> said it was coordinated between you and the grimoire lead. When was the
> grimoire lead last active? Nothing against Arwed, but he is gone for a
> month now and for the last 6 or so hasn't been very active due to real
> life.
>
> Another one, I tested for some time curl 7.16.0. Everything that I
> could see worked for me. I put it into test. A case was found where it
> didn't work for http pulls. I wasn't doing that, truthfully I don't
> think very many were doing them. It was reverted for this one case.
> No bug was written, just a revert and some talk on IRC about who does he
> think he is bumping a spell like that. I asked WTF? Got an answer and
> tracked it down. I went to the git developers and after narrowing it
> down went to the curl developers. It is now fixed in devel versions of
> both those spells. What is the process for going back into test?
>
> I am in the same position now with ncurses 5.6. I have run it against
> everything I use here. When and how does it go to test?
>
> The problems we have go well beyond stable-rc and how many bugs we have
> in bugzilla.
The stable release process is what we're talking about, that *has* been
documented, and I think sandalle even provided a link somewhere else in
this thread. We're talking in generalities here, certain spells have very
specific sub-processes for them, some of which, such as in bash or
ncurses arent as well documented as we'd like. That sucks.
The main process *is* documented, though, and if we can get that to work,
in general, thats a step in the right direction. Im not claiming our
stable release process fixes everything wrong with smgl, or dictates
how we resolve complex issues with core spells (like bash or ncurses).
I claim that if we follow the process, it will work in general, how we
fix implementation level details such as ncurses or bash is a different
issue than how we get the stable release mechanism working at all.
I suggest that if the grimoire devs pick a spell to shepherd through
the process, then more of us would have real insight into the process
and whats actually wrong with it, and how to actually fix it.
>
> I really thought that Jeremy was hitting on much more of the deeper
> issues with SMGL. His is the discussion that needs
> to take place more then one of fixing bugs and getting stable released.
Yes, earlier I tried starting a discussion on what our goal as a project
was. Outside of implementation details of fixing the grimoire or making
more isos. We've unfortunatly gotten side-tracked on fixing the grimoire,
with the assumption that that is a goal the community is interested in.
There hasnt been a consensus on that.
-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 |
-------------------------------------------------------------------------
-
Re: [SM-Discuss] Let's make Source Mage not suck!
, (continued)
- Re: [SM-Discuss] Let's make Source Mage not suck!, Andrew, 01/08/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Jeremy Blosser, 01/08/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Daniel Goller, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Andrew, 01/08/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, S. Barret Dolph, 01/08/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Andrew, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Thomas Orgis, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Andrew, 01/05/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, seth, 01/05/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, George Sherwood, 01/04/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Andrew, 01/04/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Jaka Kranjc, 01/03/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Eric Sandall, 01/03/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Daniel Goller, 01/02/2007
-
Re: [SM-Discuss] Let's make Source Mage not suck!,
Alexander Tsamutali, 01/04/2007
-
Re: [SM-Discuss] Let's make Source Mage not suck!,
David Kowis, 01/04/2007
-
Re: [SM-Discuss] Let's make Source Mage not suck!,
Jeremy Blosser, 01/04/2007
-
Re: [SM-Discuss] Let's make Source Mage not suck!,
Thomas Orgis, 01/04/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Eric Sandall, 01/04/2007
-
Re: [SM-Discuss] Let's make Source Mage not suck!,
Thomas Orgis, 01/04/2007
-
Re: [SM-Discuss] Let's make Source Mage not suck!,
Jeremy Blosser, 01/04/2007
-
Re: [SM-Discuss] Let's make Source Mage not suck!,
David Kowis, 01/04/2007
Archive powered by MHonArc 2.6.24.