[gentoo-project] Questions for Candidates (was: Questioning/Interviewing council nominees)

[gentoo-project] Questions for Candidates (was: Questioning/Interviewing council nominees)

[hasufell]

Ok, so we have a seperate thread for this.

Anybody who cares can pose a question with context to the current
council election.

Candidates don't need to answer.

For the previous quetions/answers see the subthread
"Questioning/Interviewing council nominees" of "Council nominations".

Re: [gentoo-project] Questions for Candidates (was: Questioning/Interviewing council nominees)

[Markos Chandras]

On 17 June 2013 19:46, hasufell <hasufell@gentoo.org> wrote:
> Ok, so we have a seperate thread for this.
>
> Anybody who cares can pose a question with context to the current
> council election.
>
> Candidates don't need to answer.
>
> For the previous quetions/answers see the subthread
> "Questioning/Interviewing council nominees" of "Council nominations".
>

Maybe it's best to wait until we have a complete list with all the candidates.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-project] Questions for Candidates (was: Questioning/Interviewing council nominees)

[Michał Górny]

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

Dnia 2013-06-17, o godz. 20:46:19
hasufell <hasufell@gentoo.org> napisał(a):

> Ok, so we have a seperate thread for this.
> 
> Anybody who cares can pose a question with context to the current
> council election.
> 
> Candidates don't need to answer.
> 
> For the previous quetions/answers see the subthread
> "Questioning/Interviewing council nominees" of "Council nominations".

I'd even ask candidates not to answer in this thread. Just make
a complete list of questions, in the meantime take the nominations
and let the nominees answer them when the list is ready.


-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-project] Questions for Candidates (was: Questioning/Interviewing council nominees)

[Pacho Ramos]

El lun, 17-06-2013 a las 21:10 +0200, Michał Górny escribió:
> Dnia 2013-06-17, o godz. 20:46:19
> hasufell <hasufell@gentoo.org> napisał(a):
> 
> > Ok, so we have a seperate thread for this.
> > 
> > Anybody who cares can pose a question with context to the current
> > council election.
> > 
> > Candidates don't need to answer.
> > 
> > For the previous quetions/answers see the subthread
> > "Questioning/Interviewing council nominees" of "Council nominations".
> 
> I'd even ask candidates not to answer in this thread. Just make
> a complete list of questions, in the meantime take the nominations
> and let the nominees answer them when the list is ready.
> 
> 

Yeah, I think it's the cleaner solution, otherwise, it's really a pain
to review mail when I return home :O

Re: [gentoo-project] Questions for Candidates (was: Questioning/Interviewing council nominees)

[Rich Freeman]

On Mon, Jun 17, 2013 at 3:10 PM, Michał Górny <mgorny@gentoo.org> wrote:
> I'd even ask candidates not to answer in this thread. Just make
> a complete list of questions, in the meantime take the nominations
> and let the nominees answer them when the list is ready.

The intent of my suggestion was basically to collect questions now,
and just let the candidates stick their answers in their manifestos.
Consider this thread a list of topics voters are interested in.

And let's avoid turning every question, response, manifesto, etc into
a standing debate.  Devs are asking questions, candidates are
answering them, that's it (don't like the answer, don't vote, or by
all means ping them on irc or something).

Rich

[gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

@dberkholz

- From your manifesto:

> I continue to believe that technical advances are, and should be, 
> driven by individuals. Given our volunteer culture, a council can't
>  force people to do things they don't want to do, but it can help
> to break up disputes and roadblocks, and make global decisions when
> needed.

Do you think that gentoo is consistent in it's behavior?

Should the council step in without any1 asking them if there are
changes about to happen that are a) global and b) highly controversial
discussed?

As an example: multilib. The council was not involved in that decision
between eclass vs multilib-portage. Since any1 is allowed to add
eclasses to the tree the decision was somehow implicit, without any
real consensus on what the course should be.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRx2iKAAoJEFpvPKfnPDWzU8QH/0FF4OSMB2jcBqJnHFWLgdGK
zopByu4MYKrCgh2vkVVJFohdfgNrGk0XqDIMXQ5Mc4qJSSnuGdHCQd2WbyaGpUT/
VFo3NcMl2XUmzV/6XRmlc1QxfIymHsbnHl6GU/QPkBl/tUMBJrE2fd2TOZK1moCr
POdzH0eUqbzTs1kafX/htb+H/+uZ6gu4uelovaGSnP4q+bYzuxZBEk+QGedrS+5o
BSHBtg7lLz3RuEksj7mNdVEy8K6BWeUBlUOX6p1M86rsqr95Yr//Qc58O/lLe39X
cQVd7ZDNcDO+iiv5uZNJlQgVL3rxfrtrC+o53JTY8HJ2P5l6Oh1E8iXucrimszg=
=ijU/
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/23/2013 05:28 PM, hasufell wrote:
> @dberkholz
> 
> From your manifesto:
> 
>> I continue to believe that technical advances are, and should be,
>> driven by individuals. Given our volunteer culture, a council can't
>>  force people to do things they don't want to do, but it can help
>> to break up disputes and roadblocks, and make global decisions when
>> needed.
> 
> Do you think that gentoo is consistent in it's behavior?
> 
> Should the council step in without any1 asking them if there are
> changes about to happen that are a) global and b) highly controversial
> discussed?
> 
> As an example: multilib. The council was not involved in that decision
> between eclass vs multilib-portage. Since any1 is allowed to add
> eclasses to the tree the decision was somehow implicit, without any
> real consensus on what the course should be.
> 
> 

- From http://devmanual.gentoo.org/eclass-writing/ :

"Before committing a new eclass to the tree, it should be emailed to the
gentoo-dev mailing list with a justification and a proposed
implementation. Do not skip this step — sometimes a better
implementation or an alternative which does not require a new eclass
will be suggested."

The dev manual doesn't believe this is implicit nor without any
consensus.  True, it doesn't ban you from adding a new eclass, but it
doesn't say you can just go and randomly add new eclasses without
discussion either.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRx33WAAoJEKXdFCfdEflKQscQALJBt8oaLsdVKO0U/KSo7ZFo
RZ3/JJLkoFY1In6ny4aLN/50Fzimdi1+941gViMMixFOspHN3iDqL26PqZGR9dnV
NLoNm2sGOEFp0kfTK2Ebx6BZN+9MhMxHTdJAwHd7QxCdV2Zat2UuoQLcRVNlL66H
as1ogjjZAeYeDQbz5Jqu9mxVRpZUuvINAqwS0Pe44kP9hzgEqlKUTXshxhwfJnZM
hMWHfFG7KRDvlrttM0oPK3kLh/djn5RWGbuMGoycmogBgmbwvdGf9V8WNreynivO
rDcY9L4Mjp4o873CgW2ffPdTNb5NYkaQ0amJg3HWG33B2MNWx1ULSJ+yneuHewfz
7YtaVy8MHElllpckFSNhrk1as9PY2hLaivm0XmZZQ7GUcAo2tkcHAmOuxvYYmfu6
Sz3JYflUfgrpsycuBDrFMxz4/CsuxhJ1HhPLShJufVXmNOAQJiwRYUvvZ0Qy+6zP
IOQIPd12BZGoyovOUjEA2zuHRxpDX7Tv8Em7HSmscwzNR+QQ/4MvNpk3BolvDPX6
h8hLou6yBgEIab2IN8dbsoyFaqSHW/jjsYes50HISUYXdDuSivkoqyFjGmd23w5n
bO0JRJDbDbrh1H/nmQkxeaHz4BunuinJoii7l7l3og3tj0LiZoyI9HkkDaNWGybE
CXuBbHFK2jldX7mdBJzC
=HkU2
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[hasufell]

On 06/24/2013 12:59 AM, Rick "Zero_Chaos" Farina wrote:
> On 06/23/2013 05:28 PM, hasufell wrote:
> > @dberkholz
>
> > From your manifesto:
>
> >> I continue to believe that technical advances are, and should be,
> >> driven by individuals. Given our volunteer culture, a council can't
> >>  force people to do things they don't want to do, but it can help
> >> to break up disputes and roadblocks, and make global decisions when
> >> needed.
>
> > Do you think that gentoo is consistent in it's behavior?
>
> > Should the council step in without any1 asking them if there are
> > changes about to happen that are a) global and b) highly controversial
> > discussed?
>
> > As an example: multilib. The council was not involved in that decision
> > between eclass vs multilib-portage. Since any1 is allowed to add
> > eclasses to the tree the decision was somehow implicit, without any
> > real consensus on what the course should be.
>
>
>
> - From http://devmanual.gentoo.org/eclass-writing/ :
>
> "Before committing a new eclass to the tree, it should be emailed to the
> gentoo-dev mailing list with a justification and a proposed
> implementation. Do not skip this step — sometimes a better
> implementation or an alternative which does not require a new eclass
> will be suggested."
>
> The dev manual doesn't believe this is implicit nor without any
> consensus.  True, it doesn't ban you from adding a new eclass, but it
> doesn't say you can just go and randomly add new eclasses without
> discussion either.
>
> -Zero


I know the devmanual quite well. The example in it's procedure was a bit
more complex than you are describing, so I don't see how that adds anything.

