2007/5/7, Tobias Powalowski :
> Am Sonntag 29 April 2007 schrieb Roman Kyrylych:
> > Hi!
> >
> > As Tobias said: "kernel 2.6.21 series is now in testing, it will be
> > the kernel series for next release".
> >
> > According to the schedule published by Paul repositories
> > reorganization will be finished not earlier than in the middle of
> > Summer.
> >
> > And in this announcement http://www.archlinux.org/news/308/
> > we said that "When the next kernel 2.6.22 is released, we will push
> > out a new ISO image".
> >
> >
> > So, here's how I see variants for next release:
> >
> > 1) release new ISOs based on 2.6.21, using the current scheme
> > (ftp+base+current) additional possible changes:
> > * provide snapshot of extra (and community?) for download via BitTorrent
> > * FTP reorder as described here:
> > http://www.archlinux.org/mailman/private/arch-dev/2007-March/005087.html
> >
> > 2) wait until 2.6.22 (hopefully it will be released after repositories
> > reorganization) or even a bit longer and release new ISO set:
> > core & ftp as CDs and main(extra) + community snapshots as DVDs.
> >
> > Changes that should be done in any case:
> > * remove release version and codename from /etc/issue
> > * remove /etc/arch-release
> > * call new release as "ISO release" or "snapshot" instead of "Arch release"
> > * make users understand that there's no such thing as "release" in
> > Arch Linux. :-)
> Hi guys,
> my idea of next ISO with .21 kernel and for Linuxtag 2007:
> - pacman3 should be on it, aaron when you move it in?
> - release it like 0.8 with base,current and ftp till SCM and core move has
>  been done in summer.
> - 0.8 will die, what was the consensus: 05-2007 ?
>  rc.sysinit and arch-release should contain this consensus then.
> - ftp server need to be prepared for this then
>  anything else i missed?
>
> cool-snapshot name, any suggestion?
> We have now 1-2 weeks or so until final ISO should be built.

As I said in previous message already - IMO /etc/arch-release and
snapshot name from /etc/issue should be removed.
What's the point of updating those things with Arch's rolling release system

About snapshot scheme:
I suggest 2007-05 - it's better than 05-2007 because of easy sorting
:-P, and doesn't contain redundant info.

Also, IMO it would be nice to have i686 and x86_64 titles as on this
CD cover by PJ:
http://bbs.archlinux.org/viewtopic.php?pid=247503#p247503

Some cool name would be nice too (though not necessary) but IMO
putting the cool name into filename.iso is redundant.

It would be nice to have ftp server cleaned at ISO release time.
Right now current points to 0.8 which was not the case before. I
cannot find 0.8 release snapshot on FTP.

After some thinking I come to conclusion that keeping every last (and
only) release snapshots is useful but only with extra & community
snapshots. Otherwise there's not need in them IMO
Making those snapshots available on DVDs would be nice for users that
don't have enought bandwidth & money for paid traffic and would like
to order full working [1] snapshot of all available binary packages to
setup useable working environment.

[1] probably partially, because some deps may be broken at the time of
snapshotting, but that's minor issue.

-- 
Roman Kyrylych (Роман Кирилич)

On 5/11/07, Thomas Bächler wrote:

2007-05 or 2007.05 is fine, but not 05.2007 (sortability). I don't like 200705 though.

Yeah. I like the dot, if only because number-number in Arch context say to me "pkgver-pkgrel". Maybe that's just me.

I agree with Tobias here, having these names is just fun. And putting them in /etc/issue is fine for me.

Yup, and fun is always a good idea.

I like the 'pacmania' name, but I would prefer "Duke", to remember the joke on April 1st.

Hmmm Duke might be a good idea. I like it.

On 5/11/07, Roman Kyrylych wrote:

...

...

...

As I said in previous message already - IMO /etc/arch-release and snapshot name from /etc/issue should be removed. What's the point of updating those things with Arch's rolling release system I agree with Tobias here, having these names is just fun. And putting them in /etc/issue is fine for me.

Yup, and fun is always a good idea.

I don't mind about a fun. :) But those files do state, that user is running some _release_ which is not true because of Rolling Release System (tm) ;-)

Ah, I get your point now. It does make sense. How about a change from "version X.Y" to "Codename: FOO" i.e. "Codename: Duke"

2007/5/11, Aaron Griffin :

On 5/11/07, Roman Kyrylych wrote:

...

I don't mind about a fun. :) But those files do state, that user is running some _release_ which is not true because of Rolling Release System (tm) ;-)

Ah, I get your point now. It does make sense.

How about a change from "version X.Y" to "Codename: FOO" i.e. "Codename: Duke"

A bit better. It will be fun when user will be surprised by new codename after one of -Syu on the next reboot. :-D 2007/5/11, Dale Blount :

Why don't we keep labeling release CDs as such but have pacman write the date to /etc/arch-release on successful -Su (or -Syu maybe)? It always did bother me that at times you could get a newer release than was actually available for download. This way we'd know exactly last time the system was updated.

Hm... sounds interesting... Looks like a decent idea to Arch. :-) Not so good to other distros with Pacman, that probably won't have Rolling Release System, but that can be solved. -- Roman Kyrylych (Роман Кирилич)

On Fri, 2007-05-11 at 14:26 -0500, Aaron Griffin wrote:

On 5/11/07, Roman Kyrylych wrote:

...

2007/5/11, Dale Blount :

...

Why don't we keep labeling release CDs as such but have pacman write the date to /etc/arch-release on successful -Su (or -Syu maybe)? It always did bother me that at times you could get a newer release than was actually available for download. This way we'd know exactly last time the system was updated.

Hm... sounds interesting... Looks like a decent idea to Arch. :-) Not so good to other distros with Pacman, that probably won't have Rolling Release System, but that can be solved.

I don't know how much I like the idea of modifying that file on every -Syu. A "pull" method sounds cleaner. For instance, pacman can keep track of the last time it did an -Syu (and actually installed something) somehow in /var/lib/pacman (/local/.lastupdate ? that'd match the other DBs)

We could then have some other utility adjust the release file.... cron job? rc.sysinit?

cron.daily works for me. The lag time might confuse some, so maybe cron.daily and rc.sysinit both? Dale

On 5/7/07, Tobias Powalowski wrote:

- pacman3 should be on it, aaron when you move it in? Probably tonight, unless anyone has any objections.

cool-snapshot name, any suggestion?

Hmmm, I always liked the snapshot names... How about '09F9' (hah)... kidding I'm a fan of the arbitrary names cactus can come up with on some of these things.... a few he's had for me: oxcart, barnacles, ummmm