From: William Hubbs <williamh@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14
Date: Thu, 4 Aug 2016 11:24:43 -0500 [thread overview]
Message-ID: <20160804162443.GA7048@whubbs1.gaikai.biz> (raw)
In-Reply-To: <2e11e445-c25b-b7f2-def1-99aed92308b6@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 2454 bytes --]
On Thu, Aug 04, 2016 at 04:15:14PM +0200, Kristian Fiskerstrand wrote:
> Dear all,
>
> the Gentoo Council will meet again on Sunday, August 14 at 19:00 UTC
> in #gentoo-council on FreeNode.
>
> Please reply to this message on the gentoo-project list with any items
> the council should put on its agenda to discuss or vote on.
I feel that our stable tree is so far behind on all
architectures that we are doing our stable users a disservice, so I
would like to open up a discussion here, and maybe some policy changes
at the next meeting.
Ultimately, I think we need some form of automated stabilization, e.g.
if a package version sits in ~ for 30 days and there are no blockers at
that point, the new version should go automatically to stable on all
architectures where there is a previous stable version.
I realize that automation is going to take a lot of work, so in the
meantime, I would like to discuss changes to our stabilization policies
that will get new versions of packages to stable faster.
The first issue is maintainers not filing stable requests for new
versions of packages in a timely manor. I'm not sure how to get around
this, but I feel that once a version of a package is stable, we are
doing a disservice to our stable users by not keeping stable as current
as possible. I am as bad as anyone; it is easy to forget to file
stable requests until someone pings me or files the request
themselves.
I have heard other maintainers say specifically that they do not file
stable requests unless a user asks them to, but Again, I do not feel
comfortable with this arrangement if there is an old version of the
package in stable. Users shouldn't have to ask for newer versions to be
stabilized; this should be driven by the maintainers.
The second issue is slow arch teams. Again, by not moving packages from
~ to stable, we are doing a disservice to our stable users.
I can think of two ways we can improve our situation.
We can allow maintainers to stabilize new versions of certain types of
packages on all arches where there is a previous version of the package stable
without filing stable requests. This would take a significant load off
of the arch teams.
For packages that do not fit the first group, we could require stable
requests, but allow maintainers to stabilize the new versions after a
timeout (I would propose 30 days).
What do folks think?
William
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2016-08-04 16:25 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-04 14:15 [gentoo-project] Call for agenda items - Council meeting 2016-08-14 Kristian Fiskerstrand
2016-08-04 16:24 ` William Hubbs [this message]
2016-08-04 17:08 ` Dirkjan Ochtman
2016-08-04 17:09 ` Brian Dolbec
2016-08-04 18:31 ` William Hubbs
2016-08-04 20:12 ` Andrew Savchenko
2016-08-04 22:22 ` William Hubbs
2016-08-04 23:25 ` Rich Freeman
2016-08-05 2:26 ` William Hubbs
2016-08-05 10:57 ` Rich Freeman
2016-08-05 14:28 ` William Hubbs
2016-08-05 14:36 ` Rich Freeman
2016-08-05 15:36 ` William Hubbs
2016-08-08 12:35 ` Marek Szuba
2016-08-08 19:51 ` Pacho Ramos
2016-08-09 2:07 ` Jack Morgan
2016-08-09 5:32 ` Kent Fredric
2016-08-09 5:59 ` Rich Freeman
2016-08-09 10:05 ` Kent Fredric
2016-08-09 14:41 ` Brian Dolbec
2016-08-09 15:12 ` Kent Fredric
2016-08-09 16:15 ` Brian Dolbec
2016-08-09 17:09 ` Kent Fredric
2016-08-09 17:12 ` Brian Evans
2016-08-09 17:18 ` Chí-Thanh Christopher Nguyễn
2016-08-09 17:22 ` Ciaran McCreesh
2016-08-09 20:08 ` Rich Freeman
2016-08-09 20:14 ` Kristian Fiskerstrand
2016-08-09 20:20 ` Kristian Fiskerstrand
2016-08-10 1:15 ` Pallav Agarwal
2016-08-10 1:28 ` Brian Dolbec
2016-08-05 17:32 ` Kristian Fiskerstrand
2016-08-05 17:29 ` Kristian Fiskerstrand
2016-08-04 21:30 ` Daniel Campbell
2016-08-05 16:11 ` Michael Orlitzky
2016-08-05 16:22 ` [gentoo-project] " Michael Palimaka
2016-08-05 17:06 ` Michael Orlitzky
2016-08-05 17:11 ` Chí-Thanh Christopher Nguyễn
2016-08-05 17:38 ` Michael Orlitzky
2016-08-05 17:19 ` Michał Górny
2016-08-05 17:21 ` Michael Orlitzky
2016-08-05 17:31 ` [gentoo-project] " Kristian Fiskerstrand
2016-08-05 18:42 ` William Hubbs
2016-08-05 18:45 ` Kristian Fiskerstrand
2016-08-05 18:55 ` NP-Hardass
2016-08-05 19:03 ` Kristian Fiskerstrand
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=20160804162443.GA7048@whubbs1.gaikai.biz \
--to=williamh@gentoo.org \
--cc=gentoo-project@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