People agreed that the eclass is fine, but there was no real consensus
about the question whether we actually want an eclass based solution.
You can't have both, because it does not make sense. At one point you
have to decide, council did nothing to aid in this heated (really
heated) discussion.

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Matt Turner]

On Mon, Jun 24, 2013 at 3:27 PM, hasufell <hasufell@gentoo.org> wrote:
> People agreed that the eclass is fine, but there was no real consensus
> about the question whether we actually want an eclass based solution.
> You can't have both, because it does not make sense.

You can, and I expect that we will. I don't want to start a big
discussion. I really just wanted to address this single point.

If the package manager provides a way to handle multilib more cleanly
I expect that we'll switch to it.

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Michał Górny]

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

Dnia 2013-06-25, o godz. 00:27:55
hasufell <hasufell@gentoo.org> napisał(a):

> On 06/24/2013 12:59 AM, Rick "Zero_Chaos" Farina wrote:
> > The dev manual doesn't believe this is implicit nor without any
> > consensus.  True, it doesn't ban you from adding a new eclass, but it
> > doesn't say you can just go and randomly add new eclasses without
> > discussion either.
> 
> I know the devmanual quite well. The example in it's procedure was a bit
> more complex than you are describing, so I don't see how that adds anything.
> 
> People agreed that the eclass is fine, but there was no real consensus
> about the question whether we actually want an eclass based solution.
> You can't have both, because it does not make sense. At one point you
> have to decide, council did nothing to aid in this heated (really
> heated) discussion.

Wasn't there? I can think of the two people being really unhappy with
it (guess why), a few more being unsure or indifferent. You can't get
all the people to be happy.

I'm really sorry that you're unhappy with the solution we've put our
work into. But I'd really appreciate if you two stopped undermining it,
'spreading FUD' and accepted the fact that -- even if the eclass-based
solution didn't get a 'real consensus' -- yours wouldn't get even that
close to it.

And I'm sad that you can't keep it professional. I'm doing my best to
help you with multilib-portage. It's an out-of-tree project which is
not officially supported, yet I hack the eclass to keep it working.
And I don't get anything for it, really, just more blustering
[dictionary translation, meaning may have been lost].

That said, I don't know what the Council could or should do. Should
the Council be responsible for reading discussions and grabbing whether
there was a consensus or not? Or making one in the name of the whole
community?

Last but not least, I don't even know if there were *two* solutions
proposed. It seems a bit like it's between *a working solution now*,
and not doing anything and waiting till you get it anywhere near
official acceptance. Note that the timeframe and willingness of people
to work on it is an important point as well. And likeliness that
everything breaks apart when people touch multilib.eclass.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Tony Vroon]

On Tue, 2013-06-25 at 09:11 +0200, Michał Górny wrote:
> That said, I don't know what the Council could or should do. Should
> the Council be responsible for reading discussions and grabbing
> whether there was a consensus or not? Or making one in the name of the
> whole community?

That is not the council's role, at least not as it is defined right now.
If more than a vocal minority of developers support a change of
direction I would like to hear about it.
Obviously I would have liked to have heard about this when I could still
action it... but better late than never...

Regards,
Tony V.

P.S. With all this eleventh hour direction-changing I'll submit my
manifesto at the eleventh hour. Out of sheer necessity really.

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/25/2013 09:11 AM, Michał Górny wrote:
> Dnia 2013-06-25, o godz. 00:27:55 hasufell <hasufell@gentoo.org>
> napisał(a):
> 
>> On 06/24/2013 12:59 AM, Rick "Zero_Chaos" Farina wrote:
>>> The dev manual doesn't believe this is implicit nor without
>>> any consensus.  True, it doesn't ban you from adding a new
>>> eclass, but it doesn't say you can just go and randomly add new
>>> eclasses without discussion either.
>> 
>> I know the devmanual quite well. The example in it's procedure
>> was a bit more complex than you are describing, so I don't see
>> how that adds anything.
>> 
>> People agreed that the eclass is fine, but there was no real
>> consensus about the question whether we actually want an eclass
>> based solution. You can't have both, because it does not make
>> sense. At one point you have to decide, council did nothing to
>> aid in this heated (really heated) discussion.
> 
> Wasn't there? I can think of the two people being really unhappy
> with it (guess why), a few more being unsure or indifferent. You
> can't get all the people to be happy.
> 
> I'm really sorry that you're unhappy with the solution we've put
> our work into. But I'd really appreciate if you two stopped
> undermining it, 'spreading FUD' and accepted the fact that -- even
> if the eclass-based solution didn't get a 'real consensus' -- yours
> wouldn't get even that close to it.
> 
> And I'm sad that you can't keep it professional. I'm doing my best
> to help you with multilib-portage. It's an out-of-tree project
> which is not officially supported, yet I hack the eclass to keep it
> working. And I don't get anything for it, really, just more
> blustering [dictionary translation, meaning may have been lost].
> 
> That said, I don't know what the Council could or should do.
> Should the Council be responsible for reading discussions and
> grabbing whether there was a consensus or not? Or making one in the
> name of the whole community?
> 
> Last but not least, I don't even know if there were *two*
> solutions proposed. It seems a bit like it's between *a working
> solution now*, and not doing anything and waiting till you get it
> anywhere near official acceptance. Note that the timeframe and
> willingness of people to work on it is an important point as well.
> And likeliness that everything breaks apart when people touch
> multilib.eclass.
> 


I'm sorry but this is all somehow offtopic, since the questions were
directed to dberkholz and can be answered without discussing the
_example_.

Thanks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRyVtwAAoJEFpvPKfnPDWzl8QH/0zfThFHJdjqSts5dSYoSFre
lqQEqUw/zpCv6xstG5WGXV1YSAhciTLIr7FNRHL5Hx0zKckG3tJo09sevW78ja1K
1WuLI21So8AEPpUFhT+jT8b6xoHr/tO0Jf/6THKygWQn/5WkjS/yFbR/3VKB9Mgk
Mx7pRxUeh3MX3seFuT9PtrW30YWeinqaVVmef7JcJNOZGMW69m5NbHWY4vnF1Ogy
I1P94pq3ce/UFJqKrpsDZnIR2marEhTMKv7VV8hcay2XaarYr32myTupYeLVDlAX
kpze8BbkvKJ2yYNjxO7GtEj5k7PV5K251xbKvugVNcPYQTt69U7dDcuVoa/gCEY=
=zqua
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Donnie Berkholz]

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

On 23:28 Sun 23 Jun     , hasufell wrote:
> @dberkholz
> 
> - From your manifesto:
> 
> > I continue to believe that technical advances are, and should be, 
> > driven by individuals. Given our volunteer culture, a council can't
> >  force people to do things they don't want to do, but it can help
> > to break up disputes and roadblocks, and make global decisions when
> > needed.
> 
> Do you think that gentoo is consistent in it's behavior?

Definitely not, since Gentoo isn't really an entity that can make 
decisions on its own. It's a big mob of developers with a small amount 
of structure glued on top that kicks in when the mob starts to split 
apart.

That said, mobs tend to migrate together, and Gentoo slowly drifts in 
various directions over time.

> Should the council step in without any1 asking them if there are 
> changes about to happen that are a) global and b) highly controversial 
> discussed?

If they are that controversial, why wouldn't the people who disagree 
with the actions request that the council make a decision, either before 
or after the fact? I have to assume the controversy was not particularly 
important and global if nobody on either side cares enough to ask the 
council to look into it.

--
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>

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

[gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[hasufell]

On 06/25/2013 03:25 AM, Patrick Lauer wrote:> On 06/16/2013 07:24 PM,
Agostino Sarubbo wrote:
>> I'm using the same thread, I'd like to nominate:
>
>> patrick
>
> I accept. And as soon as I'm less distracted with life I'll be a bit
> more verbose :)
>
>

Although you might answer that question in your manifesto, I just take
the liberty to ask here:


Do you think the git migration is a good thing and will improve
contributions and workflow? Will you support it?

[gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Patrick Lauer]

On 06/29/2013 06:33 AM, hasufell wrote:
> On 06/25/2013 03:25 AM, Patrick Lauer wrote:> On 06/16/2013 07:24 PM,
> Agostino Sarubbo wrote:
>>> I'm using the same thread, I'd like to nominate:
>>
>>> patrick
>>
>> I accept. And as soon as I'm less distracted with life I'll be a bit
>> more verbose :)
>>
>>
> 
> Although you might answer that question in your manifesto, I just take
> the liberty to ask here:
> 
> 
> Do you think the git migration is a good thing and will improve
> contributions and workflow? Will you support it?
> 

Good thing - well. Hmm. It'll make a few things marginally easier, and a
few things a lot harder. So that adds up to "Meh"

It'll force people to adapt to new and exciting workflows (and
excitement is not something I demand), but I guess people are in need of
Change.
(What's more fun than having 4 unsynchronized checkouts and
cross-merging between them?)

As long as people will document things, be prepared to fix the random
breakage that will happen (ey, git lost its head, now what?), etc. etc.
... I'm pretty much indifferent.

Should people try to change things and not document things (thus trying
to make my life more difficult) I'll do what I can to be lazy and get in
their way, fair is fair :)

Re: [gentoo-project] Questions for Candidates (was: Questioning/Interviewing council nominees)

[Rich Freeman]

On Mon, Jun 17, 2013 at 2:46 PM, hasufell <hasufell@gentoo.org> wrote:
> Ok, so we have a seperate thread for this.
>
> Anybody who cares can pose a question with context to the current
> council election.
>
> Candidates don't need to answer.

I've posted responses to these in my manifest at:
http://dev.gentoo.org/~rich0/council-manifesto-2013.xml

I'll update this as other questions get posted to eliminate excess
traffic in this thread, and will add new content to the bottom to make
it easier to follow along.

Rich

[gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/28/2013 07:43 PM, Chí-Thanh Christopher Nguyễn wrote:> Agostino
Sarubbo schrieb:
>> I'm using the same thread, I'd like to nominate:
>> 
>> chithanh
> 
> Thank you, I accept. My manifesto: 
> http://dev.gentoo.org/~chithanh/council/manifesto-201306.txt
> 
> 
> Best regards, Chí-Thanh Christopher Nguyễn
> 
> 


Do you think package forks or split-packages for single files would
improve user experience?

What should be our _priority_? Keeping devs happy or keeping users happy?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRzxdZAAoJEFpvPKfnPDWzIOQIALUloOdFz4B1dLWL7JGTxcbV
OgOqRpm8s696v3oN6cPEbkWBNeIQImHRKVA1uurPHqJivxF286bZjq4WrIR6ZrHm
+FDSAred8z1jR9203Gn/G4Bs3hjsxMTuIlmOCUjg7CkiM1VxiajKtfechbaqKtPz
w6865Lg9llgnkmuJNTI3Iraori8DmcYruyQz5oLazDCUWiBWTVJRLyoOWBVFLymV
Oa5rhW2J3SS4cmXf0gvfb88lun3GuUT6Gg9pyI0mETy70ll53ngLDU8oU7Ks6ZWI
4mpslrg7gIwUKSN9LS0qNFcVlYuBxSCiaGzyK0PoIBU90+XU4MFx2anCtzD7gGU=
=b9hJ
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Markos Chandras]

On 29 June 2013 18:20, hasufell <hasufell@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/28/2013 07:43 PM, Chí-Thanh Christopher Nguyễn wrote:> Agostino
> Sarubbo schrieb:
>>> I'm using the same thread, I'd like to nominate:
>>>
>>> chithanh
>>
>> Thank you, I accept. My manifesto:
>> http://dev.gentoo.org/~chithanh/council/manifesto-201306.txt
>>
>>
>> Best regards, Chí-Thanh Christopher Nguyễn
>>
>>
>
>
> Do you think package forks or split-packages for single files would
> improve user experience?
>
> What should be our _priority_? Keeping devs happy or keeping users happy?

Developers are also users. So these are not two distinct groups.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[hasufell]

On 06/29/2013 07:41 PM, Markos Chandras wrote:
> On 29 June 2013 18:20, hasufell <hasufell@gentoo.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 06/28/2013 07:43 PM, Chí-Thanh Christopher Nguyễn wrote:> Agostino
>> Sarubbo schrieb:
>>>> I'm using the same thread, I'd like to nominate:
>>>>
>>>> chithanh
>>>
>>> Thank you, I accept. My manifesto:
>>> http://dev.gentoo.org/~chithanh/council/manifesto-201306.txt
>>>
>>>
>>> Best regards, Chí-Thanh Christopher Nguyễn
>>>
>>>
>>
>>
>> Do you think package forks or split-packages for single files would
>> improve user experience?
>>
>> What should be our _priority_? Keeping devs happy or keeping users happy?
> 
> Developers are also users. So these are not two distinct groups.
> 


They are two distinct groups, although an individual can be part of both.

And it's even possible that something makes him happy in his position as
a developer, but unhappy in his user experience. So this question makes
perfect sense.

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Chí-Thanh Christopher Nguyễn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hasufell schrieb:
>> Thank you, I accept. My manifesto: 
>> http://dev.gentoo.org/~chithanh/council/manifesto-201306.txt
> 
> Do you think package forks or split-packages for single files would 
> improve user experience?
> 
> What should be our _priority_? Keeping devs happy or keeping users
> happy?

Running Gentoo requires our users to make informed decisions all the time.
As long as the forked or split packages are accompanied with documentation
describing straightforward ways how to make use of them, I do not see any
significant degradation of user experience.

About keeping devs happy vs. keeping users happy: I think that everyone of
us has an idea of what Gentoo is and what it isn't.

Is Gentoo a distribution for users who refuse to read documentation and
expect a one-click install? Hardly. Yet sometimes, I encounter users in
#gentoo / #gentoo-ten on freenode IRC, who just booted the LiveDVD or
InstallCD, and ask how to start the installer. They often leave
disappointed when we inform them that Gentoo installation has to be done
manually.

This may be an extreme example, but I think that while making users happy
is a good thing, there are limits on how far we go to cater for certain
users. Deciding where this limit is I see in the responsibility of each
individual package maintainer. If you think that a developer does not do
enough to keep a particular group of users happy, present to him your case
and encourage him to make the necessary changes.


Best regards,
Chí-Thanh Christopher Nguyễn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAlHPRSkACgkQ+gvH2voEPRBt1gCeLc4EfLzD/Qt093/MRIyQj6mj
PYIAn02/fEYMT6bhyyfjlKi2yNKQub28
=fNqK
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Matthew Summers]

On Sat, Jun 29, 2013 at 3:35 PM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> Running Gentoo requires our users to make informed decisions all the time.

This is a great statement about Gentoo. I couldn't agree more. Thanks.
-- 
Matthew W. Summers
Gentoo Foundation Inc.
GPG: 111B C438 35FA EDB5 B5D3 736F 45EE 5DC0 0878 9D46

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Michael Weber]

On 06/30/2013 03:57 AM, Matthew Summers wrote:
> On Sat, Jun 29, 2013 at 3:35 PM, Chí-Thanh Christopher Nguyễn
> <chithanh@gentoo.org> wrote:
>> Running Gentoo requires our users to make informed decisions all the time.
> 
> This is a great statement about Gentoo. I couldn't agree more. Thanks.
> 
True. But most decisions can be revised with ease (1), as long as you
known your commands[1]. So it's a great playground to learn things
behind the curtains of polished GUIs.

(1) glibc downgrade, hardened/x32/non-multilib switch
-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Rich Freeman]

On Sat, Jun 29, 2013 at 4:35 PM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> hasufell schrieb:
>> What should be our _priority_? Keeping devs happy or keeping users
>> happy?
>
> Running Gentoo requires our users to make informed decisions all the time.
> As long as the forked or split packages are accompanied with documentation
> describing straightforward ways how to make use of them, I do not see any
> significant degradation of user experience.

So, I thought this was a thread for asking questions and not answering
them, but it seems like this is turning into a general discussion.

Agree 100% that running Gentoo requires users to make informed
decisions all the time.  The question was about split packages for
single files though - not split packages in general.  Splitting up
kdebase is a great idea.  Splitting up apache into apache,
apache-gentooconfig, apache-initd, apache-logrotate, etc just because
the apache maintainer thinks that we should simply install vanilla
upstream files and logrotate is of the devil is a really bad idea.
That doesn't make any user or dev happy, save perhaps the maintainer.

Forked packages are potentially even worse.  Do you want the version
of apache that contains backported bugfixes but vanilla config files,
or the one that has gentooified configs but no init-script?  Maybe
somebody should make yet another fork that mixes and matches those.
Then another maintainer makes a fork with a logrotate script, but they
only include systemd units and not an initd script.

Maintainers shouldn't have to do the work to support any configuration
they're not comfortable testing/etc, but if somebody else comes along
to do it for them, the solution is cooperation, not revert wars.

Rich

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Chí-Thanh Christopher Nguyễn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rich Freeman schrieb:
> Forked packages are potentially even worse.  Do you want the version of
> apache that contains backported bugfixes but vanilla config files, or
> the one that has gentooified configs but no init-script?  Maybe somebody
> should make yet another fork that mixes and matches those. Then another
> maintainer makes a fork with a logrotate script, but they only include
> systemd units and not an initd script.

I do agree that forked packages do decrease usability to some degree. But I
think that is not a serious problem as long as their number remains
manageable, and proper documentation exists. Should a situation like the
one you describe arise for a non-negligible amount of packages, then I
might reconsider this position.

Note however that I consider the scenario that you describe somewhat
unlikely, because I expect that any package fork will be done with the
intention of swaying as many users as possible to the new package.
Therefore, it will probably include most if not all functions of the
original package.

> Maintainers shouldn't have to do the work to support any configuration 
> they're not comfortable testing/etc, but if somebody else comes along to
> do it for them, the solution is cooperation, not revert wars.

Yes, cooperation is better. But the method how to achieve cooperation is
convincing through arguments, not forcing changes against the wishes of the
maintainer.


Best regards,
Chí-Thanh Christopher Nguyễn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAlHQEcEACgkQ+gvH2voEPRAKsgCeNMMLVG6x1l5r5hz2ZxUsP2kv
jYUAn3tV5oMvHvFpSVP0W3LTatvz64C7
=z3uz
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Rich Freeman]

