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: Eric Sandall <eric AT sandall.us>
  • To: SM Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] ISO generation [back on-topic]
  • Date: Thu, 27 Jan 2005 10:04:43 -0800 (PST)

On Thu, 27 Jan 2005, Benoit PAPILLAULT wrote:
<big snip>
On my side, here are the areas I plan to work on:

- bi-arch port (x86_64 and maybe sparc64 if something can give me an
access to a sparc64 machine). Since sorcery needs some modification, I
could continue the work started on the proj2 branch for instance. As far
as the grimoire is concerned, glibc at least requires some modification,
where those could be done? I'd like to know who is interested in such
architectures as well and which one! If someone wants x86_64, tell us
right now!!!

//sgl/sorcery/proj/proj2 is ripe for this work if you want and already
has some of your fixes (though they're probably outdated).

- since no decision have been taken on the scripts set that will be used
for the next ISO, I'm volonteering to maintain the script we are
currently using to build the ISO. I could do so in a separate branch
(proj3). To ease the job of running those scripts and uploading the
resulting ISO, David Kowis has volonteer to host the script. Is it still
OK David?

We're trying to decide which scripts to use, more on this below.

- at the same time, I will investigate on using INSTALL_ROOT to produce
ISO since it's a good way to reuse what the sorcery team is doing and
avoid to reinvent the wheel. I've already started and it seems promising.

If both you and Karsten are thinking of using INSTALL_ROOT, perhaps we
should wait until we decide on one set of scripts and then modify
those for it?

- I'll be happy if we decide to use BearPerson's scripts. They have been
written from scratch with a new modular design. I should point out
however that both scripts cannot be merged together in a near future, so
deciding which scripts we will be using is a key decision. I'm
requesting here a clear statement from Unet or sandalle on this topic,
to avoid wasting my time on maintaining the current set of scripts.
Deadline: 2005-02-01.

I'd like the decision to be sometime this week, if possible.

- 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). ;)

- 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.

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?

-sandalle

[0] http://wiki.sourcemage.org/index.php?page=SourceMageRoadMap

--
Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/




Archive powered by MHonArc 2.6.24.

Top of Page