public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Andrew Savchenko <bircoph@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
Date: Sat, 29 Jul 2017 21:03:42 +0300	[thread overview]
Message-ID: <20170729210342.65aacaa6e3c830e01c5779b0@gentoo.org> (raw)
In-Reply-To: <1931696.H1tAJ0QB7a@porto>

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

On Fri, 28 Jul 2017 12:44:20 +0200 Andreas K. Huettel wrote:
> Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
> > 
> > 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.
> > 
> 
> That's not feasible. It would kill off any semi-professional or professional 
> Gentoo use, where a minimum of stability is required. 
> 
> (Try keeping ~10 machines on stable running without automation. That's already 
> quite some work. Now try the same with ~arch. Now imagine you're talking about 
> 100 or 1000 machines.)
 
~50 hosts here on ~arch. Stable vs unstable is not an issue for
production. The main problem (at least in my case) is upgrade path,
especially with hosts not that often updated.

Upgrade of Gentoo-based production hosts takes considerable time,
not just due to compilation time and issues, but due to the need to
update dozens (sometimes hundreds) of config files properly and
this process can't be fully automated.

Another problem is short support time: only update path for systems
up to one year old is supported more or less. IRL even half year
old system may be PITA for a full update. To make it worse there
are cases when people deliberately make such updates harder: some
developers are refusing to set minimal version requirements for
dependencies if dependency versions below minimal were below latest
stable 1 year age. While such behaviour is within established
policies I frankly do not understand such devs: having
>=cat/foo-1.2.3 instead of cat/foo doesn't hurt, but makes life of
fellow users much easier.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2017-07-29 18:03 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
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 [this message]
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=20170729210342.65aacaa6e3c830e01c5779b0@gentoo.org \
    --to=bircoph@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