From: Jose Luis Rivero <yoswink@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Proposal for how to handle stable ebuilds
Date: Tue, 11 Nov 2008 11:18:34 +0100 [thread overview]
Message-ID: <49195BFA.7060404@gentoo.org> (raw)
In-Reply-To: <4918DE04.8010207@gentoo.org>
Richard Freeman wrote:
> Jose Luis Rivero wrote:
>> I would prefer to analyze the causes of the slacker arch (manpower,
>> hardware, etc) and if we are not able to solve the problem by any way
>> (asking for new devs, buying hardware, etc) go for mark it as
>> experimental and drop all stable keywords.
>
> How is that better? Instead of dropping one stable package you'd end up
> dropping all of them. A user could accept ~arch and get the same
> behavior without any need to mark every other package in the tree
> unstable.
Accept ~arch for the random package which has lost the stable keyword a
random day? And next week .. which is going to be the next? The key is
the concept 'stable' and what you hope of it.
A long/middle-term solution for arches with very few resources instead
of generating problems to users seems a much better approach to me.
> An arch could put a note to that effect in their installation
> handbook. The user could then choose between a very narrow core of
> stable packages or a wider universe of experimental ones.
Mixing software branches is very easy in the Gentoo world but it has
some problems. Are you going to install in your stable (production,
critial, important,...) system a combination of packages not tested
before? Because the arch teams or the maintainers are not going to test
every posible combination of core stable + universe of experimental
packages. This is why branches exists.
> I guess the question is whether package maintainers should be forced to
> maintain packages that are outdated by a significant period of time.
> Suppose something breaks a package that is 3 versions behind stable on
> all archs but one (where it is the current stable). Should the package
> maintainer be required to fix it, rather than just delete it?
Maintainer has done all he can do, this means: that is broken, this
version fix the problem, go for it. Maintainer's job finishes here, now
it's the problem of your favorite arch team.
> I suspect
> that the maintainer would be more likely to just leave it broken, which
> doesn't exactly leave things better-off for the end users.
It's a different approach (maybe with the same bad results) but
different anyway. Leave the bug there, point the user to the bug and
maybe you can gain a new dev or an arch tester.
While the proposal made here is to throw random keyword problems to
users by policy (which in the case of amd64 some months ago would have
created a complete disaster).
> I'm sure the maintainers of qt/baselayout/coreutils/etc will exercise
> discretion on removing stable versions of these packages. However, for
> some obscure utility that next-to-nobody uses, does it really hurt to
> move from stable back to unstable if the arch maintainers can't keep up?
Special cases and special plans are allowed, what we are discussing here
is a general and accepted policy.
> I guess it comes down to the driving issues. How big a problem are
> stale packages (with the recent movement of a few platforms to
> experimental, is this an already-solved problem?)? How big of a problem
> do arch teams see keeping up with 30-days as (or maybe 60/90)? What are
> the practical (rather than theoretical) ramifications?
An interesting discussion. Ask our council to listen all parts:
maintainers, current arch teams, the experience of mips, etc. and try to
make a good choice.
Thanks Richard.
--
Jose Luis Rivero <yoswink@gentoo.org>
Gentoo/Alpha Gentoo/Do
next prev parent reply other threads:[~2008-11-11 10:19 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-10 18:13 [gentoo-dev] Proposal for how to handle stable ebuilds Mark Loeser
2008-11-10 18:23 ` Ciaran McCreesh
2008-11-10 18:23 ` Mart Raudsepp
2008-11-10 20:32 ` Steev Klimaszewski
2008-11-10 21:16 ` Jeremy Olexa
2008-11-10 21:57 ` Santiago M. Mola
2008-11-11 0:24 ` Jose Luis Rivero
2008-11-11 1:13 ` Mark Loeser
2008-11-11 9:31 ` Jose Luis Rivero
2008-11-11 1:21 ` Richard Freeman
2008-11-11 8:56 ` Peter Volkov
2008-11-11 10:18 ` Jose Luis Rivero [this message]
2008-11-11 13:49 ` Ferris McCormick
2008-11-11 16:06 ` [gentoo-dev] " Duncan
2008-11-11 16:24 ` Jeroen Roovers
2008-11-11 17:26 ` Duncan
2008-11-11 17:55 ` Ferris McCormick
2008-11-11 18:12 ` Jeroen Roovers
2008-11-11 21:03 ` Duncan
2008-11-13 17:38 ` [gentoo-dev] " Tobias Scherbaum
2008-11-15 13:02 ` Matti Bickel
2008-11-17 18:08 ` Tobias Scherbaum
2008-11-17 19:03 ` [gentoo-dev] " Duncan
2008-12-11 5:35 ` [gentoo-dev] " Donnie Berkholz
2008-11-17 0:38 ` [gentoo-dev] " Ryan Hill
2008-11-17 15:10 ` Daniel Gryniewicz
2008-11-18 1:08 ` Ryan Hill
2008-11-18 16:57 ` Daniel Gryniewicz
2008-11-18 17:50 ` Ciaran McCreesh
2008-11-18 20:31 ` Daniel Gryniewicz
2008-11-18 21:18 ` Ryan Hill
2008-11-18 22:04 ` Daniel Gryniewicz
2008-11-18 22:45 ` Ryan Hill
2008-11-30 22:59 ` Ryan Hill
2008-12-01 7:49 ` Peter Volkov
2008-12-11 5:37 ` [gentoo-dev] " Donnie Berkholz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49195BFA.7060404@gentoo.org \
--to=yoswink@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox