public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Sergei Trofimovich <slyfox@gentoo.org>
To: Peter Stuge <peter@stuge.se>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
Date: Tue, 25 Jul 2017 08:44:03 +0100	[thread overview]
Message-ID: <20170725084403.4dfc85af@sf> (raw)
In-Reply-To: <20170724232244.GT12397@stuge.se>

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

On Mon, 24 Jul 2017 23:22:44 +0000
Peter Stuge <peter@stuge.se> wrote:

> Thank you for working on this.
> 
> Sergei Trofimovich wrote:
> > Can this proposal make a difference and make gentoo better and
> > easier to work with?
> > 
> > Does it try to attack the right thing?
> > 
> > Does it completely miss the point?  
> 
> I hold a perhaps radical view: I would like to simply remove stable.
> 
> I continue to feel that maintaining two worlds (stable+unstable)
> carries with it an unneccessary cost.
> 
> Based solely on how excellently unstable (and similar approaches before
> using Gentoo) works for me in practice, I believe that skipping stable
> and instead focusing efforts on resolving problems reported in unstable
> a little quicker would yield a much better end result - and would net
> positive dev time.

Good point.

Stable is used by Gentoo to guard against wide-spread bugs sneaking
into everyone's systems: SIGSEGVing bootloaders (hard to recover),
crashing at startup browsers (hard to find a safe point to rollback),
hosed toolchains (hard to diagnose in time), widespread build breakages
due to incompatible API (or ABI) changes upstream (hard to recover).

It takes time to identify and devise mitigation for new issues. What
would be the mitigation mechanisims for those when we know something
is broken? Currently we say STABLE should work better as packages
there had wider and longer testing.

Why would removing stable speed things up?
Due to smaller amount of bugs to deal with?

Do you think Gentoo needs KEYWORDS at all?

Should packages be tracked as "seemingly working" on the arch
or package.mask is enough?

> > Does it sound fun?  
> 
> Sorry, no, not to me. It sounds like "double" overhead. :\
> 
> 
> I consider dev time a precious resource. Devs should need to do as
> few things as possible, to keep things going, and should be able to
> immediately reuse as much input from the wider community as possible.
> 
> More troubleshooting and fixing "hard" problems, less routine work.

Can you clarify what exactly you see currently as a routine work
on the dev side WRT stable?

Fixing bugs for non-latest packages?
Tracking manually lists for stabilization?
Something else?

Thanks!

-- 

  Sergei

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  parent reply	other threads:[~2017-07-25  7:44 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-24 21:22 [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts? Sergei Trofimovich
2017-07-24 21:52 ` [gentoo-dev] " Pacho Ramos
2017-07-24 23:22 ` [gentoo-dev] " Peter Stuge
2017-07-24 23:52   ` Rich Freeman
2017-07-25  4:34     ` [gentoo-dev] " Duncan
2017-07-25  6:26       ` Hans de Graaff
2017-07-25  6:18   ` [gentoo-dev] " Hans de Graaff
2017-07-25  9:18     ` Pacho Ramos
2017-07-25 11:54       ` Michał Górny
2017-07-25 12:15         ` Pacho Ramos
2017-07-25 13:19           ` Michał Górny
2017-07-25 13:23             ` Pacho Ramos
2017-07-25 11:26     ` Rich Freeman
2017-07-25  7:44   ` Sergei Trofimovich [this message]
2017-07-28 10:44   ` Andreas K. Huettel
2017-07-28 12:45     ` Marek Szuba
2017-07-28 13:10     ` Sam Jorna (wraeth)
2017-07-28 19:59       ` William L. Thomson Jr.
2017-07-28 21:21         ` David Seifert
2017-07-31  0:28         ` Sam Jorna
2017-07-31  0:40           ` Benda Xu
2017-07-31  2:44           ` William L. Thomson Jr.
2017-07-31  2:56             ` Sam Jorna
2017-07-31 15:00               ` William L. Thomson Jr.
2017-07-31 12:59             ` Andreas K. Huettel
2017-07-31 14:43               ` William L. Thomson Jr.
2017-07-31 14:47                 ` David Seifert
2017-07-28 19:44     ` Alec Warner
2017-07-29  1:05       ` Rich Freeman
2017-07-31 14:52         ` Alec Warner
2017-07-31 15:11           ` Rich Freeman
2017-07-31 16:51             ` Peter Volkov
2017-08-01  0:24             ` [gentoo-dev] " Duncan
2017-08-01  0:55               ` Rich Freeman
2017-08-01  1:45                 ` Duncan
2017-07-31 16:44           ` [gentoo-dev] " Michał Górny
2017-07-29  4:18       ` Daniel Campbell
2017-07-29 16:41         ` Mart Raudsepp
2017-07-29 19:10           ` David Seifert
2017-07-29 18:03     ` Andrew Savchenko
2017-07-25  7:22 ` Dirkjan Ochtman
2017-07-25 13:10   ` [gentoo-dev] " Michael Palimaka
2017-07-25 13:22     ` Rich Freeman
2017-07-25 20:16       ` Daniel Campbell
2017-07-25 13:36     ` Pacho Ramos
2017-07-25 14:15     ` Peter Stuge
2017-07-29 18:08   ` [gentoo-dev] " Christopher Head
2017-07-31  6:49     ` R0b0t1
2017-07-25  9:03 ` [gentoo-dev] " Agostino Sarubbo
2017-07-25 19:45   ` Markus Meier
2017-07-25 20:12     ` Rich Freeman
2017-07-26  5:49   ` Hans de Graaff
2017-07-25 12:59 ` Michael Palimaka
2017-07-25 13:30   ` Pacho Ramos
2017-07-25 13:51   ` Michał Górny
2017-07-25 14:13 ` [gentoo-dev] " Michał Górny
2017-07-25 14:28   ` Rich Freeman
2017-07-27 23:12 ` Denis Dupeyron
2017-07-27 23:41   ` Rich Freeman
2017-07-28  0:03     ` Denis Dupeyron
2017-07-28 21:24       ` William Hubbs
2017-07-29 10:24   ` Andrew Savchenko
2017-07-28 20:10 ` William L. Thomson Jr.
2017-07-28 21:12   ` A. Wilcox
2017-07-28 21:41     ` William L. Thomson Jr.
2017-07-29 13:41     ` Andreas K. Huettel
2017-07-28 21:45   ` [gentoo-dev] " Duncan
2017-07-28 21:56     ` William L. Thomson Jr.
2017-07-29 19:44       ` Walter Dnes

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=20170725084403.4dfc85af@sf \
    --to=slyfox@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=peter@stuge.se \
    /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