Re: [gentoo-dev] Add bc back to the stage3

[Anthony G. Basile]

On 09/29/14 07:14, Rich Freeman wrote:
> On Mon, Sep 29, 2014 at 12:05 AM, Jorge Manuel B. S. Vicetto
> <jmbsvicetto@g.o> wrote:
>> No, there isn't a need for a Council vote here. This is something up to
>> Releng (in respect to what is in the stages) and to everyone in respect to
>> what is part of the system set.
> I don't think many really care about deferring to releng on what is in
> the stages.
>
> My concern is what is in @system, since that has a big impact on everybody.

The original point and reasoning was about getting bc back into stage3.  
The @system discussion came up secondarily because of the relationship 
between the two.  But note that, if the status quo remains (ie bc 
doesn't belong in stage3) then there would be no issue about @system.

>
>> I've stopped following this mailing list regularly quite sometime
>> ago. To see this thread is still going on and no one bothered to cc
>> releng, to me shows a lack of respect for the people actually doing
>> releases around here, as well as a real lack of interest in getting
>> this done as you can discuss this all you want, but in the end, it's
>> releng that works on this.
> Nobody is intending to show a lack of respect for anybody.  The whole
> point of having a mailing list is so that you don't have to CC every
> single developer on every single thread.
>
> Nobody is required to read -dev, but as was pointed out recently,
> claiming that you don't read -dev isn't really a good starting point
> for a complaint that you've been left out of something.  [1]
>
>> Further, to me, this is a case where if anyone tries to side-step Releng and
>> go over it with a Council decision, than the council members should be ready
>> to start doing Releng work.
>>
> So, do you have an opinion on this that you'd like to share?  I think
> it makes more sense to discuss what the best path forward is rather
> than argue about who gets to make the decision.
>
> Believe it or not, the folks who are on the Council aren't really
> interested in micro-managing everything that goes on in Gentoo.
> However, as you pointed out, everybody is impacted by what is in the
> system set, and the way "everybody" in Gentoo decides on things is
> through the Council.  The alternative is endless threads like this
> one.

What's in stage3 also impacts "everybody".  The point about 
micro-managing is a judgment call about how large the impact.  In my 
judgment, adding bc to stage3 or keeping the status quo is not a big 
enough issue that releng can't decide on their own.  While anything may 
come to the Council and be entertained by it (at the cost of time), it 
would be my position to motion that the issue be pushed back to releng 
for a decision.  At that point the Council will effectively be deciding 
whether or not they agree with me, namely, that this issue really 
doesn't impact everyone sufficiently to be taken out of releng's hands.  
It is important that the Council reflect the body's sensibilities about 
what is significant and what isn't.  If we start judging everything as 
having a "significant impact" and taking it from the respective teams, 
then we will be micro-managing despite our words to the contrary.  
Jorge's response "than the council members should be ready to start 
doing Releng work" would not be atypical if we start overstepping that 
line.  Although, I must say, Jorge's is being little premature here, and 
I doubt the Council will act rashly.

>
> No, the members of the Council aren't aware of every detail of
> everything that happens with Gentoo, and they don't possess every
> skill collectively possessed by every member of the community.  About
> the only thing the Council can claim is that people voted for them to
> represent the community, so it functions best when we actually act
> like a community.
>
> [1] - http://www.gentoo.org/proj/en/council/meeting-logs/20140408-summary.txt
>
> --
> Rich


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA