[arch-dev-public] putting "beta" software in [testing]
Hi, coreutils-8.0 has been released but flagged beta because of some fairly large changes in rm which now uses gnulib's hierarchy traversal (= faster) and many changes to gnulib in the area of filesystem primitives. I found the snapshot before this fully usable, and will do a "make check/test" to ensure everything is working as it should. I would like to put it in [testing] _without_ the option of it every moving to [core]. I know we do this for some software, but never anything so "core" to the system that I know of. So... can I use [testing] for testing in this case? Allan
On Tue, Oct 6, 2009 at 7:41 PM, Allan McRae <allan@archlinux.org> wrote:
Hi,
coreutils-8.0 has been released but flagged beta because of some fairly large changes in rm which now uses gnulib's hierarchy traversal (= faster) and many changes to gnulib in the area of filesystem primitives. I found the snapshot before this fully usable, and will do a "make check/test" to ensure everything is working as it should.
I would like to put it in [testing] _without_ the option of it every moving to [core]. I know we do this for some software, but never anything so "core" to the system that I know of. So... can I use [testing] for testing in this case?
So in some sense, this has a precedent. We always put the 2.6.xx".0" kernel into [testing] with little intention of it going to [core], waiting instead for at least one stable release. I'd be fine with this as long as there is at least a version in mind that would be considered stable and able to move to [core], and it isn't going to affect the version in [core] as far as it lagging behind any pre-8.0 maint/bugfix release. -Dan
Afair in the past we left out those coreutils "beta" cycles. But I'm also fine with putting it into testing until 8.1 or 8.2 will be released and will get stable state. At least someone has to do real life testing, why not Arch testing repo users... -Andy
On Tue, Oct 6, 2009 at 7:41 PM, Allan McRae <allan@archlinux.org> wrote:
Hi,
coreutils-8.0 has been released but flagged beta because of some fairly large changes in rm which now uses gnulib's hierarchy traversal (= faster) and many changes to gnulib in the area of filesystem primitives. I found the snapshot before this fully usable, and will do a "make check/test" to ensure everything is working as it should.
I would like to put it in [testing] _without_ the option of it every moving to [core]. I know we do this for some software, but never anything so "core" to the system that I know of. So... can I use [testing] for testing in this case?
Seems ok, but this actually might fit the "unstable" repo of yore, as well :)
Allan McRae wrote:
Hi,
coreutils-8.0 has been released but flagged beta because of some fairly large changes in rm which now uses gnulib's hierarchy traversal (= faster) and many changes to gnulib in the area of filesystem primitives. I found the snapshot before this fully usable, and will do a "make check/test" to ensure everything is working as it should.
I would like to put it in [testing] _without_ the option of it every moving to [core]. I know we do this for some software, but never anything so "core" to the system that I know of. So... can I use [testing] for testing in this case?
Allan
Since the general consensus is that "testing" is proving ground for packages intended to be moved to core/extra, I don't think putting beta software there is a good idea. Maybe we can create a new repository, called "staging", that replaces the current "testing" repository and use the "testing" repository for really experimental stuff like beta software. Glenn
On Wed, Oct 7, 2009 at 4:54 PM, RedShift <redshift@pandora.be> wrote:
Allan McRae wrote:
Hi,
coreutils-8.0 has been released but flagged beta because of some fairly large changes in rm which now uses gnulib's hierarchy traversal (= faster) and many changes to gnulib in the area of filesystem primitives. I found the snapshot before this fully usable, and will do a "make check/test" to ensure everything is working as it should.
I would like to put it in [testing] _without_ the option of it every moving to [core]. I know we do this for some software, but never anything so "core" to the system that I know of. So... can I use [testing] for testing in this case?
Allan
Since the general consensus is that "testing" is proving ground for packages intended to be moved to core/extra, I don't think putting beta software there is a good idea. Maybe we can create a new repository, called "staging", that replaces the current "testing" repository and use the "testing" repository for really experimental stuff like beta software.
So we can have another unused/underused repo like [unstable]? No thanks. -Dan
On Wed, Oct 7, 2009 at 4:54 PM, RedShift <redshift@pandora.be> wrote:
Allan McRae wrote:
Hi,
coreutils-8.0 has been released but flagged beta because of some fairly large changes in rm which now uses gnulib's hierarchy traversal (= faster) and many changes to gnulib in the area of filesystem primitives. I found the snapshot before this fully usable, and will do a "make check/test" to ensure everything is working as it should.
I would like to put it in [testing] _without_ the option of it every moving to [core]. I know we do this for some software, but never anything so "core" to the system that I know of. So... can I use [testing] for testing in this case?
Allan
Since the general consensus is that "testing" is proving ground for packages intended to be moved to core/extra, I don't think putting beta software there is a good idea. Maybe we can create a new repository, called "staging", that replaces the current "testing" repository and use the "testing" repository for really experimental stuff like beta software.
Two points here. a) The software WILL make it to core/extra, just at a later version b) We often have versions in testing that get bumped without ever hitting core/extra. This seems to parallel this case here The only thing I'm wary of is the fact that it IS beta and could possibly bork some systems harder than we'd expect. But, I guess I trust the coreutils guys, at least
participants (5)
-
Aaron Griffin
-
Allan McRae
-
Andreas Radke
-
Dan McGee
-
RedShift