On Sun, Jun 30, 2013 at 7:08 AM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> Note however that I consider the scenario that you describe somewhat
> unlikely, because I expect that any package fork will be done with the
> intention of swaying as many users as possible to the new package.
> Therefore, it will probably include most if not all functions of the
> original package.

Agreed, but even then you start having nomenclature issues.  Do we
really want new users to have to figure out that apache is the package
that nobody uses because a stubborn maintainer is sitting on the name,
while apache-fixed is the one that actually works like most would
expect it to?

> Yes, cooperation is better. But the method how to achieve cooperation is
> convincing through arguments, not forcing changes against the wishes of the
> maintainer.

There we disagree.  Maintaining a package is a privilege conditioned
on using that power in alignment with our philosophies, not a right.
I wouldn't force the maintainer to actively support any particular
config, but I wouldn't allow them to actively interfere with the
properly-supported work of any project.  I'll leave it at that - many
will agree, many will disagree.  I'm going to be completely up-front
about my beliefs here, and I'm eager to see how the majority view is
reflected in votes in the hope that the community can pick one
direction and start moving in it either way.

Rich

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[William Hubbs]

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

On Sun, Jun 30, 2013 at 07:18:49AM -0400, Rich Freeman wrote:
> On Sun, Jun 30, 2013 at 7:08 AM, Chí-Thanh Christopher Nguyễn
> <chithanh@gentoo.org> wrote:
> > Yes, cooperation is better. But the method how to achieve cooperation is
> > convincing through arguments, not forcing changes against the wishes of the
> > maintainer.
> 
> There we disagree.  Maintaining a package is a privilege conditioned
> on using that power in alignment with our philosophies, not a right.
> I wouldn't force the maintainer to actively support any particular
> config, but I wouldn't allow them to actively interfere with the
> properly-supported work of any project.  I'll leave it at that - many
> will agree, many will disagree.  I'm going to be completely up-front
> about my beliefs here, and I'm eager to see how the majority view is
> reflected in votes in the hope that the community can pick one
> direction and start moving in it either way.

I'm going to agree with Rich. Maintaining a package in Gentoo is a
privilege; not a right. Maintainers do not own the packages; we as a
distribution own them. Packages should be maintained in a manor that is
in line with the gentoo philosophy.

William


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

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Brian Dolbec]

On Sun, 2013-06-30 at 13:52 -0500, William Hubbs wrote:
> On Sun, Jun 30, 2013 at 07:18:49AM -0400, Rich Freeman wrote:
> > On Sun, Jun 30, 2013 at 7:08 AM, Chí-Thanh Christopher Nguyễn
> > <chithanh@gentoo.org> wrote:
> > > Yes, cooperation is better. But the method how to achieve cooperation is
> > > convincing through arguments, not forcing changes against the wishes of the
> > > maintainer.
> > 
> > There we disagree.  Maintaining a package is a privilege conditioned
> > on using that power in alignment with our philosophies, not a right.
> > I wouldn't force the maintainer to actively support any particular
> > config, but I wouldn't allow them to actively interfere with the
> > properly-supported work of any project.  I'll leave it at that - many
> > will agree, many will disagree.  I'm going to be completely up-front
> > about my beliefs here, and I'm eager to see how the majority view is
> > reflected in votes in the hope that the community can pick one
> > direction and start moving in it either way.
> 
> I'm going to agree with Rich. Maintaining a package in Gentoo is a
> privilege; not a right. Maintainers do not own the packages; we as a
> distribution own them. Packages should be maintained in a manor that is
> in line with the gentoo philosophy.
> 
> William
> 

Overall, I agree with both sides

1) What Chí-Thanh said is true:

Yes, cooperation is better. But the method how to achieve cooperation is
convincing through arguments,...

2) What Rich said is also true:

Maintaining a package is a privilege conditioned
on using that power in alignment with our philosophies, not a right.


The main problem here is finding the right balance between convincing
(first choice) and mandating (if convincing fails).  Unfortunately, like
anywhere else in this world, not everyone will agree on where that
balance point should be.  There will always be extremists on both ends
of the debate.  It is the developers votes that will determine which end
of the spectrum the balance point will be.  It is also prudent for them
to vote in someone that can see both ends of the spectrum ;)

-- 
Brian Dolbec <dolsen@gentoo.org>

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[William Hubbs]

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

On Sun, Jun 30, 2013 at 01:56:05PM -0700, Brian Dolbec wrote:
> Overall, I agree with both sides
> 
> 1) What Chí-Thanh said is true:
> 
> Yes, cooperation is better. But the method how to achieve cooperation is
> convincing through arguments,...
> 
> 2) What Rich said is also true:
> 
> Maintaining a package is a privilege conditioned
> on using that power in alignment with our philosophies, not a right.
> 
> 
> The main problem here is finding the right balance between convincing
> (first choice) and mandating (if convincing fails).  Unfortunately, like
> anywhere else in this world, not everyone will agree on where that
> balance point should be.  There will always be extremists on both ends
> of the debate.  It is the developers votes that will determine which end
> of the spectrum the balance point will be.  It is also prudent for them
> to vote in someone that can see both ends of the spectrum ;)

Nothing is an absolute. I'm not saying that anyone who doesn't like
something a maintainer does should be able to force the maintainer to do
what they want.

Chithanh, please stop me and correct me if I am wrong.

The way I understand what you are saying is that you believe the
maintainers have absolute authority over what happens with their
packages. So if I file a bug against a package requesting a change that
I think would bring the package more in line with the gentoo philosophy for
example and explain to the maintainer why I think that is the case and
He closes my bug invalid or wontfix, you feel that I should not take my
concerns to qa or the council. correct?

What happens if I am actually a co-maintainer but another co-maintainer
blocks my changes?

imo there should be, and is, an arbitration path for this sort of thing.

William


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

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Rich Freeman]

On Sun, Jun 30, 2013 at 8:59 PM, William Hubbs <williamh@gentoo.org> wrote:
> Nothing is an absolute. I'm not saying that anyone who doesn't like
> something a maintainer does should be able to force the maintainer to do
> what they want.

Ditto.  I only want maintainers to not be able to get in the way of
reasonable and well-supported projects and other teams.

If a maintainer just hates having foo-1.2 in the tree because they put
foo-1.3 in the tree yesterday, and foo-1.2 is stable on x86, we
already require them to wait until 1.3 can be stabilized (perhaps
rapidly if a security issue).  Maintainers already must coordinate
with other projects.

In general I'm not in favor of forcing maintainers to do anything
beyond fixing glaring QA issues.  If a maintainer wants to have a
non-upstreamed patch that doesn't cause issues that isn't a big
problem IMHO.

However, if another dev wants to co-maintain and make that
non-upstream patch USE-dependent and support the work, the original
maintainer must allow them to do so.  If the x32 project wants to add
a conditional patch to support their arch and they are willing to
follow-through on support, the original maintainer must allow this.
Non-maintainers must always collaborate with maintainers, but the
intent of that isn't so that maintainers can block other projects.

I've been in the place of having somebody come along and bump an EAPI
on me or make other changes that I'd honestly have been more
comfortable taking my time with.  I understand that the job of a
maintainer is easier if they can block outside changes entirely.
However, we need to strike a balance.

And on the other side of things I'm completely against scripted
tree-wide changes without a great deal of care (honestly, I'd prefer
that all scripted changes against the tree aside maybe from package
renames be reviewed on -dev first unless they're confined to within a
project's domain - such as the KDE team making a change to only KDE
packages).  I'm also against fly-by commits where a dev makes changes
but isn't willing to stand behind them.  I think that is what we need
to protect against, not well-organized projects adding config files to
daemons.

Rich

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
> If a maintainer just hates having foo-1.2 in the tree because they put
> foo-1.3 in the tree yesterday, and foo-1.2 is stable on x86, we
> already require them to wait until 1.3 can be stabilized (perhaps
> rapidly if a security issue).  Maintainers already must coordinate
> with other projects.

I did not say that maintainers can ignore policy. The removal of ebuilds
must follow certain rules which are set in policy.

For example, you cannot ignore reverse dependencies when removing a
package. Also you are not allowed to drop the latest stable version of a
package without following proper procedure.

> However, if another dev wants to co-maintain and make that
> non-upstream patch USE-dependent and support the work, the original
> maintainer must allow them to do so.  If the x32 project wants to add
> a conditional patch to support their arch and they are willing to
> follow-through on support, the original maintainer must allow this.
> Non-maintainers must always collaborate with maintainers, but the
> intent of that isn't so that maintainers can block other projects.

With x32 specifically, a number of people including some upstreams think
that the whole concept is a bad idea. A case could be made for patches
that #ifdef x32 and which compile to a no-op on other arches, but even
those must be maintained. What if the patch no longer applies after a
version bump?

> I've been in the place of having somebody come along and bump an EAPI
> on me or make other changes that I'd honestly have been more
> comfortable taking my time with.

That's great, and I encourage all developers to allow this too. But I am
against forcing anybody.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Chí-Thanh Christopher Nguyễn]

William Hubbs schrieb:
> Chithanh, please stop me and correct me if I am wrong.
>
> The way I understand what you are saying is that you believe the
> maintainers have absolute authority over what happens with their
> packages. So if I file a bug against a package requesting a change that
> I think would bring the package more in line with the gentoo philosophy for
> example and explain to the maintainer why I think that is the case and
> He closes my bug invalid or wontfix, you feel that I should not take my
> concerns to qa or the council. correct?

If you can demonstrate that the package is in violation of policy, or
there is an immediate danger to users' Gentoo installations, then of
course you can expect QA or the council to step up and make the
necessary changes.

If however there is no policy which mandates such a change, and all
attempts to resolve the issue directly with the maintainer are
unsuccessful, then you can still come to the council and we will try to
mediate. But I do not support forcing your view over the maintainer's.

> What happens if I am actually a co-maintainer but another co-maintainer
> blocks my changes?

If the maintainers are part of a team or project, then the (elected)
lead can decide. If not, then they will have to reach consensus somehow.

> imo there should be, and is, an arbitration path for this sort of thing.

Mediation, yes. Binding arbitration, no.


Best regards,

Chí-Thanh Christopher Nguyễn

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Rich Freeman]

On Mon, Jul 1, 2013 at 5:32 AM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> Rich Freeman schrieb:
>> If a maintainer just hates having foo-1.2 in the tree because they put
>> foo-1.3 in the tree yesterday, and foo-1.2 is stable on x86, we
>> already require them to wait until 1.3 can be stabilized (perhaps
>> rapidly if a security issue).  Maintainers already must coordinate
>> with other projects.
>
> I did not say that maintainers can ignore policy. The removal of ebuilds
> must follow certain rules which are set in policy.

IMO this really doesn't say anything at all.  Of course maintainers
have to follow policy.  The question is what should the policy be?
The original question was whether we should be forking or splitting
packages over adding single files when the maintainer doesn't want
them in the original package.  Right now we have no explicit policy
governing this.

I don't think it necessarily needs to be written down, but if people
are going to refuse to cooperate using the lack of something written
down as an excuse and devrel feels that they can't do anything about
it in the absence of a written policy, then we'll need a new policy.
I think the policy should basically amount to requiring devs to
coordinate with maintainers, but that maintainers can not outright
block well-supported project-related work without Council approval.
Also, policy would be that anybody can become a maintainer of any
package, but they're responsible for their actions and maintainers
must coordinate.

I don't think we need rules for everything.  However, if the lack of a
policy is causing paralysis then a policy should be created.  That
said, this might be a moot issue - the only Dev to really be vocal
about blocking such changes asked to retire a week or two ago over
this very debate.  I'd probably wait until a real issue comes up, but
I would not take my time about dealing with it (announce an immediate
case-by-case decision and then write up a GLEP/etc over the next few
weeks).

>
> With x32 specifically, a number of people including some upstreams think
> that the whole concept is a bad idea. A case could be made for patches
> that #ifdef x32 and which compile to a no-op on other arches, but even
> those must be maintained. What if the patch no longer applies after a
> version bump?

Well, since I'm only talking about WELL-SUPPORTED project-related
work, just ask the project team to fix the patch.  If they don't in a
reasonable timeframe, then it isn't well-supported and the maintainer
can do whatever they want with it.  Project teams should only take on
patches if they think they can sustain them.  Most likely for
something like x32 they'd only do it for strategic packages anyway
(toolchain, etc).

This is no different than requiring arch teams to operate in a timely
manner/etc.  If a project is getting out of hand Maintainers can talk
to the lead, and bring it to Council if necessary.

Honestly, I think an issue here is that some would like Gentoo to
slowly transform into a retirement community where nobody wants cars
driving on the road after 7PM.  I see Gentoo as a place where people
can do things that are new and exciting, and yet still run a
traditional system.  For end users I want to contain disruption, and
for maintainers I want to coordinate disruption, but if we want to be
a place where innovation happens, disruption is going to be there.
Advocates for disruptive changes should be required to properly
coordinate and support these changes, but they should not be at the
mercy of individuals who want to block these changes.

>
>> I've been in the place of having somebody come along and bump an EAPI
>> on me or make other changes that I'd honestly have been more
>> comfortable taking my time with.
>
> That's great, and I encourage all developers to allow this too. But I am
> against forcing anybody.

I'm not going to force anybody to do anything they don't already have
to do.  I'm just not going to let them stand in the way.  I think
there is a balance, but right now we're moving too far in the
direction of treating packages as the personal property of
maintainers, and that needs adjustment.  It is certainly possible to
move too far in the other direction, and perhaps our current situation
is the result of over-reaction to these kinds of problems in the past
(devs running scripts against the tree and such).

Rich

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
>> I did not say that maintainers can ignore policy. The removal of
>> ebuilds must follow certain rules which are set in policy. 
> IMO this really doesn't say anything at all.  Of course maintainers
> have to follow policy.  The question is what should the policy be?

I think I am beginning to understand what you want to say. You want the
council (or some other body) to act as enforcer to bring maintainers in
line with prevailing opinion. Sorry, I am not supporting that.

> The original question was whether we should be forking or splitting
> packages over adding single files when the maintainer doesn't want
> them in the original package.  Right now we have no explicit policy
> governing this.

Yes, and due to the absence of policy it is the maintainer who has the
final say. That is how it is currently, and how I think it should be in
the future too. GLEP 39 specifically says that you cannot monopolize the
package, and anyone can fork the ebuild. That is sufficient remedy
against uncooperative maintainers in my eyes.

I wrote in a previous message that I would reconsider my position if the
amount of forked packages grew to unmanageable proportions. But until
then, if the kids cannot get along they shall play on separate playgrounds.

>> With x32 specifically, a number of people including some upstreams think
>> that the whole concept is a bad idea. A case could be made for patches
>> that #ifdef x32 and which compile to a no-op on other arches, but even
>> those must be maintained. What if the patch no longer applies after a
>> version bump?
> Well, since I'm only talking about WELL-SUPPORTED project-related
> work, just ask the project team to fix the patch.  If they don't in a
> reasonable timeframe, then it isn't well-supported and the maintainer
> can do whatever they want with it.  Project teams should only take on
> patches if they think they can sustain them.  Most likely for
> something like x32 they'd only do it for strategic packages anyway
> (toolchain, etc).

But in this hypothetical scenario you have unloaded additional work on
the maintainer. He just wants to bring the latest and greatest version
to his users, and the failing patch prevents him from doing that. He has
to request and then wait for the a new patch, and if he bumps the
package anyway after timeout risks breaking x32 users' systems.
If he does this voluntarily, fine. If the patch was forced on him,
putting him in this dilemma is not fair.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Rich Freeman]

On Mon, Jul 1, 2013 at 7:16 AM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
>
> I wrote in a previous message that I would reconsider my position if the
> amount of forked packages grew to unmanageable proportions. But until
> then, if the kids cannot get along they shall play on separate playgrounds.

As far as I'm concerned, kids who can't get along can go play
someplace else.  If you want your own apache ebuild that can't be
touched by anybody but you, that's what overlays are for.

Don't like that, please don't vote for me.  I have no issues with real
alternate implementations (openrc vs systemd, udev vs eudev,
consolekit vs logind, alsa sorta-vs pulseaudio, etc).  However,
projects that discuss their plans openly, embrace our philosophy of
choice, and which properly support their work to our quality standards
will be able to take dumps on your packages if you put them in the
main tree and there is nothing you'll be able to do about it.  Call it
tyranny of the majority if it makes you happier, but a distro that
gives every developer veto-power over any change is destined for
extinction.  Innovation will always come from individual developers;
the role of the Council is not to try to mandate innovation, but to
get the roadblocks out of the way so that it can flourish.

Gentoo has never needed internal forks simply because developers
cannot get along.  I don't see single-text-file additions to packages
as a reason that we should start.

> But in this hypothetical scenario you have unloaded additional work on
> the maintainer. He just wants to bring the latest and greatest version
> to his users, and the failing patch prevents him from doing that.

Is it more work?  Only in the sense that not being able to drop stable
versions is.  If things get out of hand we'll deal with them, but
polluting the package namespace with internal forks is a really ugly
technical solution to a really simple people problem.

Rich

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Markos Chandras]

On 1 July 2013 12:36, Rich Freeman <rich0@gentoo.org> wrote:
> On Mon, Jul 1, 2013 at 7:16 AM, Chí-Thanh Christopher Nguyễn
> <chithanh@gentoo.org> wrote:
>>
>> I wrote in a previous message that I would reconsider my position if the
>> amount of forked packages grew to unmanageable proportions. But until
>> then, if the kids cannot get along they shall play on separate playgrounds.
>
> As far as I'm concerned, kids who can't get along can go play
> someplace else.  If you want your own apache ebuild that can't be
> touched by anybody but you, that's what overlays are for.
>

I have to agree with that. You can't compete with the other high-end distros
if you spend your (limited) manpower forking packages just because two (or more)
maintainers can't work together. If this keep happening then we are
doomed to always be
one step behind in user experience.
We may as well turn the whole packaging thing into an internal
competition. Whoever has the
prettiest ebuild wins a "Larry The Cow" t-shirt and a goodie bag :)

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Ben de Groot]

