From: Pacho Ramos <pacho@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items
Date: Mon, 06 Apr 2015 22:52:20 +0200 [thread overview]
Message-ID: <1428353540.2041.11.camel@gentoo.org> (raw)
In-Reply-To: <CAGfcS_k=6X-zc-koYZ4dmjkajZZLZt+3-n3n9Vv_4UUbNMwHsw@mail.gmail.com>
El dom, 05-04-2015 a las 20:47 -0400, Rich Freeman escribió:
> On Sun, Apr 5, 2015 at 7:05 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> >
> > How git is relevant I don't really see, you'd still have to re-test all
> > involved packages, so the effort is mostly in testing and not in running
> > ekeyword in a loop.
> >
>
> If you removed stable keywords from 300 packages, they would be in a
> single git commit. That means you can restore those keywords in a
> single command once you've checked that the new library can be made
> stable. The benefit of git is that tree-wide operations are atomic.
>
> Generally speaking arch teams do not test EVERY reverse dependency of
> a library with the stable branch before stabilizing it. Certainly
> arch teams that can't even keep up with stable requests will not do
> so.
>
> I'm not saying I'm in favor of breaking the stable depgraph. I just
> think that we need to think through the effects of removing hundreds
> of keywords on users (as bircoph points out in his reply). Neither
> option is terribly great.
>
From my point of view, I think we should *for now* focus on the affected
arches instead of trying to find a completely general policy to fit all
arches.
For instance, in this topic I haven't seen any comment from
alpha/ia64/sparc arch teams... I think those would be the fist
candidates for moving to testing only. On the other hand, Blueness has
multiple times replied for trying to handle ppc* (I also joined those
teams to try to help... I try but I don't have enough time for handling
all, in summary, when I have time, I am able then to do amd64, x86, ppc
and ppc64 at the same time, but not much more sadly :(. Maybe for ppc*
would be much more feasible to try to shrink their stable tree but still
keep a stable tree.
Also, for HPPA and ARM I have no complaints for now, then, I am unsure
if a general policy for all arches is really needed (or needs to block
the move to testing of, for example, ia64 and alpha)
That is the reason why I suggest at this stage to start suggesting to
move alpha/ia64/sparc to testing. Once the current arch team members are
then able to focus on remaining arches (as some of them won't need to
spend time on alpha/ia64/sparc anymore and, then, they should then have
more time for the others), we can re-evaluate then the situation of
remaining arches and try to handle them in the near future if needed.
But that is only my opinion of course :)
next prev parent reply other threads:[~2015-04-06 20:52 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-02 14:14 [gentoo-project] Council meeting 2015-04-14: call for agenda items Tim Harder
2015-04-02 16:45 ` Ulrich Mueller
2015-04-03 19:33 ` [gentoo-project] " Michael Palimaka
2015-04-03 20:01 ` Rich Freeman
2015-04-03 20:13 ` Andreas K. Huettel
2015-04-04 14:31 ` Michael Palimaka
2015-04-04 15:13 ` Rich Freeman
2015-04-04 15:44 ` Michał Górny
2015-04-04 15:48 ` Michał Górny
2015-04-04 22:02 ` William Hubbs
2015-04-05 12:32 ` Pacho Ramos
2015-04-05 12:44 ` Ben de Groot
2015-04-05 19:50 ` William Hubbs
2015-04-05 20:20 ` James Le Cuirot
2015-04-05 21:27 ` Andrew Savchenko
2015-04-05 22:54 ` Rich Freeman
2015-04-05 23:05 ` Patrick Lauer
2015-04-06 0:47 ` Rich Freeman
2015-04-06 7:55 ` Michał Górny
2015-04-06 20:52 ` Pacho Ramos [this message]
2015-04-06 22:22 ` Matt Turner
2015-04-07 15:38 ` Michael Palimaka
2015-04-07 23:25 ` Anthony G. Basile
2015-04-07 23:29 ` Rich Freeman
2015-04-07 23:50 ` Anthony G. Basile
2015-04-08 11:51 ` William Hubbs
2015-04-08 13:33 ` Rich Freeman
2015-04-08 17:39 ` William Hubbs
2015-04-08 18:15 ` Rich Freeman
2015-04-08 22:41 ` William Hubbs
2015-04-09 0:01 ` Rich Freeman
2015-04-08 11:58 ` Michael Palimaka
2015-04-07 23:38 ` Rich Freeman
2015-04-07 23:42 ` Francesco Riosa
2015-04-08 0:01 ` Matt Turner
2015-04-08 0:35 ` Rich Freeman
2015-04-05 23:38 ` Andrew Savchenko
2015-04-06 7:59 ` Michał Górny
2015-04-06 10:29 ` Rich Freeman
2015-04-06 11:09 ` Michał Górny
2015-04-06 21:37 ` Andrew Savchenko
2015-04-06 22:05 ` Michał Górny
2015-04-06 22:25 ` Andrew Savchenko
2015-04-06 22:28 ` William Hubbs
2015-04-07 0:02 ` Rich Freeman
2015-04-06 9:28 ` [gentoo-project] " Michał Górny
2015-04-11 7:13 ` Ben de Groot
2015-04-11 9:04 ` Ulrich Mueller
2015-04-11 11:58 ` Rich Freeman
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=1428353540.2041.11.camel@gentoo.org \
--to=pacho@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