public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Markos Chandras <hwoarang@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Policy for late/slow stabilizations
Date: Sun, 27 Jun 2010 18:04:45 +0300	[thread overview]
Message-ID: <20100627150445.GA19456@Eternity> (raw)

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

Hi

As many of you have already noticed, there are some arches that are quite
slow on stabilizations. This leads to deprecated stabilizations e.g a
package is stabilized after 60 days which makes that version of
the specific package obsolete and not worth to stabilize anymore.

I would suggest to introduce a new rule where a stabilization bug may close
after 30 days. Arches that fail to stabilize it within this timeframe
they will simply don't have this package stable for them.

Moreover, slow arches introduce another problem as well. If a package is
marked stabled for their arch, but this package is quite old, and they fail to
stabilize a new version, we ( as maintainers ) can't drop the very old
( and obsolete ) version of this package because we somehow will break
the stable tree for these arches. How should we act in this case?
Keep the old version around forever just to say that "hey, they do have
a stable version for our exotic arch".

Whilst I do understand that these arches are understaffed and they can't keep
up with the increased stabilization load like x86/amd64 do, I still
think that slow stabilization leads to an obsolete stable tree which I
doesn't make sense to me after all.

Thoughts?

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

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

             reply	other threads:[~2010-06-27 15:07 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-27 15:04 Markos Chandras [this message]
2010-06-27 15:45 ` [gentoo-dev] Policy for late/slow stabilizations Patrick Lauer
2010-06-27 18:40   ` Tony "Chainsaw" Vroon
2010-06-27 15:47 ` Olivier Crête
2010-06-27 15:54   ` Markos Chandras
2010-06-27 18:21     ` Olivier Crête
2010-06-27 20:00       ` Markos Chandras
2010-06-27 16:30   ` Samuli Suominen
2010-06-28  3:53   ` Jeroen Roovers
2010-06-27 16:38 ` Ciaran McCreesh
2010-06-27 17:22   ` Markos Chandras
2010-06-27 17:43     ` Ciaran McCreesh
2010-06-27 18:01       ` Markos Chandras
2010-06-27 18:13         ` Ciaran McCreesh
2010-06-28  9:21       ` [gentoo-dev] " Duncan
2010-06-27 16:53 ` [gentoo-dev] " Auke Booij
2010-06-27 17:16   ` Markos Chandras
2010-06-27 18:15     ` Auke Booij
2010-06-27 19:58       ` Markos Chandras
2010-06-28  7:49         ` Thilo Bangert
2010-06-28 12:01           ` Mart Raudsepp
2010-06-27 18:07 ` Arfrever Frehtes Taifersar Arahesis
2010-06-27 18:37 ` Tony "Chainsaw" Vroon
2010-06-27 19:55   ` Markos Chandras
2010-06-27 20:01     ` Ciaran McCreesh
2010-06-27 20:10       ` Markos Chandras
2010-06-27 20:29 ` Nirbheek Chauhan
2010-06-27 21:38   ` Markos Chandras
2010-06-27 23:08     ` Nirbheek Chauhan

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=20100627150445.GA19456@Eternity \
    --to=hwoarang@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