On 1 July 2013 19:16, Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> Rich Freeman schrieb:
>>> I did not say that maintainers can ignore policy. The removal of
>>> ebuilds must follow certain rules which are set in policy.
>> IMO this really doesn't say anything at all.  Of course maintainers
>> have to follow policy.  The question is what should the policy be?
>
> I think I am beginning to understand what you want to say. You want the
> council (or some other body) to act as enforcer to bring maintainers in
> line with prevailing opinion. Sorry, I am not supporting that.
>
>> The original question was whether we should be forking or splitting
>> packages over adding single files when the maintainer doesn't want
>> them in the original package.  Right now we have no explicit policy
>> governing this.
>
> Yes, and due to the absence of policy it is the maintainer who has the
> final say. That is how it is currently, and how I think it should be in
> the future too. GLEP 39 specifically says that you cannot monopolize the
> package, and anyone can fork the ebuild. That is sufficient remedy
> against uncooperative maintainers in my eyes.
>
> I wrote in a previous message that I would reconsider my position if the
> amount of forked packages grew to unmanageable proportions. But until
> then, if the kids cannot get along they shall play on separate playgrounds.
>
>>> With x32 specifically, a number of people including some upstreams think
>>> that the whole concept is a bad idea. A case could be made for patches
>>> that #ifdef x32 and which compile to a no-op on other arches, but even
>>> those must be maintained. What if the patch no longer applies after a
>>> version bump?
>> Well, since I'm only talking about WELL-SUPPORTED project-related
>> work, just ask the project team to fix the patch.  If they don't in a
>> reasonable timeframe, then it isn't well-supported and the maintainer
>> can do whatever they want with it.  Project teams should only take on
>> patches if they think they can sustain them.  Most likely for
>> something like x32 they'd only do it for strategic packages anyway
>> (toolchain, etc).
>
> But in this hypothetical scenario you have unloaded additional work on
> the maintainer. He just wants to bring the latest and greatest version
> to his users, and the failing patch prevents him from doing that. He has
> to request and then wait for the a new patch, and if he bumps the
> package anyway after timeout risks breaking x32 users' systems.
> If he does this voluntarily, fine. If the patch was forced on him,
> putting him in this dilemma is not fair.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>

Thank you for this voice of reason.

--
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[hasufell]

On 07/01/2013 01:16 PM, Chí-Thanh Christopher Nguyễn wrote:
> But until
> then, if the kids cannot get along they shall play on separate playgrounds.

That separate playground is usually an overlay and it has already
happened, see "gamerlay" which is now terribly unmaintained and only has
one/two active users (no dev) who do not get any review and find it more
convenient than sunrise. That has lead to low QA and ebuilds scattered
across overlays instead of being in the tree. Eventually they even
overwrite crucial libraries like "libsdl" and break them.

Other _devs_ just open their own overlay for such ebuilds, because they
don't want to work with some project/herd.

Does that improve user experience? Is that the answer to a systematic
problem of inconsistency and stubbornness? Will that make any1
reconsider his attitude about being a maintainer and realize that it
means to serve the _user_?

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Arun Raghavan]

On 1 July 2013 17:06, Rich Freeman <rich0@gentoo.org> wrote:
> On Mon, Jul 1, 2013 at 7:16 AM, Chí-Thanh Christopher Nguyễn
> <chithanh@gentoo.org> wrote:
>>
>> I wrote in a previous message that I would reconsider my position if the
>> amount of forked packages grew to unmanageable proportions. But until
>> then, if the kids cannot get along they shall play on separate playgrounds.
>
> As far as I'm concerned, kids who can't get along can go play
> someplace else.  If you want your own apache ebuild that can't be
> touched by anybody but you, that's what overlays are for.
>
> Don't like that, please don't vote for me.  I have no issues with real
> alternate implementations (openrc vs systemd, udev vs eudev,
> consolekit vs logind, alsa sorta-vs pulseaudio, etc).  However,
> projects that discuss their plans openly, embrace our philosophy of
> choice, and which properly support their work to our quality standards
> will be able to take dumps on your packages if you put them in the
> main tree and there is nothing you'll be able to do about it.  Call it
> tyranny of the majority if it makes you happier, but a distro that
> gives every developer veto-power over any change is destined for
> extinction.  Innovation will always come from individual developers;
> the role of the Council is not to try to mandate innovation, but to
> get the roadblocks out of the way so that it can flourish.
>

Well said. Thank you for putting this down and taking a definitive
stance once this.

--
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
> On Mon, Jul 1, 2013 at 7:16 AM, Chí-Thanh Christopher Nguyễn
> <chithanh@gentoo.org> wrote:
>>
>> I wrote in a previous message that I would reconsider my position if the
>> amount of forked packages grew to unmanageable proportions. But until
>> then, if the kids cannot get along they shall play on separate playgrounds.
> 
> As far as I'm concerned, kids who can't get along can go play
> someplace else.  If you want your own apache ebuild that can't be
> touched by anybody but you, that's what overlays are for.

And then the Gentoo portage ebuild loses its maintainer? How is that supposed
to make anything better?


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Chí-Thanh Christopher Nguyễn]

hasufell schrieb:
> On 07/01/2013 01:16 PM, Chí-Thanh Christopher Nguyễn wrote:
>> But until
>> then, if the kids cannot get along they shall play on separate playgrounds.
> 
> That separate playground is usually an overlay and it has already
> happened,

They can each have their own ebuild in portage. I do not think that overlays
are the solution here.

> Does that improve user experience? Is that the answer to a systematic
> problem of inconsistency and stubbornness?

I fail to see the systematic problem. It was a couple of devs who made drama.
Not enough in my eyes to justify a policy change.

> Will that make any1
> reconsider his attitude about being a maintainer and realize that it
> means to serve the _user_?

No, it means to scratch an itch.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Rich Freeman]

On Mon, Jul 1, 2013 at 1:25 PM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> Rich Freeman schrieb:
>> As far as I'm concerned, kids who can't get along can go play
>> someplace else.  If you want your own apache ebuild that can't be
>> touched by anybody but you, that's what overlays are for.
>
> And then the Gentoo portage ebuild loses its maintainer? How is that supposed
> to make anything better?

First, most people aren't going to quit over this.  The maintainer
doesn't have to do anything but not actively revert changes made by
the project teams.

If they do quit, somebody else will have to step up and maintain it,
or it gets treecleaned (eventually).  Short-term it might be a loss.
Long-term I think it is the only way we can thrive.

You can't make everybody happy.  If we make Gentoo the best place for
FOSS contributors to be if they don't want to have to cooperate with
anybody else, then those are exactly the sorts of applicants we will
get.  If we make Gentoo a place where it is easy to make big (optional
to users and devs alike) changes and initiatives, then people
interested in these will come join us.  Somebody made an excellent
point about making sure that candidate developers were a good cultural
fit, but just what kind of culture do we want them to fit into?  Not
everybody is going to agree on what kind of culture we should have,
but not making any choice at all is resulting in WW3 in the trenches
and nobody seems to be happy as a result.  Sometimes you just have to
make a choice.

Frankly I've never been one to cater to "do it my way or I'll quit."
If doing it their way makes sense that's fine, but if it isn't a
win/win then sometimes no deal is the lesser evil.

Rich

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[hasufell]

On 07/01/2013 07:26 PM, Chí-Thanh Christopher Nguyễn wrote:
> hasufell schrieb:
>> On 07/01/2013 01:16 PM, Chí-Thanh Christopher Nguyễn wrote:
>>> But until
>>> then, if the kids cannot get along they shall play on separate playgrounds.
>>
>> That separate playground is usually an overlay and it has already
>> happened,
> 
> They can each have their own ebuild in portage. I do not think that overlays
> are the solution here.
> 

That idea is so bad I hope we will never see it happen.
A distribution is a _centralized_ place where packages are maintained
_consistently_.

If we don't care about consistency anymore and cover the lack of
professionalism (people who ignore philosophy, policy, don't communicate
etc) under "choice" then we are heading for a user-free community.

>> Does that improve user experience? Is that the answer to a systematic
>> problem of inconsistency and stubbornness?
> 
> I fail to see the systematic problem. It was a couple of devs who made drama.
> Not enough in my eyes to justify a policy change.

No, I was not talking about systemd files and I do not want this topic
to be cut down to that issue. It's about widespread behavior causing
confusion for users and worsening the user experience.

consequences:
- devs who are sick of other devs/herds/projects that they continue to
a) maintain a package alone (not an improvement) or even b) maintain it
in an overlay to avoid conflict with territorial people
- devs who push a different ebuild for the same package to gx86 causing
a) duplicated work b) confusion for the user and c) avoiding to work
with each other
- devs who stop to care for some package and doing their modifications
locally without ever pushing/discussing them

win-win?

> 
>> Will that make any1
>> reconsider his attitude about being a maintainer and realize that it
>> means to serve the _user_?
> 
> No, it means to scratch an itch.
> 
> 

I think we will not improve as a distro if we do not redefine our
priorities.
I have the feeling that our work is not user-centered anymore, but
developer-centered and that concept is simply wrong and no sane business
manager would ever disagree.

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Chí-Thanh Christopher Nguyễn]

hasufell schrieb:
>> They can each have their own ebuild in portage. I do not think that overlays
>> are the solution here.
> 
> That idea is so bad I hope we will never see it happen.

That's what GLEP 39 explictly allows.

