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: Fri, 28 Jan 2005 11:01:34 -0800 (PST)

On Fri, 28 Jan 2005, Benoit PAPILLAULT wrote:
Eric Sandall a ?crit :
//sgl/sorcery/proj/proj2 is ripe for this work if you want and already
has some of your fixes (though they're probably outdated).

OK. I'll use it then. Thanks.

You should have access to it now.

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

Like Karsten almost said, I think that the ISO generation scripts and the installer are quite separate. Since someone will be working on the installer script with some fresh ideas, I was wondering if we could convert the installer script to a spell like any another spell that will be added to the list of spell installed on the ISO. The first advantage being that the development will then follow the grimoire framework, which provides all the necessary tools to install it. David? Karsten? Others?

The installer script is the script with smgl.install et. al.? Why do
the installer scripts need to be "installed"?

[I replaced some proj dir in the following text]

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/proj4 (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/proj4 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

Sounds good. I'll rewrite it to be sure I understand and to be correct.

1) We have a stable branch. This should match the "current" stable ISO available for download.

Correct, the code in //sgl/cauldron/stable will be the same as the
code used to make the latest ISO release (not test releases).

2) We have a devel branch. At some point, it matches the "current" test ISO. When feedback comes, we apply fixes to this branch. We can also integrate code from our "proj" branch.

Yes, and once a test ISO is deemed good enough for a new stable release, this
code is then integrated into //sgl/cauldron/stable.

3) Everyone is working on his/her "proj" branch (branched from devel initially). It will be integrated to devel (not stable).

The only integrates to stable will be from //sgl/cauldron/devel, and
then only after test ISOs have been tested and verified to work.

4) We need a way to get the code for any previous stable or test ISO when we need to (to compare what has changed between releases for instance)(should we use p4 labels ?).

I was thinking of using the Sorcery model:
//sgl/cauldron/devel Code for latest test ISO
//sgl/cauldron/stable Code for latest stable ISO
//sgl/cauldron/release/<ISO version> Code for <ISO version>

So when we integrate devel into //sgl/cauldron/stable, we also pull it
to //sgl/cauldron/release/<ISO version>.

e.g. For our 0.9.4 release we'd do (once devel has the code we want
for the final 0.9.4):
$ p4 integ //sgl/cauldron/devel/... //sgl/cauldron/stable/...
$ p4 integ //sgl/cauldron/devel/... //sgl/cauldron/release/0.9.4/...
$ p4 resolve
$ p4 submit

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.

Good. We'll need to make a bug review later.

Such as:
http://bugs.sourcemage.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Install&component=Installer&component=ISO&component=Unknown&version=0.9.3&version=0.9.4&version=0.9.4-test2&version=0.9.4-test3&version=pre-1.0&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
(I believe this gets them all ;))?

-sandalle

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