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: Re: [gentoo-dev] Documenting touching of arch profiles' files
Date: Fri, 2 Nov 2012 18:56:30 +0000	[thread overview]
Message-ID: <CAG2jQ8jvjoee6MffytcXHb=-3qDoYpMoAvCoF1oe4ZvEFstDyw@mail.gmail.com> (raw)
In-Reply-To: <CAB9SyzSuNj6YoCJ1SYcFAzhCjPRAZpVQkA3q-===cs0_LofnCg@mail.gmail.com>

On Fri, Nov 2, 2012 at 3:25 PM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 2 November 2012 18:01, Markos Chandras <hwoarang@gentoo.org> wrote:
>> On Fri, Nov 2, 2012 at 9:58 AM, Michał Górny <mgorny@gentoo.org> wrote:
> [...]
>>> With the exception of hppa which explicitly says its use.mask shouldn't
>>> be touched without permission, and now I can't enable pypy on flaggie
>>> because that arch is slacking. Great, isn't it?
>>
>> As Michael already said on the very first post on this thread, you are
>> free to touch the file is arch is slacking.
>
> In that case this whole policy is unnecessary, as the minor arches are
> always slacking and unresponsive, while x86 and amd64 have no problems
> with developers doing what they need to do in their profiles.
>
> In my opinion we should simply state that:
> 1) contacting arch teams is preferred, but should not hold up
> development activity if they are not immediately responsive
> 2) we need make sure a bug is filed for each issue, so arch teams are
> kept in the loop, and everyone can track what is going on
> 3) small changes are no problem (e.g. package.use.mask), but
> wider-reaching changes should be announced / discussed in advance
>

which are the minor arches? And how do you classify arches on major and minor?

I already said that if an arch is not responsive go ahead and commit
your changes.

Discussing it in a public ML everytime you want to touch the use.mask
of an arch is not efficient. A bug may be preferred yes.
Like I said, we already touch package.use.mask without previously
getting an ACK from the arch so the policy for this
situation will not change.

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2


      reply	other threads:[~2012-11-02 18:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-01 13:47 [gentoo-dev] Documenting touching of arch profiles' files Michael Palimaka
2012-11-01 23:47 ` Robin H. Johnson
2012-11-01 23:51   ` Diego Elio Pettenò
2012-11-02  0:07     ` Robin H. Johnson
2012-11-02 17:54   ` Jeroen Roovers
2012-11-02  9:50 ` Markos Chandras
2012-11-02  9:58   ` Michał Górny
2012-11-02 10:01     ` Markos Chandras
2012-11-02 15:25       ` Ben de Groot
2012-11-02 18:56         ` Markos Chandras [this message]

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='CAG2jQ8jvjoee6MffytcXHb=-3qDoYpMoAvCoF1oe4ZvEFstDyw@mail.gmail.com' \
    --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