Developer Only Discussion List

[Hamish Greig <hgreig AT bigpond.net.au>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 24 Dec 2003 23:57, Benoit PAPILLAULT wrote:
> - ISO FILENAME:
> ---------------
>
> I think we should follow the convention smgl-0.8.0-i386.iso.bz2,
> smgl-0.8.0-i386.iso.bz2.md5sum and smgl-0.8.0-i386.iso.md5sum.
>
> The file ending with ".iso.bz2" is a bz2 archive of the ".iso" file to
> save some disk space.
>
> The file ending with ".iso.bz2.md5sum" should contain the output of
> md5sum on the .iso.bz2 file.
>
> The file ending with ".iso.md5sum" is the output of md5sum run on the
> original ".iso" file.
>
> The "-0.8.0" part should be the version number. "-pre#" should not be
> used. It must be 0.8.0 and next 0.8.1, 0.8.2 ... and next 0.9.0, 0.9.1
> and so on.
>
> The "-i386" is the architecture. There should be soon a "-ppc" version.

all common sense.
Except that you were the person started using "-pre#", if you need to release 
ISO's for bugtesting before the main 0.X.0 release then they have to be 
marked  "-pre" or "-experimental" or "-devel". Using the plain file 
STABLE_IS_BLA and DEVEL_IS_BLA is a good way around this if you don't wish 
"-pre#" or "bla" added into the filename anymore.

> - ISO LOCATION:
> ---------------
>
> In order for people to download the correct version, annoucement message
>   should contain a full http link to the .iso.bz2 file. "latest" file
> are forbidden.
>
> So, those link must be maintained over time, that's why moving file to
> either "older-i386-versions" or "older-ppc-versions" should NOT occur.

I *strongly* disagree. WE are talking about 130+ MB files, if we did as you 
suggested, within a short periiod of time (sixmonths - a year ) we would have 
hundreds of files in that top dir, most of them quite large in size (130MB+).
Several solutions to this follow, But I am strongly against having everything 
bundled into a single dir, no matter what reason.

1) Only the current ISO should be in the top level dir. Older iso's should be 
in the older-"arch" dir. Announcements should link to the top level dir only, 
stating latest can be found from that folder, but it will change with each 
new release, so explicitly linking to a file name is not supported. A plain 
file stating that could also be used.
2) Another method would be to have each release in a seperate folder. 0.8.0, 
0.9.0 etc and linking to the actual ISO within that folder. That folder need 
never change, the next release will go into it's own folder and can have it's 
"static" link too. The top level dir could have a simple LATEST_IS_bla file 
or even a link into that release's dir. 

Lastly, I am more concerned about deadlines and bugs than ISO names and 
locations. I don't think it matters much what you call something if it is 
always late and the bugs that are filed against it's previous versions are 
not addressed (or even commented on). If we are going to spend time 
discussing minor issues like filenames and locations, we should also (and 
more importantly) be discussing what the ISO/Cauldron team needs to get back 
onto track and meet it's deadlines and what help it needs in dealing with the 
open bugs it has.
I always believed the roadmaps/deadlines were attainable. No-one  has 
publicly 
stated the current release roadmap is unrealistic or unattainable, but one 
ISO release has been cancelled (and others are late). 
Do we need to revisit the Roadmap ? 
Are the ISO and Cauldron teams not working together properly ?
Am I wrong in thinking ISO and Cauldron teams are the left and right hand of 
the same body ?
Are unfinished enhancements slowing down the releases ?
Are less changes in between each release needed, are the team goals 
unrealistic ?
Is the lack of progress on the hardware detection holding up the ISO building 
process ?

What is really needed from the guru's maintaining the grimoires so that ISO's 
are on time and have all the features we as spellwriters/sysadmins/users 
need ?


Hamish
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/7Yin8fSufZR6424RAvkiAJ9EF7Drv0Qr+xMA6sM5j8ShmgywPgCeNmeL
h1ZMIe6J2aZQbHNqBGL0Nyk=
=Accp
-----END PGP SIGNATURE-----