>>> Will that make any1
>>> reconsider his attitude about being a maintainer and realize that it
>>> means to serve the _user_?
>>
>> No, it means to scratch an itch.
> 
> I think we will not improve as a distro if we do not redefine our
> priorities.
> I have the feeling that our work is not user-centered anymore, but
> developer-centered and that concept is simply wrong and no sane business
> manager would ever disagree.

If you want a user-centric distro which is run by business managers, that
niche is already occupied. If Gentoo tried to achieve a linear user
experience, putting uniformity over diversity, then we'd just become a poor
copy of Ubuntu. Would it increase our user base? Probably. Would it still be
Gentoo? I'm not sure.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
>> And then the Gentoo portage ebuild loses its maintainer? How is that supposed
>> to make anything better?
> 
> First, most people aren't going to quit over this.  The maintainer
> doesn't have to do anything but not actively revert changes made by
> the project teams.

I don't say that they quit altogether. Just that they may leave that
particular ebuild in portage alone (and continue in an overlay as was
suggested) because they don't want to have anything to do with the changes
that were forced upon them.

> If they do quit, somebody else will have to step up and maintain it,
> or it gets treecleaned (eventually).  Short-term it might be a loss.
> Long-term I think it is the only way we can thrive.

So until someone else steps up, users will have the great experience of a
unified ebuild that nobody takes care of.

I'll take the reasoning with the maintainer approach (without threatening to
apply anyway if you arguments fail to convince him) over this insanity any day.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[William Hubbs]

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

On Mon, Jul 01, 2013 at 08:37:57PM +0200, Chí-Thanh Christopher Nguyễn wrote:
> hasufell schrieb:
> >> They can each have their own ebuild in portage. I do not think that overlays
> >> are the solution here.
> > 
> > That idea is so bad I hope we will never see it happen.
> 
> That's what GLEP 39 explictly allows.

I have to agree on this point. glep 39 allows, and should allow
competing projects.

> >>> Will that make any1
> >>> reconsider his attitude about being a maintainer and realize that it
> >>> means to serve the _user_?
> >>
> >> No, it means to scratch an itch.
> > 
> > I think we will not improve as a distro if we do not redefine our
> > priorities.
> > I have the feeling that our work is not user-centered anymore, but
> > developer-centered and that concept is simply wrong and no sane business
> > manager would ever disagree.

We are a group of volunteers, not a business, so I'm not sure how much
the business model can apply to us.

> If you want a user-centric distro which is run by business managers, that
> niche is already occupied. If Gentoo tried to achieve a linear user
> experience, putting uniformity over diversity, then we'd just become a poor
> copy of Ubuntu. Would it increase our user base? Probably. Would it still be
> Gentoo? I'm not sure.

By the nature of being a source based distribution, we can offer a
uniform user experience without being a poor copy of any binary
distribution, and that uniform user experience could be far more
flexable than any binary distribution.

William


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

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Rich Freeman]

On Mon, Jul 1, 2013 at 3:08 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Mon, Jul 01, 2013 at 08:37:57PM +0200, Chí-Thanh Christopher Nguyễn wrote:
>> hasufell schrieb:
>> >> They can each have their own ebuild in portage. I do not think that overlays
>> >> are the solution here.
>> >
>> > That idea is so bad I hope we will never see it happen.
>>
>> That's what GLEP 39 explictly allows.
>
> I have to agree on this point. glep 39 allows, and should allow
> competing projects.

GLEP 39 ALLOWS me to make a competing apache ebuild, or a competing
amd64 arch.  It doesn't FORCE me to do so.

If all I want to do is introduce some optional feature distro-wide
that doesn't impact anybody who doesn't want to use it (aside from
trivial numbers of inodes), then I shouldn't HAVE to fork every
package in the tree to do it.

This isn't about taking away the freedom of people to fork things,
this is about taking away the freedom of Maintainers to force people
to fork things.

>> > I think we will not improve as a distro if we do not redefine our
>> > priorities.
>> > I have the feeling that our work is not user-centered anymore, but
>> > developer-centered and that concept is simply wrong and no sane business
>> > manager would ever disagree.
>
> We are a group of volunteers, not a business, so I'm not sure how much
> the business model can apply to us.

Sure, but why would anybody volunteer to work on an unusable distro?
Just what is Gentoo's purpose?  If all I wanted was a set of packages
that only could be reliably used in some particular configuration I
could take my pick of binary distros.

I'm a developer because I'm also a user.  Nobody pays me to work on
ebuilds - I'm scratching my itch.  Nobody is asking maintainers to
scratch somebody else's itch - they just have to stay out of the way
when somebody else chooses to do so.

> By the nature of being a source based distribution, we can offer a
> uniform user experience without being a poor copy of any binary
> distribution, and that uniform user experience could be far more
> flexable than any binary distribution.

Absolutely, but that flexibility depends on a certain amount of
standardization.  If every package maintainer was free to make up
their own arch keywords there would be chaos (x86_64 vs amd64
anyone?).  No problem - just fork every package in the tree and users
can try to guess whether apache or apache-fixed is the one that will
work better with their choice of php or php-improved.  Don't like
USE=X?  Just make your package have IUSE=x - somebody can fork it if
they don't like it.

If all you want is a bunch of clean upstream tarballs, go download
them from upstream and roll your own LFS.  If we want to offer choices
to users or ourselves in any kind of usable way, then we need to
cooperate in their implementation.  That means listening to everybody,
but ultimately arriving at a decision.

Rich

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[hasufell]

On 07/01/2013 08:37 PM, Chí-Thanh Christopher Nguyễn wrote:
> hasufell schrieb:
>>> They can each have their own ebuild in portage. I do not think that overlays
>>> are the solution here.
>>
>> That idea is so bad I hope we will never see it happen.
> 
> That's what GLEP 39 explictly allows.
> 
>>>> Will that make any1
>>>> reconsider his attitude about being a maintainer and realize that it
>>>> means to serve the _user_?
>>>
>>> No, it means to scratch an itch.
>>
>> I think we will not improve as a distro if we do not redefine our
>> priorities.
>> I have the feeling that our work is not user-centered anymore, but
>> developer-centered and that concept is simply wrong and no sane business
>> manager would ever disagree.
> 
> If you want a user-centric distro which is run by business managers, that
> niche is already occupied. If Gentoo tried to achieve a linear user
> experience, putting uniformity over diversity, then we'd just become a poor
> copy of Ubuntu. Would it increase our user base? Probably. Would it still be
> Gentoo? I'm not sure.
> 
> 

That is wrapping words in my mouth or at least misunderstanding on
purpose. Please read more carefully.

I knew people would jump on that anecdote of business management. I was
not talking about gentoo becoming a business, but about facts based on
experience in the world of (free) software development which tell us to
involve the user in development. That user can very well consist of
specific group we are explicitly targeting, so your other point is wrong
too: I did not talk about widening the userbase by putting "uniformity"
over "diversity". I did not mention any of these words, you said them. I
was talking about _consistency_ (at least on a certain level) and that
does not necessarily conflict with diversity and does not involve
changing our userbase. It does conflict with diversity at those points
where people stop working together and stop discussing issues and just
go their own way either by doing things against our philosophy/policy or
by being stubborn/uncommunicative.
That can happen in numerous ways, especially on those issues which are
definitely worth _global discussion_, such as eclasses, supporting a new
init-system, switching a default implementation, messing with profiles,
with portage, PMS whatever.

Did any1 in those recent discussions ask: do _our users_ actually want
feature x or feature y, implementation foo or bar?
If the answer is yes and it makes sense for us too, then we should not
care about a minority of devs that do not like that course.

Ofc we have our low-level principles that might not change in the
forseeable future, but that does not mean we can ignore what our
community thinks and circumvent conflict resolution by avoiding each
other which is basically what that sounds like.

Bringing up the word "ubuntu" in this dicussion is a really poor thing.

Do you hold the concept of "maintainership" over "common sense"?

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Chí-Thanh Christopher Nguyễn]

hasufell schrieb:
>>> I think we will not improve as a distro if we do not redefine our
>>> priorities.
>>> I have the feeling that our work is not user-centered anymore, but
>>> developer-centered and that concept is simply wrong and no sane business
>>> manager would ever disagree.
>>
>> If you want a user-centric distro which is run by business managers, that
>> niche is already occupied. If Gentoo tried to achieve a linear user
>> experience, putting uniformity over diversity, then we'd just become a poor
>> copy of Ubuntu. Would it increase our user base? Probably. Would it still be
>> Gentoo? I'm not sure.
> 
> That is wrapping words in my mouth or at least misunderstanding on
> purpose. Please read more carefully.

What I got from your statement is that you want to redefine Gentoo
priorities, become more user-centric, and do less things that a business
manager would not approve.
If that is not your position then I take back my above statement.

> Ofc we have our low-level principles that might not change in the
> forseeable future, but that does not mean we can ignore what our
> community thinks and circumvent conflict resolution by avoiding each
> other which is basically what that sounds like.

If conflict resolution actually means impose a change in a package onto the
maintainer against his will, then I am all for circumventing it.

> Bringing up the word "ubuntu" in this dicussion is a really poor thing.

You brought up "business" so I thought I'd return the favor. :)

> Do you hold the concept of "maintainership" over "common sense"?

