[arch-dev-public] thoughts about next release
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. :-) -- Roman Kyrylych (Роман Кирилич)
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 <cool-snapshotname>? 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. thanks guys greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
2007/5/7, Tobias Powalowski <t.powa@gmx.de>: > 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 <cool-snapshotname>? > 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 (Роман Кирилич)
Roman Kyrylych schrieb:
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.
agreed
- 0.8 will die, what was the consensus: 05-2007 <cool-snapshotname>? rc.sysinit and arch-release should contain this consensus then.
2007-05 or 2007.05 is fine, but not 05.2007 (sortability). I don't like 200705 though.
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. I like the 'pacmania' name, but I would prefer "Duke", to remember the joke on April 1st.
On 5/11/07, Thomas Bächler <thomas@archlinux.org> 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.
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) ;-) -- Roman Kyrylych (Роман Кирилич)
On 5/11/07, Roman Kyrylych <roman.kyrylych@gmail.com> 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"
On Fri, 2007-05-11 at 21:33 +0300, 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) ;-)
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. Dale
2007/5/11, Aaron Griffin <aaronmgriffin@gmail.com>:
On 5/11/07, Roman Kyrylych <roman.kyrylych@gmail.com> 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 <dale@archlinux.org>:
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 5/11/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/5/11, Dale Blount <dale@archlinux.org>:
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?
On Fri, 2007-05-11 at 14:26 -0500, Aaron Griffin wrote:
On 5/11/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/5/11, Dale Blount <dale@archlinux.org>:
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 Fri, May 11, 2007 at 09:56:10PM +0300, Roman Kyrylych wrote:
2007/5/11, Aaron Griffin <aaronmgriffin@gmail.com>:
On 5/11/07, Roman Kyrylych <roman.kyrylych@gmail.com> 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 <dale@archlinux.org>:
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 think I like the idea of displaying the last time they updated in /etc/issue. No one is going to get a warm fuzzy feeling because they updated 2007-05-13 12:17:50. It's just random noise on the login screen. Having a codename show up is much more interesting though. We are still having releases, the difference is that the releases are driven by kernel versions. If we display the code name, people will at least know when new cds are out. Jason
On 5/7/07, Tobias Powalowski <t.powa@gmx.de> 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
participants (6)
-
Aaron Griffin
-
Dale Blount
-
Jason Chu
-
Roman Kyrylych
-
Thomas Bächler
-
Tobias Powalowski