[arch-dev-public] freezing core/extra - cleanup testing
Hi everybody, to avoid any chaos in our repos we should think about freezing core and extra. I would propose that we set a date till when we should fix the outstanding bugs in core packages. Afaik there are only some problem with the new initscripts (e.g. hwclock problem) and I am unsure about netcfg. Shouldn't this be merged with initscripts? There seems to be some redundant code atm. After that we should be able to create a first release candidate of the new iso. Then we shhould concentrate on testing those isos. In parallel we have new libtool, gcc and friends in testing. So I would recommend that we only use testing for building packages and keep core/extra untouched. Greetings, Pierre -- archlinux.de
On Wed, Mar 12, 2008 at 7:14 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
Hi everybody,
to avoid any chaos in our repos we should think about freezing core and extra. I would propose that we set a date till when we should fix the outstanding bugs in core packages.
Hrm? We're always going to have bugs. Releasing while fixing bugs is part of developing software. Are you talking about anything specific?
Afaik there are only some problem with the new initscripts (e.g. hwclock problem) and I am unsure about netcfg. Shouldn't this be merged with initscripts? There seems to be some redundant code atm.
Initscripts also needs a bump to match the new ISO version, as we've done in the past. Just recently, tpowa said "no rush we can get to it on Wed or Thurs", so.... there's no rush right now. Um, netcfg was actually split from initscripts. That was a bit of the point. What code is redundant?
After that we should be able to create a first release candidate of the new iso. Then we shhould concentrate on testing those isos.
Tpowa already released his ISO release plan. I always assumed tpowa was the local authority on releasing ISOs, and him and I talk about these things a lot. I assumed it's silly stuff that no one else needs to know much about, but if you'd like, I can inform you of what we talk about over jabber if you'd like.
In parallel we have new libtool, gcc and friends in testing. So I would recommend that we only use testing for building packages and keep core/extra untouched.
In recent memory, we have waited until tpowa was ready to release a new ISO. Then we would freeze, not core and extra, but testing. We do not put any more packages in testing, more everything OUT of testing, and then build the new ISOs. Tpowa, is this correct? Additionally, extra is wholely unrelated to the ISO releases, so there's no real reason to worry about it.
In general I'm not understanding your email. Let me ask for clarification. On Wed, Mar 12, 2008 at 01:14:49PM +0100, Pierre Schmitz wrote:
Hi everybody,
to avoid any chaos in our repos we should think about freezing core and extra. I would propose that we set a date till when we should fix the outstanding bugs in core packages.
You want to set a date where we'll stop updating core? You say it's to avoid chaos, what does this mean?
Afaik there are only some problem with the new initscripts (e.g. hwclock problem) and I am unsure about netcfg. Shouldn't this be merged with initscripts? There seems to be some redundant code atm.
Now you're talking about a specific set of package changes that seem unrelated to what you were saying above...
After that we should be able to create a first release candidate of the new iso. Then we shhould concentrate on testing those isos.
Ok, so... merge initscripts, fix outstanding core bugs by a certain date then make isos and test them.
In parallel we have new libtool, gcc and friends in testing. So I would recommend that we only use testing for building packages and keep core/extra untouched.
Wait... and keep testing the way it is? So the new isos should work with the old versions of libtool, gcc, etc? Does this mean we'll have problems when we push libtool, gcc, etc out of testing? Jason
Hey guys keep cool, following packages i would like to see in core: pending signoffs and move to base: pmciautils, just a small udev.rules fix waiting for signoff. cryptsetup -->waiting on response klibc klibc-extras klibc-module-init-tools --> seems to be solid and movable, would you move in Thomas? vi --> seems to be signed off, could Eric or Tobias this move in or should i move it? klibc-udev? the one from testing works fine, we can use this 116-3 instead of 118 which is not buildable here. --> move in klibc-udev-116-3, would you move in Thomas? initscripts? bump to 2008.03 with the last changes from git aaron and roman will add the final changes and then release a new version. mkinitcpio? do we need a new version to get init= syntax back? if yes we could fix this bug also: http://bugs.archlinux.org/task/9433 --> Aaron said doesn't seem to be an issue problem because of missing /dev/mem? http://bugs.archlinux.org/task/9813 Thomas is this a showstopper? pending signoffs and move to support: rp-pppoe --> waiting for response tiacx --> will go to core now tiacx-firmware --> will go to core now wpasupplicant? Thomas movable? fuse? Thomas is there an issue atm? movable? kbd? Roman wanted to add some changes and additions to it, this is not critical we could live with the old version too. Roman just tell me, if we should wait for your work or not. madwifi/madwifi-utils? I don't have the hardware and cannot test it at all. I am so undecided, Andy has issues with both the one in core and the one from testing. Varun reported this bug on his macbook: http://bugs.archlinux.org/task/9802 Others have no issues and gave signoff on general ml. We could move in the so called stable version or leave it with the snapshot we already have in core.(I hate buggy modules:( ) delayed package moves due to rebuilds and issues: gcc build-toolchain libtool perl any other comments? greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am Wed, 12 Mar 2008 20:10:22 +0100 schrieb Tobias Powalowski <t.powa@gmx.de>:
delayed package moves due to rebuilds and issues: gcc build-toolchain libtool perl
any other comments?
greetings tpowa
I'm fine with that. But I won't keep building packages for core/extra + testing for 2 architectures. Sorry, this is not possible for OpenOffice and other tricky packages like gnash/swfdec. I will only build against testing from now on. i686 toolchain issues should be fixed quickly. Jan, how's the state? -Andy
On Wed, Mar 12, 2008 at 2:10 PM, Tobias Powalowski <t.powa@gmx.de> wrote:
mkinitcpio? do we need a new version to get init= syntax back? if yes we could fix this bug also: http://bugs.archlinux.org/task/9433 --> Aaron said doesn't seem to be an issue problem because of missing /dev/mem? http://bugs.archlinux.org/task/9813 Thomas is this a showstopper?
As I said, the init= syntax is *NOT* a bug in mkinitcpio. It is an upstream klibc issue. It will require changes to the klibc code. It is not super critical right now, but I will complete the patch in the near future. Please do not worry about this issue, I will deal with it. FS#9433 is a silly issue, and not a big deal FS#9813 I don't understand. Everything seems to work fine, so I'm not sure why this is needed. Obviously not a showstopper though.
2008/3/12, Tobias Powalowski <t.powa@gmx.de>:
kbd? Roman wanted to add some changes and additions to it, this is not critical we could live with the old version too. Roman just tell me, if we should wait for your work or not.
Since the process of building the latest version from klibc is still not completely finished, and building statically against glibc causes a bad bug with some keymaps - I will try to rebuilt the package from old sources (they should work) but with my latest modifications to the keymap hook, and with the latest keymaps (that fix a couple of bugs). If for some reason that will still be buggy - we can just stay with the old version until those isssues get solved. I should get internet connection back at home tonight. If you need to contact me during a day - the only way now is by email (I'm not at home from 06:00 to 23:00 now, except weekend). 2008/3/12, Aaron Griffin <aaronmgriffin@gmail.com>:
FS#9813 I don't understand. Everything seems to work fine, so I'm not sure why this is needed. Obviously not a showstopper though.
This is needed to fix some issues with v86d and seems not not hurt anyway. -- Roman Kyrylych (Роман Кирилич)
On Thu, Mar 13, 2008 at 2:49 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2008/3/12, Aaron Griffin <aaronmgriffin@gmail.com>:
FS#9813 I don't understand. Everything seems to work fine, so I'm not sure why this is needed. Obviously not a showstopper though.
This is needed to fix some issues with v86d and seems not not hurt anyway.
If that's the case, /dev/mem can be created by the v86d hook.
participants (6)
-
Aaron Griffin
-
Andreas Radke
-
Jason Chu
-
Pierre Schmitz
-
Roman Kyrylych
-
Tobias Powalowski