* Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
@ 2014-01-24 18:26 99% ` Tom Wijsman
0 siblings, 0 replies; 1+ results
From: Tom Wijsman @ 2014-01-24 18:26 UTC (permalink / raw
To: slong; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 3748 bytes --]
On Fri, 24 Jan 2014 10:46:06 +0000
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:
> Tom Wijsman wrote:
> > "Steven J. Long" wrote:
> > > What? Without a stable tree, Gentoo is useless afaic.
> >
> > It moves us closer to upstream releases, a little more bleeding
> > edge; a lot of users and developers run that already, it is found
> > to be useful.
>
> What? More vague. As are many of your philosophical statements in
> later and prior mails, so I'll ignore those.
It is reality; and thus, without a stable tree, Gentoo is still useful
for a lot of users and developers. What is vague about that?
> > > I don't think that's what was being proposed, though. The
> > > question was really the old complaint about slow architectures;
> > > the "-* arch" solution sounds like the most reasonable definition
> > > of "dropping" keywords, in the absence of AT communication
> > > otherwise.
> >
> > Dropping keywords and specifying -* are a world apart of each other.
>
> That's why it's in quotes.
Why is there at all if you intend it to be irrelevant to this thread?
> > The former means that it is not ready for wide stable or testing
> > users, the latter means that it has been tested to not work at all;
> > furthermore, we need to explicitly specify which arches in that
> > case.
>
> You're missing the point, again. The question was what does "dropping
> keywords" mean, when the maintainer has stabilised a newer version on
> the arch/s s/he has available, but feels that slower archs are holding
> up that process.
Where is that question?
> I'm slightly at a loss as to why it's such a big deal to just leave
> the old ebuild as-is, given that anyone on a stabled arch should
> upgrade automatically.
It is when you are running the arch that only has the old version.
> But given that the maintainer feels they don't want that old ebuild
> around, and that the arch in question has not got round to testing the
> new one, for whatever reason (it's their call, after all, as to how
> their arch progresses), instead of simply removing that ebuild, or
> bumping it to unstable (which makes zero sense), just leave it stable
> on the slow arch/s in question, and remove the others.
There are situations (security, stability, incompatibility) where
keeping it in place becomes a much harder task; at which point, removal
is bound to happen. At that point, such action is required.
It becomes faster than you think; if you depend on a library, and the
compatible range of that library gets wiped by a security bug, your
package will suddenly depend on an incompatible newer stabilized
version of the library at which point you are up for either a lot of
hard work or plain out starting the progress of masking and removing it.
> This seems like a rarity, but when it's an issue, people get annoyed
> on either side. The solution proposed by the ARM team,
Where is this solution?
> seems like a simple way round, and indicates clearly to anyone
> perusing the ebuild, that a newer version needs stabling on the
> "slow" archs.
Masking works fine for that too; what this does is make clear to the
user that (1) the current stable version has breakage for a specific
reason, (2) a newer stable version is not yet available and (3) that the
user can choose to keep the breakage or upgrade to an unstable version.
> By all means, raise technical objections; just not a philosophical
> one.
Where are these philosophical objections?
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : TomWij@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2014-01-15 1:36 [gentoo-dev] rfc: revisiting our stabilization policy Michael Orlitzky
2014-01-15 2:09 ` William Hubbs
2014-01-15 2:21 ` Michael Orlitzky
2014-01-15 2:46 ` William Hubbs
2014-01-16 7:28 ` Christopher Head
2014-01-16 22:44 ` Tom Wijsman
2014-01-19 22:31 ` Christopher Head
2014-01-20 0:47 ` Tom Wijsman
2014-01-23 18:12 ` [gentoo-dev] " Steven J. Long
2014-01-23 19:13 ` Tom Wijsman
2014-01-24 10:46 ` Steven J. Long
2014-01-24 18:26 99% ` Tom Wijsman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox