public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download: 
* Re: [gentoo-dev] rfc: revisiting our stabilization policy
  @ 2014-01-15  2:09 99%                   ` William Hubbs
  0 siblings, 0 replies; 1+ results
From: William Hubbs @ 2014-01-15  2:09 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]

On Tue, Jan 14, 2014 at 08:36:10PM -0500, Michael Orlitzky wrote:
> On 01/14/2014 08:23 PM, Tom Wijsman wrote:
> > On Tue, 14 Jan 2014 20:11:24 -0500
> > Michael Orlitzky <mjo@gentoo.org> wrote:
> > 
> >> On 01/14/2014 08:08 PM, Tom Wijsman wrote:
> >>>
> >>> This is under the assumption that the user knows of the state of the
> >>> stabilization worsening; if the user is unaware of that change, the
> >>> "could have done anyway" might be less common and first something
> >>> bad would need to happen before they realize the worsened
> >>> stabilization.
> >>>
> >>
> >> If I don't realize it, it ain't broke.
> > 
> > So, you're going to wait for corruption, a security breach or something
> > along those lines to happen first?
> 
> I will wait for them to be *known*.
> 
> Security stabilizations are already treated special, so while they'd
> make a nice example here you don't get to invoke them =)
> 
> It's highly unlikely that one day a stable piece of software is just
> going to start corrupting data randomly when some other stable package
> is updated. Why? Because arch testers have to test them before they go
> stable! It's even more unlikely that upgrading to untested stuff would
> be safer than staying put, which is really all I care about given a
> choice between the two.
> 
> For really bad cases like data corruption we already have procedures
> that allow quick stabilization ("reasonable amount of time..."). All
> we're really talking about here is forcing me to upgrade to an unstable
> package for some features or bugfixes I don't care about.

After the package has been sitting in ~arch for 90 days with an open
stable request with no blockers that the arch team has not taken any
action on. We are not talking about randomly yanking package versions,
just doing something when arch teams are not responsive, and it seems
that the cleanest thing to do would be to remove the old versions.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 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-14 21:37     [gentoo-dev] rfc: revisiting our stabilization policy William Hubbs
2014-01-14 21:57     ` Michael Orlitzky
2014-01-14 22:33       ` William Hubbs
2014-01-14 22:43         ` Michael Orlitzky
2014-01-14 23:11           ` William Hubbs
2014-01-15  0:47             ` Michael Orlitzky
2014-01-15  1:08               ` Tom Wijsman
2014-01-15  1:11                 ` Michael Orlitzky
2014-01-15  1:23                   ` Tom Wijsman
2014-01-15  1:36                     ` Michael Orlitzky
2014-01-15  2:09 99%                   ` William Hubbs

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox