Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] ISO generation [back on-topic]

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: "David Kowis" <dkowis AT shlrm.org>
  • To: "Eric Sandall" <eric AT sandall.us>
  • Cc: SM Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] ISO generation [back on-topic]
  • Date: Thu, 27 Jan 2005 07:31:15 -0600 (CST)


--
One login to rule them all, one login to find them. One login to bring
them all, and in the web bind them.

<quote who="Eric Sandall">

>> - As far as the install script is concerned, David has volonteer to work
>> on it with a modular design. I'm quite happy to have a new member in the
>> team to take care of that. I've mainly tried to maintain the script left
>> by hgg, but failed totally on the RAID & LVM part. (evms has been
>> included on 0.9.4-test3 ISO ... ). I even think that it could be a
>> separate spell installed on the ISO as any other spell and that could be
>> used to install chroot as well as real system. Comments?
>
> If both David and Karsten are working on modularizing, perhaps they
> should work on the same scripts? But then we need to decide which
> scripts we're going to use (at the end of the e-mail). ;)
>
I'm working on the smgl.install script. Karsten's script is a modular iso
generation script. I suppose we could collaborate on design schematics,
but for the most part, our entities are seperate.

>> - As far as the 1.0 release is concerned, i think it would be good to
>> have some quality criteria. However, if the criteria is to not have
>> people complaining here and there about stuff not working, we will never
>> have such 1.0 release. Usually, happy people are not showing up but
>> newbies are just posting bugs without taking the time needed to fix them
>> or help fix them. Moreover, I cannot fix a bug than I'm unable to
>> reproduce myself without some help (I requested some help on bug #7642
>> [2], but even the developper that were able to reproduce the problem did
>> not give any information). So far, my criteria was to run twice "sorcery
>> rebuild" on the installed system to ensure that people will not have
>> problem casting spells.
>
> Our criteria is to fix all pre-1.0 bugs on the ISOs as well as the
> other targets listed on our RoadMap[0]
>
>> Comments, decision, volonteerS ... are welcome :-)
>> Benoit PAPILLAULT, ISO guru
>>
>> [1] http://wiki.sourcemage.org/index.php?page=ISO+RoadMap
>> [2] http://bugs.sourcemage.org/show_bug.cgi?id=7642
>
> How about we do this: branch the current (with any fixes yet to be
> applied) scripts into //sgl/cauldron/stable, continue to apply fixes
> to that and use it to produce more test ISOs, applying the fixes to
> devel and branching into stable after producing test ISOs and getting
> feedback. We then use //sgl/cauldron/proj/proj2 to continue work on
> Karsten's scripts and see if we can get those building working ISOs as
> well as integrating //sgl/cauldron/proj/proj3 (David's modularization
> of smgl.install) into //sgl/cauldron/devel once his scripts work.
Actually the installer stuff ended up in proj4 :) I'll write a script to
package up the installer to be unpacked, or copied or something, by the
iso generation scripts so that they can just call that script and the
necessary files will be placed where they should be.

>
> This will lead to the following (IMO):
> 1) We have a stable branch that we know at least mostly works
> 2) We have a devel branch where we can apply fixes for the stable
> branch, test, and then integrate into stable after feedback
> 3) We have a sub-project working on the Next Generation ISO that,
> once it can make working ISOs, can be moved into //sgl/cauldron/stable
> 4) The modularization of the current stable code
> (//sgl/cauldron/proj/proj3 via David) can be worked on and, once
> tested and working, integrated back into the devel code, then tested
> some more (Yet Another Test Release ;)) and eventually moved to stable
>
> This will give us a stable code base to apply fixes and updates to
> while letting us work on modularizing the stable code as well as
> working on a re-write.
>
> I would request the following naming scheme for ISOs:
> http://download.sourcemage.org/testing/ will hold all of our testing
> ISOs (no need for 2 testing directories). The ISOs will be labeled as
> follows:
> * Testing for current scripts (//sgl/cauldron/devel):
> smgl-<version>-<arch>-<nptl|non-nptl>-test<++#>.bz2
> * Testing for Next Generation ISOs (//sgl/cauldron/proj/proj2):
> smgl-<version>-<arch>-<nptl|non-nptl>-ng-test<++#>.bz2
>
> Where the following are defined as:
> <version>: The next version (currently 0.9.4) to be released
> (the NG ISOs will probably keep the 0.9.4 nomicker for a while)
> <arch>: Architecture ISO is built for (x86, PPC, x86_64, etc.)
> <nptl|non-nptl>: Denotes whether this ISO was compiled with an
> NPTL-enabled glibc or not
> <++#>: Incrementing numbers (e.g. the next test will be
> -test3)
>
> I would prefer that we focus on the current scripts to get them into
> stable, a 0.9.4 released with as many pre-1.0 bugs fixed as possible,
> and then we can start maintaining stable/devel, continue work on the
> Next Generation ISOs, and work on modularizing stable/devel.
>
> Thoughts? Am I going overboard?
Yeah that sounds great. I'd like to see something like that done. Your
method sounds as good as any. It gives the ISO generation scripters a
target filename, it gives us a structure and a plan to get development to
move forward. I've no problems with this methodology. I'm not sure how to
determine what's a Next Gen ISO tho. I suppose NextGen would be equivalent
to devel. I like it, but I think it might be a little while until we can
have an ISO that I would consider stable. I suppose the 0.9.3 is good
enough, but it has some hella bugs. I think the stable should be the first
working ISO we get from the generation scripts and the new installer. Then
we can roll onward from there. Of course, I don't run the show, so if
there's a better idea, please slap mine around a bit :)





Archive powered by MHonArc 2.6.24.

Top of Page