I feel like I am starting to repeat myself, and possibly we have lost the
others, so unless pressed I am going to add some clarification to my
manifesto rather than making further replies to this thread.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[hasufell]

On 07/01/2013 09:51 PM, Chí-Thanh Christopher Nguyễn wrote:
> become more user-centric

Thanks, it's clear to me now that this is not one of your goals.

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[William Hubbs]

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

Rich,

I think you missed a lot of points I was making.

On Mon, Jul 01, 2013 at 03:21:25PM -0400, Rich Freeman wrote:
> On Mon, Jul 1, 2013 at 3:08 PM, William Hubbs <williamh@gentoo.org> wrote:
> > On Mon, Jul 01, 2013 at 08:37:57PM +0200, Chí-Thanh Christopher Nguyễn wrote:
> >> hasufell schrieb:
> >> >> They can each have their own ebuild in portage. I do not think that overlays
> >> >> are the solution here.
> >> >
> >> > That idea is so bad I hope we will never see it happen.
> >>
> >> That's what GLEP 39 explictly allows.
> >
> > I have to agree on this point. glep 39 allows, and should allow
> > competing projects.
> 
> GLEP 39 ALLOWS me to make a competing apache ebuild, or a competing
> amd64 arch.  It doesn't FORCE me to do so.
> 
> If all I want to do is introduce some optional feature distro-wide
> that doesn't impact anybody who doesn't want to use it (aside from
> trivial numbers of inodes), then I shouldn't HAVE to fork every
> package in the tree to do it.

I am agreeing with you on this. I never said that glep 39 forces you to
do anything.

> I'm a developer because I'm also a user.  Nobody pays me to work on
> ebuilds - I'm scratching my itch.  Nobody is asking maintainers to
> scratch somebody else's itch - they just have to stay out of the way
> when somebody else chooses to do so.

Agreed; this is all about cooperation instead of being territorial.

> > By the nature of being a source based distribution, we can offer a
> > uniform user experience without being a poor copy of any binary
> > distribution, and that uniform user experience could be far more
> > flexable than any binary distribution.
> 
> Absolutely, but that flexibility depends on a certain amount of
> standardization. 

I'm not contesting this. Honestly I'n not quite sure how to respond to
anything else in this message because I agree with you as I said in my
manifesto. I feel like maintainers should cooperate with other
projects/teams/developers.
William

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

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Rich Freeman]

On Mon, Jul 1, 2013 at 6:12 PM, William Hubbs <williamh@gentoo.org> wrote:
> I am agreeing with you on this. I never said that glep 39 forces you to
> do anything.

No worries.  The thread was just going in the direction that GLEP 39
was supposed to endorse total chaos.  I don't mind some level of
creative chaos, but I'm sure that forking ebuilds over the inclusion
of a config file is not what those GLEP authors had in mind.

My reply wasn't directed at you in particular - I just wanted to reply
towards the end of the thread and you quoted all the relevant parts.

Rich

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Donnie Berkholz]

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

On 20:38 Mon 01 Jul     , Chí-Thanh Christopher Nguyễn wrote:
> Rich Freeman schrieb:
> > First, most people aren't going to quit over this.  The maintainer 
> > doesn't have to do anything but not actively revert changes made by 
> > the project teams.
> 
> I don't say that they quit altogether. Just that they may leave that 
> particular ebuild in portage alone (and continue in an overlay as was 
> suggested) because they don't want to have anything to do with the 
> changes that were forced upon them.

I might instead suggest that people own the code they've written, even 
if it's just part of an ebuild. If I run into a Prefix bug in an ebuild, 
I'm going to ask the team that actually knows something about Prefix to 
look into it. Same should hold true for any other code — you add it, you 
accept the responsibility of dealing with it.

It seems to me that there's a couple of issues that really bother people 
here:

- The maintenance burden of any additional code; and
- Overriding a maintainer's decisions on existing code.

My suggestion helps to deal with the former, while I believe Rich has 
made a good point for the latter as part of larger changes that are 
either council-supported or have general consensus. When we voted GLEP 
39 in ourselves (or joined while it existed), we agreed to respect the 
decisions of the leadership and structure we chose.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>

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

Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees)

[Rich Freeman]

On Tue, Jul 2, 2013 at 10:59 AM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
>
> It seems to me that there's a couple of issues that really bother people
> here:
>
> - The maintenance burden of any additional code; and
> - Overriding a maintainer's decisions on existing code.
>
> My suggestion helps to deal with the former, while I believe Rich has
> made a good point for the latter as part of larger changes that are
> either council-supported or have general consensus. When we voted GLEP
> 39 in ourselves (or joined while it existed), we agreed to respect the
> decisions of the leadership and structure we chose.

I don't think most of the recent controversy has been over existing
code, but rather the addition of new code (though a two-line
insinto/doins is stretching the meaning of "code").  However, if a
controversy broke out over existing code I'd feel the same about it -
as long as the changes were sensible and well-supported by a
project/etc I would not want maintainers to block them.

The original question was, "Do you think package forks or
split-packages FOR SINGLE FILES would improve user experience?"
(emphasis mine)

Rich

Re: [gentoo-project] Questions for Candidates (was: Questioning/Interviewing council nominees)

[hasufell]

Well, thanks for all that nonsense, derailing and offtopic crap.

Neither the mailing list mods, nor userrel seem to think some
intervention is necessary.

I was not aware of a gentoo policy that trolls are allowed on our
mailing lists. I apologize for my ignorance.
I hope you will realize some day that this is one of the reasons why
some people unsubscribe from, reroute to trash or just ignore gentoo MLs.

Next time I will definitely choose a different channel for this kind of
thing, if at all.

Re: [gentoo-project] Questions for Candidates (was: Questioning/Interviewing council nominees)

[Rich Freeman]

On Fri, Jul 5, 2013 at 8:08 PM, hasufell <hasufell@gentoo.org> wrote:
> I was not aware of a gentoo policy that trolls are allowed on our
> mailing lists. I apologize for my ignorance.

Is this the thread you intended to post this to?  I don't really see
anything that I'd call trolling here (though I haven't gone back and
re-read all 50+ posts).  Perhaps some was a bit repetitive (I'm as
guilty as any on that count).

I certainly see disagreement here, but nothing I'd call trolling.  As
much as I disagree vigorously with chithanh I do understand where he
is coming from and I know that others agree with him.  He might be
wrong, but being wrong isn't trolling.  :)  (And YES, that was HUMOR!)

Rich

[gentoo-project] Re: [OT] Questions for Candidates (was: Questioning/Interviewing council nominees)

[Tom Wijsman]

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

On Sat, 06 Jul 2013 02:08:41 +0200
hasufell <hasufell@gentoo.org> wrote:

> Well, thanks for all that nonsense, derailing and offtopic crap.

Not sure what part of that thread this is referring to; because you have
accepted a lot of possible topics by asking to "pose a question with
context to the current council election", which scope reaches out to
almost anything Gentoo Developer related in Gentoo Linux.

That open, people will simply discuss what bothers them and want to
see how possibly new Gentoo Council members will deal with that. For
all sub threads; I do not see nonsense, derailing or off-topic crap.

If you instead intended this to be solely Q&A then I think the mailing
lists might not be the right place to do this; sadly it's true, but
sometimes you need the tool you're using to restrict the possible input.

> Neither the mailing list mods, nor userrel seem to think some
> intervention is necessary.

Tried DevRel? Whom invites people to contact them? Nearly all responses
in that thread are from Gentoo Developers, so I don't think UserRel has
anything to do here. I don't see any rules that apply to the ML voided
myself; so, not sure which intervention you are looking for.

As for the ML mods, filtering Council related material makes them biased
so I think they will want to avoid that unless absolutely necessary.

> I was not aware of a gentoo policy that trolls are allowed on our
> mailing lists.

Trolls are defined in the Gentoo CoC, DevRel deals with them.

> I apologize for my ignorance.

No, you need to ignore much more; the average mail client allows you to
ignore sub threads, put that feature to good use and don't be bothered.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Questions for Candidates (was: Questioning/Interviewing council nominees)

[Jorge Manuel B. S. Vicetto]

On Fri, 5 Jul 2013, Rich Freeman wrote:

> On Fri, Jul 5, 2013 at 8:08 PM, hasufell <hasufell@gentoo.org> wrote:
>> I was not aware of a gentoo policy that trolls are allowed on our
>> mailing lists. I apologize for my ignorance.
>
> Is this the thread you intended to post this to?  I don't really see
> anything that I'd call trolling here (though I haven't gone back and
> re-read all 50+ posts).  Perhaps some was a bit repetitive (I'm as
> guilty as any on that count).
>
> I certainly see disagreement here, but nothing I'd call trolling.  As
> much as I disagree vigorously with chithanh I do understand where he
> is coming from and I know that others agree with him.  He might be
> wrong, but being wrong isn't trolling.  :)  (And YES, that was HUMOR!)
>
> Rich

Given Rich's and Tom's reply as well as a lack of supporting emails, 
perhaps now Julian, you may finally accept that my reply to you (userrel's 
reaction), wasn't that "crazy" or "surprising".
For all of those wondering, he's not upset with developer's reactions to 
this thread or the exchange between candidates, but about the 8 or 9 
emails that came from 2 specific users.
Regards,

Jorge Manuel B. S. Vicetto