[gentoo-project] Call for agenda items - Council meeting 2014-04-08

[gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Anthony G. Basile]

Hi everyone,

The council will be meeing on April 8, 2014 at 1900 UTC.  Please bring 
forward any agenda items you would like discussed.

--Tony

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Anthony G. Basile]

On 03/27/2014 09:40 AM, Anthony G. Basile wrote:
> Hi everyone,
>
> The council will be meeing on April 8, 2014 at 1900 UTC.  Please bring
> forward any agenda items you would like discussed.
>
> --Tony
>

Okay I'd like to add an agenda item.  A policy inspired by bug #506034.

Motion: "Significant changes to virtuals are to be discussed (via 
mailing list or bugzilla) with all the maintainers and/or herds which 
maintain packages those virtuals depend on."

Discussion: "Like eclasses, changes to virtuals can affect all the 
packages which depend on them.  Changing existing virtuals, removing 
virtuals or adding new ones affect the packages they depend on.  When 
such a change is proposed, all maintainers affected need to be included 
in the discussion."

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Anthony G. Basile:
> On 03/27/2014 09:40 AM, Anthony G. Basile wrote:
>> Hi everyone,
>> 
>> The council will be meeing on April 8, 2014 at 1900 UTC.  Please
>> bring forward any agenda items you would like discussed.
>> 
>> --Tony
>> 
> 
> Okay I'd like to add an agenda item.  A policy inspired by bug
> #506034.
> 
> Motion: "Significant changes to virtuals are to be discussed (via 
> mailing list or bugzilla) with all the maintainers and/or herds
> which maintain packages those virtuals depend on."
> 
> Discussion: "Like eclasses, changes to virtuals can affect all the 
> packages which depend on them.  Changing existing virtuals,
> removing virtuals or adding new ones affect the packages they
> depend on.  When such a change is proposed, all maintainers
> affected need to be included in the discussion."
> 

Sounds like any other reverse-dep. If people don't discuss non-trivial
changes (to whatever part of gentoo), then that needs to be fixed, not
policies introduced for every single situation that arises.
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTNsofXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgg08QAJz2ZGqjsFxIctK6u1LcMmtN
5jIP7xorHZYFOyWLwHOSzjGakoZj5qbhm2c3BoWh26qtmPOEWXoEEbbTpiyHznyZ
FcoyRhtAV6n7pXqC3Wqkb30gmL2fkxDYpx/8uFzmFAH6Jemhz5usgc82MKTpCznU
91OuSWeVKx0HNNF5jCWBRI7AK8NK+Z1zux/qWyI5ftXl4in4UV8fkJcQFJ/MMzqc
r6GjCEFrr9houf5YBDk2FNBtctVFj0cLxbrgeTyffQbR+TWng2pBW9HohOkSp3ec
XrBumk2LrcBduEfC7ZDZf5B9rsFuN3JlBQd7KsprO7acshoXdTFpjhGxC8BPBF0p
9p8dOp6wWDafZprUT5CW2HD1EiuMxSLTEn4bszyvgRzdA90yOkUBGagXTSeasdnl
B8T5dpjx4/idA14DnCI8Dd6Zt639qYG7waPpsRZpJdrX/KKHDagtEE1ouk+rJL/W
jSKQyHJWzyE1UUYmVF0JAH+PiOBYIF1RW+LXZoKGvKi05poY2hruA5sQxZ3JUNR6
6QMnsB6+If9yKe+Q6oSrk/UpFJSJUlHt509sfXYhGmnHCQ2G2ZVZ5/tT15MhimoM
HIf8NU7F55cwQQT/3nBzv3XNw1VRgvg5Y7PR3BARAEPAcdgSQ87HCbWBU1zNzgXM
xC5lVxSwUEGUShgRF5n8
=5FI0
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Anthony G. Basile]

On 03/29/2014 09:26 AM, hasufell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Anthony G. Basile:
>> On 03/27/2014 09:40 AM, Anthony G. Basile wrote:
>>> Hi everyone,
>>>
>>> The council will be meeing on April 8, 2014 at 1900 UTC.  Please
>>> bring forward any agenda items you would like discussed.
>>>
>>> --Tony
>>>
>> Okay I'd like to add an agenda item.  A policy inspired by bug
>> #506034.
>>
>> Motion: "Significant changes to virtuals are to be discussed (via
>> mailing list or bugzilla) with all the maintainers and/or herds
>> which maintain packages those virtuals depend on."
>>
>> Discussion: "Like eclasses, changes to virtuals can affect all the
>> packages which depend on them.  Changing existing virtuals,
>> removing virtuals or adding new ones affect the packages they
>> depend on.  When such a change is proposed, all maintainers
>> affected need to be included in the discussion."
>>
> Sounds like any other reverse-dep. If people don't discuss non-trivial
> changes (to whatever part of gentoo), then that needs to be fixed, not
> policies introduced for every single situation that arises.

True, I did think of that, but we do have a policy for eclasses. With 
deeper uses of virtuals, it does not hurt to make the reverse-dep issue 
explicit.

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Anthony G. Basile:
> On 03/29/2014 09:26 AM, hasufell wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>> 
>> Anthony G. Basile:
>>> On 03/27/2014 09:40 AM, Anthony G. Basile wrote:
>>>> Hi everyone,
>>>> 
>>>> The council will be meeing on April 8, 2014 at 1900 UTC.
>>>> Please bring forward any agenda items you would like
>>>> discussed.
>>>> 
>>>> --Tony
>>>> 
>>> Okay I'd like to add an agenda item.  A policy inspired by bug 
>>> #506034.
>>> 
>>> Motion: "Significant changes to virtuals are to be discussed
>>> (via mailing list or bugzilla) with all the maintainers and/or
>>> herds which maintain packages those virtuals depend on."
>>> 
>>> Discussion: "Like eclasses, changes to virtuals can affect all
>>> the packages which depend on them.  Changing existing
>>> virtuals, removing virtuals or adding new ones affect the
>>> packages they depend on.  When such a change is proposed, all
>>> maintainers affected need to be included in the discussion."
>>> 
>> Sounds like any other reverse-dep. If people don't discuss
>> non-trivial changes (to whatever part of gentoo), then that needs
>> to be fixed, not policies introduced for every single situation
>> that arises.
> 
> True, I did think of that, but we do have a policy for eclasses.
> With deeper uses of virtuals, it does not hurt to make the
> reverse-dep issue explicit.
> 

IMO, eclasses are special since they are not really versioned.
Virtuals are regular packages, versioned and with stable and unstable
keywords.

Unless you really want to apply this policy on _all_ reverse deps.

And if people don't follow it, then what? There have been a hundred
situations (including eclasses) that were sufficient to say "stop" to
some people who regularly do undiscussed, non-trivial changes. Until
now, not much has happened about it. I doubt that this policy will
change any of that.

[sarcasm]
But it gives us an impression of progress, at least... and policies
seem to be a trend lately.
[/sarcasm]
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTNs9uXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgIgIQAORJXH05DUeASzBMKwOkCitN
uTJZDy1riMwnjSDKgFanm8QBGIN7fFDpaj2bB/NOwslrJsQ1t++Zfgz+YHoUOIxU
ARK0O1yLCqESEX8PBUkSXdx2THRZbZpRiFtZ++Y3tuggHsBd4/AFe1zz5ZDUFE+C
ZkMqaXWA60K8rWWFn3i6Rs98KG7VRu1jU5cQ0SQyaW+I0MS1wQ78jo779Hwa/h11
hGRHC0Ojxch+1sVm7YupPtHEY7XAGu5KTzM0AefqzzRl4qYyB7DKrWJ1J05eZmja
/A65ViKwf7mb8aMm4tQvQXqtQ4zSvxL6FbU0mvfybwlNgckdl7wHtu52Dqe9/EU9
bc8Lh8AaVydctjTY3duzJGON7467BlP/bmprA/gunRA1EGJuc7M2oSzEtMXjEbZC
2yPqdrCBQHDGBJvf1HnwZWrBAiWXS0BnD8MPL9fk37GL5wSTbF4rHP+KYa0P+H5U
OvEtHuRLILojiPKQtcUyD3hKFKvSo6QeGoFUamhGi9sHS55EzctGlNv6i4GACUQr
6yyPBBEbnvyYum8F+p0ip+R2Q/ZTnnTb/xQKQvgXehm6ml2eq6IQ2XuFwAYmn6GQ
8au6O2pY4L+CLG/U0AfzFYwWcpWTIoAlXMMy+tut5t1MS9tc1ZFqunDTIYc5uvPF
+imie0+8yeQizwx+KTbJ
=J8nI
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Anthony G. Basile]

On 03/29/2014 09:49 AM, hasufell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Anthony G. Basile:
>> On 03/29/2014 09:26 AM, hasufell wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>>>
>>> Anthony G. Basile:
>>>> On 03/27/2014 09:40 AM, Anthony G. Basile wrote:
>>>>> Hi everyone,
>>>>>
>>>>> The council will be meeing on April 8, 2014 at 1900 UTC.
>>>>> Please bring forward any agenda items you would like
>>>>> discussed.
>>>>>
>>>>> --Tony
>>>>>
>>>> Okay I'd like to add an agenda item.  A policy inspired by bug
>>>> #506034.
>>>>
>>>> Motion: "Significant changes to virtuals are to be discussed
>>>> (via mailing list or bugzilla) with all the maintainers and/or
>>>> herds which maintain packages those virtuals depend on."
>>>>
>>>> Discussion: "Like eclasses, changes to virtuals can affect all
>>>> the packages which depend on them.  Changing existing
>>>> virtuals, removing virtuals or adding new ones affect the
>>>> packages they depend on.  When such a change is proposed, all
>>>> maintainers affected need to be included in the discussion."
>>>>
>>> Sounds like any other reverse-dep. If people don't discuss
>>> non-trivial changes (to whatever part of gentoo), then that needs
>>> to be fixed, not policies introduced for every single situation
>>> that arises.
>>
>> True, I did think of that, but we do have a policy for eclasses.
>> With deeper uses of virtuals, it does not hurt to make the
>> reverse-dep issue explicit.
>>
>
> IMO, eclasses are special since they are not really versioned.
> Virtuals are regular packages, versioned and with stable and unstable
> keywords.

And yet we do have many such policies beyond eclasses.  For example, in 
profiles/base/make.conf we have:

# Env vars to expand into USE vars.  Modifying this requires prior
# discussion on gentoo-dev@gentoo.org.
USE_EXPAND=

There is precedence withing Gentoo for asking that far reaching design 
changes (eg USE_EXPAND) be discussed on the list.

>
> Unless you really want to apply this policy on _all_ reverse deps.

It is difficult to enumerate _all_.  I believe Tom and I have identified 
two more areas were we should encourage list wide discussion when the 
consequences by affect others: virtuals and profiles.

>
> And if people don't follow it, then what? There have been a hundred
> situations (including eclasses) that were sufficient to say "stop" to
> some people who regularly do undiscussed, non-trivial changes. Until
> now, not much has happened about it. I doubt that this policy will
> change any of that.

If nothing else it raises awareness that we are a community where our 
changes affect one another.  The "enforcement" I would hope for is the 
respect that we show one another.

>
> [sarcasm]
> But it gives us an impression of progress, at least... and policies
> seem to be a trend lately.
> [/sarcasm]


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Sat, 29 Mar 2014 08:50:36 -0400
"Anthony G. Basile" <basile@opensource.dyc.edu> wrote:

> Okay I'd like to add an agenda item.  A policy inspired by bug
> #506034.

(PS: Bug #506114 could be relevant to your item)

Same here, let's take this a step further and extend this to profiles.
A policy inspired by bug #435094 and bug #506142.

> Motion: "Significant changes to virtuals are to be discussed (via 
> mailing list or bugzilla) with all the maintainers and/or herds which 
> maintain packages those virtuals depend on."

Motion: "Significant changes to profiles are to be discussed (via
mailing list or bugzilla) with all the maintainers and/or herds that
rely on what gets changed in the profiles." 

> Discussion: "Like eclasses, changes to virtuals can affect all the 
> packages which depend on them.  Changing existing virtuals, removing 
> virtuals or adding new ones affect the packages they depend on.  When 
> such a change is proposed, all maintainers affected need to be
> included in the discussion."

Discussion: "Like eclasses and virtuals, changes to the profiles affect
a set of packages at once. For instance, adding or removing a mask or
force can result in something becoming forced or optional. If something
is assumed to be forced, or optional; it can result in breakage, we
would like to prevent huge breakage. When such change is proposed, all
maintainers affected need to be included in the discussion."

Concern: "Unawareness, possible breakage and a lack of cooperation."

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Anthony G. Basile]

On 03/29/2014 09:30 AM, Tom Wijsman wrote:
> On Sat, 29 Mar 2014 08:50:36 -0400
> "Anthony G. Basile" <basile@opensource.dyc.edu> wrote:
>
>> Okay I'd like to add an agenda item.  A policy inspired by bug
>> #506034.
>
> (PS: Bug #506114 could be relevant to your item)
>
> Same here, let's take this a step further and extend this to profiles.
> A policy inspired by bug #435094 and bug #506142.
>
>> Motion: "Significant changes to virtuals are to be discussed (via
>> mailing list or bugzilla) with all the maintainers and/or herds which
>> maintain packages those virtuals depend on."
>
> Motion: "Significant changes to profiles are to be discussed (via
> mailing list or bugzilla) with all the maintainers and/or herds that
> rely on what gets changed in the profiles."
>
>> Discussion: "Like eclasses, changes to virtuals can affect all the
>> packages which depend on them.  Changing existing virtuals, removing
>> virtuals or adding new ones affect the packages they depend on.  When
>> such a change is proposed, all maintainers affected need to be
>> included in the discussion."
>
> Discussion: "Like eclasses and virtuals, changes to the profiles affect
> a set of packages at once. For instance, adding or removing a mask or
> force can result in something becoming forced or optional. If something
> is assumed to be forced, or optional; it can result in breakage, we
> would like to prevent huge breakage. When such change is proposed, all
> maintainers affected need to be included in the discussion."
>
> Concern: "Unawareness, possible breakage and a lack of cooperation."
>


Tom, I agree.  This does seem like a good idea.  An example here are 
some of the ABI variables that were introduced.  I maintain some 
profiles which stack differently than default/linux/amd64/13.0 and 
getting a heads up about changes in the layers of the default profiles 
would have helped.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[William Hubbs]

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

On Sat, Mar 29, 2014 at 10:07:02AM -0400, Anthony G. Basile wrote:
> On 03/29/2014 09:30 AM, Tom Wijsman wrote:
> > On Sat, 29 Mar 2014 08:50:36 -0400
> > "Anthony G. Basile" <basile@opensource.dyc.edu> wrote:
> >
> >> Okay I'd like to add an agenda item.  A policy inspired by bug
> >> #506034.
> >
> > (PS: Bug #506114 could be relevant to your item)
> >
> > Same here, let's take this a step further and extend this to profiles.
> > A policy inspired by bug #435094 and bug #506142.
> >
> >> Motion: "Significant changes to virtuals are to be discussed (via
> >> mailing list or bugzilla) with all the maintainers and/or herds which
> >> maintain packages those virtuals depend on."
> >
> > Motion: "Significant changes to profiles are to be discussed (via
> > mailing list or bugzilla) with all the maintainers and/or herds that
> > rely on what gets changed in the profiles."
> >
> >> Discussion: "Like eclasses, changes to virtuals can affect all the
> >> packages which depend on them.  Changing existing virtuals, removing
> >> virtuals or adding new ones affect the packages they depend on.  When
> >> such a change is proposed, all maintainers affected need to be
> >> included in the discussion."
> >
> > Discussion: "Like eclasses and virtuals, changes to the profiles affect
> > a set of packages at once. For instance, adding or removing a mask or
> > force can result in something becoming forced or optional. If something
> > is assumed to be forced, or optional; it can result in breakage, we
> > would like to prevent huge breakage. When such change is proposed, all
> > maintainers affected need to be included in the discussion."
> >
> > Concern: "Unawareness, possible breakage and a lack of cooperation."
> >
> 
> 
> Tom, I agree.  This does seem like a good idea.  An example here are 
> some of the ABI variables that were introduced.  I maintain some 
> profiles which stack differently than default/linux/amd64/13.0 and 
> getting a heads up about changes in the layers of the default profiles 
> would have helped.

I understand the concerns, but I am with hasufell on both of these.

We are supposed to be a team, and if a few people aren't team players,
I would rather see energy spent on fixing that issue instead of trying
to legislate every possible corner case.

William


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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sat, Mar 29, 2014 at 10:36 AM, William Hubbs <williamh@gentoo.org> wrote:
>
> We are supposed to be a team, and if a few people aren't team players,
> I would rather see energy spent on fixing that issue instead of trying
> to legislate every possible corner case.

So, a few thoughts on the whole issue in general.

1.  When somebody wants to do something in a way completely different
from how things have been done before or in a way that impacts how
many packages will be maintained, it is best to discuss it on the
lists first.  That doesn't mean that you can't proceed without
unanimous consent, but rather that even good ideas can become better
ideas with more input.  That said, when an issue comes up those who
object need to at least speak up ahead of time, because after-the-fact
isn't the time for I-told-you-so.  That has come up a few times lately
- you don't need to have the last reply on the thread to win the
argument, but that doesn't mean that you shouldn't speak up at all.

2.  When there is a change in the tree that threatens to be disruptive
to users/dev/etc QA has the right to step in.  The necessity of doing
this should really be considered first - if simply saying "hold on,
don't do any more of this for a few days" is sufficient to get by,
that should be preferred over masks/bans/etc.  On the other hand, if
users are being adversely affected by something and this will get
worse with time, it is better to stop the bleeding.  Think of it like
asking a court for an emergency stay/injunction/etc - courts generally
prefer to hear the whole case before taking action, but if there is
some kind of irreversible harm at stake, they'll act first and sort it
out later.  Obviously QA should manage its own guidelines as to when
individuals should act in the name of QA.

3.  In general the absence of an explicit policy should never be
considered grounds for ignoring #1 or preventing #2.  The real
principle is cooperation and managing disruptive change.  QA can step
in even if you can't quote a specific rule that was broken (though
they should be careful before doing so), and I really don't want to
hear excuses like "well, there was no rule saying I had to play nicely
with the other kids."  We really don't want to have to maintain the
Code of Gentoo Regulations.

So, I'd certainly endorse that things like profile changes, eclass
changes, and changes that impact many reverse-deps should be announced
on the list and coordinated in general if they aren't routine.  That
said, I don't see the need to codify this in some kind of explicit
policy - I'd argue that it already is policy.  I don't want to get
into back-and-forth on how to word a policy so that a dev masking
their own package is fine but a dev removing bash from the system set
isn't.  If somebody can't tell the difference between these, they
shouldn't have commit access.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 765 bytes --]

Am Samstag, 29. März 2014, 15:36:34 schrieb William Hubbs:
> On Sat, Mar 29, 2014 at 10:07:02AM -0400, Anthony G. Basile wrote:

> 
> I understand the concerns, but I am with hasufell on both of these.
> 
> We are supposed to be a team, and if a few people aren't team players,
> I would rather see energy spent on fixing that issue instead of trying
> to legislate every possible corner case.
> 

Full agreement. We already have way too many specialized policies. 

The actual problem is that some people dont feel like talking to others. I'd 
tend to call it lack of respect, either for individuals or for the rules that 
make up a community.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[William Hubbs]

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

On Sun, Mar 30, 2014 at 12:12:49AM +0100, Andreas K. Huettel wrote:
> Full agreement. We already have way too many specialized policies. 
> 
> The actual problem is that some people dont feel like talking to others. I'd 
> tend to call it lack of respect, either for individuals or for the rules that 
> make up a community.

Full agreement.

Some how we need to focus on getting people to respect each other and
the policies we already have, and quite frankly, if they won't do that,
removing them from the community.

William


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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sat, Mar 29, 2014 at 8:37 PM, William Hubbs <williamh@gentoo.org> wrote:
> Some how we need to focus on getting people to respect each other and
> the policies we already have, and quite frankly, if they won't do that,
> removing them from the community.

Alas, we cannot afford to drive people away any more than we can
afford to let them drive others away...

I really wish that devs would get over their differences and just talk
about their ideas.  You don't need anybody's "permission" to do many
things around here.  That doesn't mean that it isn't nice (and more
importantly wise) to at least ask for some feedback before striking
off on your own.

The only clean solution is for all of us to grow up a little more...

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[William Hubbs]

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

On Sat, Mar 29, 2014 at 09:35:32PM -0400, Rich Freeman wrote:
> On Sat, Mar 29, 2014 at 8:37 PM, William Hubbs <williamh@gentoo.org> wrote:
> > Some how we need to focus on getting people to respect each other and
> > the policies we already have, and quite frankly, if they won't do that,
> > removing them from the community.
> 
> Alas, we cannot afford to drive people away any more than we can
> afford to let them drive others away...
> 
> I really wish that devs would get over their differences and just talk
> about their ideas.  You don't need anybody's "permission" to do many
> things around here.  That doesn't mean that it isn't nice (and more
> importantly wise) to at least ask for some feedback before striking
> off on your own.
> 
> The only clean solution is for all of us to grow up a little more...

Rich and all,

I appologise if I came off harsh in my last email; that really wasn't the
point. It was just frustration coming through.

Rich,

I agree, I'm just not sure how to make that happen. I don't think though
that the answer is more policies/red tape.

William



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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sat, Mar 29, 2014 at 10:20 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Sat, Mar 29, 2014 at 09:35:32PM -0400, Rich Freeman wrote:
>> On Sat, Mar 29, 2014 at 8:37 PM, William Hubbs <williamh@gentoo.org> wrote:
>> > Some how we need to focus on getting people to respect each other and
>> > the policies we already have, and quite frankly, if they won't do that,
>> > removing them from the community.
>>
>> Alas, we cannot afford to drive people away any more than we can
>> afford to let them drive others away...
>
> I agree, I'm just not sure how to make that happen. I don't think though
> that the answer is more policies/red tape.

And neither is ignoring the problem.

I was just venting my frustration, as are many others.  I think that
this is just a really great idea that suffered because of how it was
implemented, and all the subsequent reactions and counter-reactions.
We need to move on, and I think all of us can learn something from
what happened.

I think your posts were right-on.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Anthony G. Basile]

On 03/29/2014 10:33 PM, Rich Freeman wrote:
> On Sat, Mar 29, 2014 at 10:20 PM, William Hubbs <williamh@gentoo.org> wrote:
>> On Sat, Mar 29, 2014 at 09:35:32PM -0400, Rich Freeman wrote:
>>> On Sat, Mar 29, 2014 at 8:37 PM, William Hubbs <williamh@gentoo.org> wrote:
>>>> Some how we need to focus on getting people to respect each other and
>>>> the policies we already have, and quite frankly, if they won't do that,
>>>> removing them from the community.
>>> Alas, we cannot afford to drive people away any more than we can
>>> afford to let them drive others away...
>> I agree, I'm just not sure how to make that happen. I don't think though
>> that the answer is more policies/red tape.
> And neither is ignoring the problem.
>
> I was just venting my frustration, as are many others.  I think that
> this is just a really great idea that suffered because of how it was
> implemented, and all the subsequent reactions and counter-reactions.
> We need to move on, and I think all of us can learn something from
> what happened.
>
> I think your posts were right-on.
>
> Rich
>

While implementing a new policy may not be the right approach (or so I'm 
hearing from the community), I can bring forward at least 3 examples of 
significant changes that were not discussed.  I don't think I would have 
difficulty convincing people of this fact.  If we do not enact policy 
then how is this problem addressed?

As far as "driving people away" I will shift my efforts to recruiting.  
I am a professor and can get more students into Gentoo development.  We 
cannot adopt a de facto situation where devs can misbehave because they 
are indispensable.

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Sun, 30 Mar 2014 07:00:42 -0400
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> While implementing a new policy may not be the right approach (or so
> I'm hearing from the community), I can bring forward at least 3
> examples of significant changes that were not discussed.  I don't
> think I would have difficulty convincing people of this fact.  If we
> do not enact policy then how is this problem addressed?
> 
> As far as "driving people away" I will shift my efforts to
> recruiting. I am a professor and can get more students into Gentoo
> development.  We cannot adopt a de facto situation where devs can
> misbehave because they are indispensable.

Had a whole conversation with WilliamH about this; my viewpoint after
that conversation has changed, it isn't anymore to just go for the
policy, but it boils down that there are multiple options to pick from:

    1) you fix it on the technical level, by introducing policy;

    2) you fix it on the personal level, by improving relations;

    3) you do nothing, letting people burn out in personal quibblings.

Maybe more options exist, I dunno.

Each option then has its advantages and disadvantages, a pick:

    1) Advantage: You prevent the concerns altogether. You get useful
       feedback on what you're planning to commit.

       Disadvantage: The loudest people can stall progress. People who
       disagree speak more than people than acknowledge it, even if
       there is a fifty-fifty situation it's hard to tell how to
       proceed; that leads to less progress than without discussion.

    2) Advantage: Improved communication.

       Disadvantage: You'll need to be though to get people to improve;
       as Anthony highlights, people currently are indispensable. The
       way to fix that is get more people, if you can get more people.

    3) Advantage: People learn through burning out to work together;
       because well, reverting and/or whatsoever yields no progress.

       Disadvantage: A personal quibbling every week or so. Mood drops.

There are other (dis)advantage to these things; but I'm just saying,
whatever solution we pick, we must be well aware of the goal as well a
the consequence of that solution. And there's no way to pick no
solution; because doing so, you'll pick the current (3) by default.

That being said, these things come up due to a series of minor events
over the last week; they all turn out to not be huge breakage,
however ... what if one day someone commits something much worse?

We do our best to mitigate the situation in that case; however, I hope
that these cases don't become the habit, but rather the exception.

So far, we've been doing fine though; but seeing that some things get
committed where unintended side effects happen, it is still a worry.

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Anthony G. Basile]

On 03/30/2014 07:22 AM, Tom Wijsman wrote:
> On Sun, 30 Mar 2014 07:00:42 -0400
> "Anthony G. Basile" <blueness@gentoo.org> wrote:
>
>> While implementing a new policy may not be the right approach (or so
>> I'm hearing from the community), I can bring forward at least 3
>> examples of significant changes that were not discussed.  I don't
>> think I would have difficulty convincing people of this fact.  If we
>> do not enact policy then how is this problem addressed?
>>
>> As far as "driving people away" I will shift my efforts to
>> recruiting. I am a professor and can get more students into Gentoo
>> development.  We cannot adopt a de facto situation where devs can
>> misbehave because they are indispensable.
> Had a whole conversation with WilliamH about this; my viewpoint after
> that conversation has changed, it isn't anymore to just go for the
> policy, but it boils down that there are multiple options to pick from:
>
>      1) you fix it on the technical level, by introducing policy;
>
>      2) you fix it on the personal level, by improving relations;
>
>      3) you do nothing, letting people burn out in personal quibblings.
>
> Maybe more options exist, I dunno.
>
> Each option then has its advantages and disadvantages, a pick:
>
>      1) Advantage: You prevent the concerns altogether. You get useful
>         feedback on what you're planning to commit.
>
>         Disadvantage: The loudest people can stall progress. People who
>         disagree speak more than people than acknowledge it, even if
>         there is a fifty-fifty situation it's hard to tell how to
>         proceed; that leads to less progress than without discussion.
>
>      2) Advantage: Improved communication.
>
>         Disadvantage: You'll need to be though to get people to improve;
>         as Anthony highlights, people currently are indispensable. The
>         way to fix that is get more people, if you can get more people.
>
>      3) Advantage: People learn through burning out to work together;
>         because well, reverting and/or whatsoever yields no progress.
>
>         Disadvantage: A personal quibbling every week or so. Mood drops.
>
> There are other (dis)advantage to these things; but I'm just saying,
> whatever solution we pick, we must be well aware of the goal as well a
> the consequence of that solution. And there's no way to pick no
> solution; because doing so, you'll pick the current (3) by default.
>
> That being said, these things come up due to a series of minor events
> over the last week; they all turn out to not be huge breakage,
> however ... what if one day someone commits something much worse?
>
> We do our best to mitigate the situation in that case; however, I hope
> that these cases don't become the habit, but rather the exception.
>
> So far, we've been doing fine though; but seeing that some things get
> committed where unintended side effects happen, it is still a worry.
>

No there is another issue: you don't get good design in isolation. At 
least one of the issues that was not discussed until too late has a 
design flaw.  The same arrogance that leads people to think "I know what 
I'm doing" leads people to think "I don't need to discuss this with others".

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Sun, 30 Mar 2014 07:32:42 -0400
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> No there is another issue: you don't get good design in isolation. At 
> least one of the issues that was not discussed until too late has a 
> design flaw.  The same arrogance that leads people to think "I know
> what I'm doing" leads people to think "I don't need to discuss this
> with others".

+1 Progress might not be good progress; good design is good progress.

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sun, Mar 30, 2014 at 7:00 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
> While implementing a new policy may not be the right approach (or so I'm
> hearing from the community), I can bring forward at least 3 examples of
> significant changes that were not discussed.  I don't think I would have
> difficulty convincing people of this fact.  If we do not enact policy then
> how is this problem addressed?

I should clarify my meaning.

I don't think we need to enact a specific virtual/profile/etc policy
because I think it should ALREADY be treated as policy.  At most we
should be clarifying that we already consider it policy.  To the
extent that we create new policy it should be much more open-ended,
like "consult the list when making major design changes that impact
many packages/users" or something like that.

However, either creating/clarifying policy, or pointing out that
something already is policy will not do anything if people don't
follow it.

I also was not suggesting that we should not enforce policy - only
that doing so is tragic.  I do think that allowing productive
developers to just ignore the rules is more harmful than stepping in.

I will make the general statement that if people have a problem with
QA outright defiance is something that should almost certainly lead to
a ban of some kind.  There are many ways to handle perceived abuse of
QA power, and that is probably the worst possible.  No need to just
sit on your hands until the next council meeting - complain privately
to council, or publicly to council, or go to comrel (who will probably
just end up arbitrating or handing off to council) but don't
unilaterally get into a revert war with QA!  When you do, you
immediately change priority #1 from fixing the situation to fixing
you.  Don't just assume that QA won't back down or the Council won't
step in after just a bit of reasoning.

On the other hand, these are people issues, and when a need for
enforcement comes up somebody should at least take the time to chat
with the individual concerned and try to explain/connect/etc, and get
the full story before taking action.  They shouldn't just get an email
saying "the Council just met and FYI your commit access is revoked for
two weeks, have a nice day."  Somebody should be responsible to reach
out to them and be a contact through the experience.  Some may
ragequit and be lost all the same, but really the goal is to try to
teach a lesson and some kind of mentoring will help with that, and
perhaps give the affected individual someplace to vent the next time a
problem comes up.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Rich Freeman:
> On Sat, Mar 29, 2014 at 8:37 PM, William Hubbs <williamh@gentoo.org> wrote:
>> Some how we need to focus on getting people to respect each other and
>> the policies we already have, and quite frankly, if they won't do that,
>> removing them from the community.
> 
> Alas, we cannot afford to drive people away any more than we can
> afford to let them drive others away...
> 
> I really wish that devs would get over their differences and just talk
> about their ideas.  You don't need anybody's "permission" to do many
> things around here.  That doesn't mean that it isn't nice (and more
> importantly wise) to at least ask for some feedback before striking
> off on your own.
> 
> The only clean solution is for all of us to grow up a little more...
> 
> Rich
> 

That is not going to happen and is not really a solution. Also, by
trying to not drive people away, we already drive others away (I very
well remember the last few "I will retire" threads).

In the end it seems to me that old-timers regularly win that
"contest". It's not the same thing to temporarily remove commit access
of someone who has been working on gentoo for 5+ years and is lead of
several projects, compared to someone who just got in here 5 months ago.

Let's face it. It will never improve. We can just try to live with it
and that's what most people do.

And I am specifically talking about people who don't follow a
methodology of talking stuff through before doing it... not gentoo
culture in general. And I am also not talking about casual oversight,
but about behavioral pattern.
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTOAyRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAg5FcP/REoH+lveBIcw6ViZtY74pJh
V+pxGHUlmrEWuG+ZU3UBjiUw0IJ1GNdihHVsxL6Uaeo2VMala9UPystxQ7BHxw4e
6oWoDdG0Wk1zY5spJvXPBaeZTxM1RBVm72LY8NMF9axi/8GWISa6TsYS14GF27MY
TVdlvBPQfdWDr+It2BqvyQfjudK+SW/BGF8Oyi8A63K6rjMa+ZY63lwKo4J8SqaP
YYAA0NVb+kgw+b/UsBRTbIivWJQP4GngKaUZmD9y8DLGzE2WJ30Q1+9AVINUmA+5
4fVJJpTNJ+a2BUVZbv1Y6WPE6KpOsgL7egxRp+DK4zrnp3gAq9RIKfUEbMw0nubW
s1UHSA7cB82sVcgPS/j1aSH3mrlpmXC6aQC03Cb1nCUmQVMgxIZyVZCiYvOownO+
JVTen3V4IL9K1qa0FmqlyWioJ0QPkfN+8SYVnWxcsj9WdAM7DUMWaRCAhhvdejUE
oFniV27yXq2r1mqYgvaD/twy8sK4b/2QXeoQUm1Z7xHt8AggRtr6XtFFXMisJh+t
vSdbY2nG/BbWtYEllR851s4JX4EQXJKRSPjFbtvfYyTzzWfiJiyqVz9aqm1etta4
8YTZB4xUpXrGUtCMMEm7CTTbsosPm+20/yn67fKglLyd2RVo//Iyni1nNqSxrIBY
X1JrtdoyVB+uLP6t/vn/
=4zEI
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1081 bytes --]

Am Sonntag, 30. März 2014, 14:22:41 schrieb hasufell:
> 
> That is not going to happen and is not really a solution. Also, by
> trying to not drive people away, we already drive others away (I very
> well remember the last few "I will retire" threads).
> 
> In the end it seems to me that old-timers regularly win that
> "contest". It's not the same thing to temporarily remove commit access
> of someone who has been working on gentoo for 5+ years and is lead of
> several projects, compared to someone who just got in here 5 months ago.
> 
> Let's face it. It will never improve. We can just try to live with it
> and that's what most people do.
> 
> And I am specifically talking about people who don't follow a
> methodology of talking stuff through before doing it... not gentoo
> culture in general. And I am also not talking about casual oversight,
> but about behavioral pattern.

+1 Insightful.
(Though I'm still a bit more optimistic.)

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Samuli Suominen]

On 30/03/14 04:35, Rich Freeman wrote:
> On Sat, Mar 29, 2014 at 8:37 PM, William Hubbs <williamh@gentoo.org> wrote:
>> Some how we need to focus on getting people to respect each other and
>> the policies we already have, and quite frankly, if they won't do that,
>> removing them from the community.
> Alas, we cannot afford to drive people away any more than we can
> afford to let them drive others away...
>
> I really wish that devs would get over their differences and just talk
> about their ideas.  You don't need anybody's "permission" to do many
> things around here.  That doesn't mean that it isn't nice (and more
> importantly wise) to at least ask for some feedback before striking
> off on your own.

The problem here is that 'to at least ask for some feedback' seems to
mean 'it must
be discussed on the gentoo-dev ML' for some people, even if the feedback
required
has already been given elsewhere by good number of developers (like IRC)

- Samuli

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Patrick Lauer]

On 04/01/2014 12:00 AM, Samuli Suominen wrote:
>>
>> I really wish that devs would get over their differences and just talk
>> about their ideas.  You don't need anybody's "permission" to do many
>> things around here.  That doesn't mean that it isn't nice (and more
>> importantly wise) to at least ask for some feedback before striking
>> off on your own.
> 
> The problem here is that 'to at least ask for some feedback' seems to
> mean 'it must
> be discussed on the gentoo-dev ML' for some people, even if the feedback
> required
> has already been given elsewhere by good number of developers (like IRC)
> 
> - Samuli
> 

The advantage of persistent and common channels is that other people are
informed and it's archived.

A discussion you had somewhere else, as far as I (and surely others) are
concerned, didn't happen. You can't reference it in the future because
it's not archived, and people will be upset because you actively worked
around the established communication paths to avoid them.

Sooo ... just drop a message here of what you intend to do, with a short
rationale maybe, and then there'll be less people being upset because
you don't communicate (in the right channels)

Merci,

Patrick

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Michał Górny]

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

Dnia 2014-03-27, o godz. 09:40:47
"Anthony G. Basile" <blueness@gentoo.org> napisał(a):

> The council will be meeing on April 8, 2014 at 1900 UTC.  Please bring 
> forward any agenda items you would like discussed.

Before we get into another revert war from patrick, I'd like to raise
the following item:

- use of ISO/IEC binary prefixes vs ambiguous 'mega' prefixes

Quick explanation:

ISO/IEC prefixes [1,2]: KiB (kibibyte), MiB (mebi-), GiB (gibi-)
  -- unambiguously 2^10, 2^20, 2^30

'old' prefixes: kB (kilobyte), MB (mega-), GB (giga-)
  -- can mean 10^3 or 2^10 etc. depending on author's intention
  -- SI people tend to use 10^N for consistency with other units

Major FLOSS projects have already started using binary prefixes:
the Linux kernel and GNU coreutils (e.g. df). They are used in e.g.
pacman as well, and I've submitted patches for portage already.

2.5yr ago scarabeus had updated check-reqs.eclass to use binary
prefixes [3] after a mailing list discussion. 1.5yr ago patrick changed
units back [4] without any discussion. Yesterday ulm (not knowing of
earlier revert) noticed the wrong names and fixed them again [5]. Today
patrick threatened already that he's going to revert the change.

Therefore, I'd like to have this discussed and voted through by Council
so that we could have a single front rather than a single developer
reverting changes randomly.

[1]:http://www.iec.ch/si/binary.htm
[2]:http://physics.nist.gov/cuu/Units/binary.html
[3]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/check-reqs.eclass?r1=1.8&r2=1.9
[4]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/check-reqs.eclass?r1=1.12&r2=1.13
[5]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/check-reqs.eclass?r1=1.13&r2=1.14

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Patrick Lauer]

On Sunday 30 March 2014 10:33:42 Michał Górny wrote:
> Dnia 2014-03-27, o godz. 09:40:47
> 
> "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
> > The council will be meeing on April 8, 2014 at 1900 UTC.  Please bring
> > forward any agenda items you would like discussed.
> 
> Before we get into another revert war from patrick, I'd like to raise
> the following item:
> 
> - use of ISO/IEC binary prefixes vs ambiguous 'mega' prefixes
> 
> Quick explanation:
> 
> ISO/IEC prefixes [1,2]: KiB (kibibyte), MiB (mebi-), GiB (gibi-)
>   -- unambiguously 2^10, 2^20, 2^30
> 
> 'old' prefixes: kB (kilobyte), MB (mega-), GB (giga-)
>   -- can mean 10^3 or 2^10 etc. depending on author's intention
>   -- SI people tend to use 10^N for consistency with other units
> 

base-10 bytes make no sense.

A "3TB" disk has 2.7TB actual capacity since it's three trillion bytes, and 
not something that makes sense in a base-2 world. 

It'd be a lot easier to ignore the marketingbytes used for storage and 
consistently use bits and bytes in base-2 ... (which is the natural way for 
bits to end up as they are inherently binary)

... but it looks like people prefer inventing some horribad wordenings like 
maybebytes to avoid this confusion.

I strongly recommend not using base-10 bytes or inventing new words to work 
around the ambiguity created by stupid people, and I hope I don't have to 
tolerate having a three trellobyte disk. 'cause that would be very sad. And 
then I'd have to complain every single time I see that stupidity printed out.

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Michał Górny]

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

Dnia 2014-03-30, o godz. 16:43:20
Patrick Lauer <patrick@gentoo.org> napisał(a):

> On Sunday 30 March 2014 10:33:42 Michał Górny wrote:
> > Dnia 2014-03-27, o godz. 09:40:47
> > 
> > "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
> > > The council will be meeing on April 8, 2014 at 1900 UTC.  Please bring
> > > forward any agenda items you would like discussed.
> > 
> > Before we get into another revert war from patrick, I'd like to raise
> > the following item:
> > 
> > - use of ISO/IEC binary prefixes vs ambiguous 'mega' prefixes
> > 
> > Quick explanation:
> > 
> > ISO/IEC prefixes [1,2]: KiB (kibibyte), MiB (mebi-), GiB (gibi-)
> >   -- unambiguously 2^10, 2^20, 2^30
> > 
> > 'old' prefixes: kB (kilobyte), MB (mega-), GB (giga-)
> >   -- can mean 10^3 or 2^10 etc. depending on author's intention
> >   -- SI people tend to use 10^N for consistency with other units
> > 
> 
> base-10 bytes make no sense.

Sorry to disappoint you but most people in the world use base 10
as their natural system. Not that they've chosen to, it's just what you
get teached in schools, and then what you meet in shops, government
agencies, random companies and -- guess what -- even most of those
computer programs output in base 10 unconditionally.

Why would base-1024 prefixes make any sense when the numbers are
base 10?

Sorry to say that, but when I see 10-digit number, I'd rather shift
the decimal comma and use base-10 gigabytes. Dividing by power of 1024
don't come easy in base 10, and most of the people don't waste time
using a calculator just to use some fancy base-1024 unit that makes
some sense in internal computer design issues. Though 1024 there is
pretty arbitrary and makes real sense only in some contexts.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sun, Mar 30, 2014 at 7:52 AM, Michał Górny <mgorny@gentoo.org> wrote:
>
> Why would base-1024 prefixes make any sense when the numbers are
> base 10?

Numbers are numbers, but they are displayed in base 10 and people
commonly think/work in base 10.

In the interest of debating specific policy ahead of the meeting, I'll
go ahead and propose:

Proposal 1
"Whenever practical Developers are encouraged to use SI units and base
10 values (ie 1KB = 1000 bytes).  They may use base 2 values when this
output is more likely to be useful to users (eg in memory hexdumps,
etc).  Either way, unit prefixes defined in IEC 80000-13 (KB, KiB,
etc) must be used so that output is unambiguous.  This does not
require maintainers to patch upstream code to change its behavior, but
they should be applied with code that originates in Gentoo."

While I understand the resentment at the redefinition of prefixes that
have been in use for decades, the ambiguity of using SI prefixes with
non-SI definitions creates confusion and potentially error.  I think
clarity should always be valued when the change is otherwise cosmetic.

So, use MiB or MB as makes sense, but the latter should be the default
and should always mean 1000000 bytes.

If there is strong objection to my first proposal I offer:

Proposal 2
"Whenever practical developers are required to use unit prefixes
defined in IEC 80000-13 (KB, KiB, etc) so that output is unambiguous.
This does not require maintainers to patch upstream code to change its
behavior, but they should be applied with code that originates in
Gentoo."

This takes no stance on whether 1000 vs 1024 is preferred but still
requires the new-style prefixes to remove ambiguity.  I strongly
advocate that using "KB" to refer to 1024 bytes is a recipe for
confusion, if only because everybody who attends a decent school comes
out indoctrinated that kilo means something else.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ulrich Mueller]

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

>>>>> On Sun, 30 Mar 2014, Rich Freeman wrote:

> Proposal 2
> "Whenever practical developers are required to use unit prefixes
> defined in IEC 80000-13 (KB, KiB, etc) so that output is unambiguous.
> This does not require maintainers to patch upstream code to change its
> behavior, but they should be applied with code that originates in
> Gentoo."

> This takes no stance on whether 1000 vs 1024 is preferred but still
> requires the new-style prefixes to remove ambiguity.  I strongly
> advocate that using "KB" to refer to 1024 bytes is a recipe for
> confusion, if only because everybody who attends a decent school comes
> out indoctrinated that kilo means something else.

+1

(Should be lower case k for kilo though, i.e. "kB" for 1000 bytes and
"KiB" for 1024 bytes.)

Ulrich

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Michał Górny]

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

Dnia 2014-03-30, o godz. 10:07:49
Rich Freeman <rich0@gentoo.org> napisał(a):

> Proposal 1
> "Whenever practical Developers are encouraged to use SI units and base
> 10 values (ie 1KB = 1000 bytes).  They may use base 2 values when this

Just to be clear, 'kB' (small 'k', but 'KiB'). 'KB' is kelvin*byte
which could probably be useful if we were considering storage based on
heat-expanding materials.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ruud Koolen]

On Sunday 30 March 2014 16:07:49 Rich Freeman wrote:
> Proposal 1
> "Whenever practical Developers are encouraged to use SI units and base
> 10 values (ie 1KB = 1000 bytes).  They may use base 2 values when this
> output is more likely to be useful to users (eg in memory hexdumps,
> etc).  Either way, unit prefixes defined in IEC 80000-13 (KB, KiB,
> etc) must be used so that output is unambiguous.  This does not
> require maintainers to patch upstream code to change its behavior, but
> they should be applied with code that originates in Gentoo."
>
> While I understand the resentment at the redefinition of prefixes that
> have been in use for decades, the ambiguity of using SI prefixes with
> non-SI definitions creates confusion and potentially error.  I think
> clarity should always be valued when the change is otherwise cosmetic.
>
> So, use MiB or MB as makes sense, but the latter should be the default
> and should always mean 1000000 bytes.

+1

Whatever terminology we use, it had better meet the requirement that one 
kilobyte per kilometer equals one byte per meter. And the definition of the 
kilometer isn't going to change.

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sun, Mar 30, 2014 at 4:33 AM, Michał Górny <mgorny@gentoo.org> wrote:
>
> ISO/IEC prefixes [1,2]: KiB (kibibyte), MiB (mebi-), GiB (gibi-)
>   -- unambiguously 2^10, 2^20, 2^30
>
> 'old' prefixes: kB (kilobyte), MB (mega-), GB (giga-)
>   -- can mean 10^3 or 2^10 etc. depending on author's intention
>   -- SI people tend to use 10^N for consistency with other units

To think that counting is the one situation where it is actually
possible to have perfect precision, and we still manage to mess up the
units...

I'm a bit torn on this.  I'm an American, so I am supposed to do
something ambiguous and arbitrary (can we count bytes in baker's
dozens?).  I'm also a Chemist, and never met an SI unit I didn't like.

We do need to keep in mind that the laws of physics dictate that
boolean states can only be combined in groups of 8.  That's a shame,
because kibibits just rolls off the tongue and helps promote healthy
fur.

Now I need to get back to sleep because I have a 97.7 kibimeter drive
tomorrow...

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Joshua Kinard]

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

On 03/30/2014 05:23, Rich Freeman wrote:
> On Sun, Mar 30, 2014 at 4:33 AM, Michał Górny <mgorny@gentoo.org> wrote:
>>
>> ISO/IEC prefixes [1,2]: KiB (kibibyte), MiB (mebi-), GiB (gibi-)
>>   -- unambiguously 2^10, 2^20, 2^30
>>
>> 'old' prefixes: kB (kilobyte), MB (mega-), GB (giga-)
>>   -- can mean 10^3 or 2^10 etc. depending on author's intention
>>   -- SI people tend to use 10^N for consistency with other units
> 
> To think that counting is the one situation where it is actually
> possible to have perfect precision, and we still manage to mess up the
> units...
> 
> I'm a bit torn on this.  I'm an American, so I am supposed to do
> something ambiguous and arbitrary (can we count bytes in baker's
> dozens?).  I'm also a Chemist, and never met an SI unit I didn't like.
> 
> We do need to keep in mind that the laws of physics dictate that
> boolean states can only be combined in groups of 8.  That's a shame,
> because kibibits just rolls off the tongue and helps promote healthy
> fur.
> 
> Now I need to get back to sleep because I have a 97.7 kibimeter drive
> tomorrow...

I'm on the side of using the old prefixes.  I just never groked the base-10
forms.  Since Gentoo is all about choice, why not make it configurable?
Maybe a USE flag or some other switch in make.conf that can be read by
Portage to let you choose if you want natural computer size presentations
(old prefix) or the human-friendly ones (new prefixes).  We've obviously got
the code for both forms in the referenced eclass, so just wrap it in a
conditional based on the chosen switch.  That laves the debate up to which
value is the default.

That said, I assume the six-fingered man might have an entirely different
opinion on this matter.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Michał Górny]

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

Dnia 2014-03-30, o godz. 09:56:45
Joshua Kinard <kumba@gentoo.org> napisał(a):

> On 03/30/2014 05:23, Rich Freeman wrote:
> > On Sun, Mar 30, 2014 at 4:33 AM, Michał Górny <mgorny@gentoo.org> wrote:
> >>
> >> ISO/IEC prefixes [1,2]: KiB (kibibyte), MiB (mebi-), GiB (gibi-)
> >>   -- unambiguously 2^10, 2^20, 2^30
> >>
> >> 'old' prefixes: kB (kilobyte), MB (mega-), GB (giga-)
> >>   -- can mean 10^3 or 2^10 etc. depending on author's intention
> >>   -- SI people tend to use 10^N for consistency with other units
> > 
> > To think that counting is the one situation where it is actually
> > possible to have perfect precision, and we still manage to mess up the
> > units...
> > 
> > I'm a bit torn on this.  I'm an American, so I am supposed to do
> > something ambiguous and arbitrary (can we count bytes in baker's
> > dozens?).  I'm also a Chemist, and never met an SI unit I didn't like.
> > 
> > We do need to keep in mind that the laws of physics dictate that
> > boolean states can only be combined in groups of 8.  That's a shame,
> > because kibibits just rolls off the tongue and helps promote healthy
> > fur.
> > 
> > Now I need to get back to sleep because I have a 97.7 kibimeter drive
> > tomorrow...
> 
> I'm on the side of using the old prefixes.  I just never groked the base-10
> forms.  Since Gentoo is all about choice, why not make it configurable?
> Maybe a USE flag or some other switch in make.conf that can be read by
> Portage to let you choose if you want natural computer size presentations
> (old prefix) or the human-friendly ones (new prefixes).  We've obviously got
> the code for both forms in the referenced eclass, so just wrap it in a
> conditional based on the chosen switch.  That laves the debate up to which
> value is the default.

Don't you think this would be a serious overkill?

If choice for this were to be provided, it should probably land
in glibc's LC_MEASUREMENT. Though I'm not sure if that would help
something since most of the countries seem to support the binary
prefixes. At least the countries using the metric system.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Joshua Kinard]

On 03/30/2014 11:47, Michał Górny wrote:
> Dnia 2014-03-30, o godz. 09:56:45
> Joshua Kinard <kumba@gentoo.org> napisał(a):
> 
>> On 03/30/2014 05:23, Rich Freeman wrote:
>>> On Sun, Mar 30, 2014 at 4:33 AM, Michał Górny <mgorny@gentoo.org> wrote:
>>>>
>>>> ISO/IEC prefixes [1,2]: KiB (kibibyte), MiB (mebi-), GiB (gibi-)
>>>>   -- unambiguously 2^10, 2^20, 2^30
>>>>
>>>> 'old' prefixes: kB (kilobyte), MB (mega-), GB (giga-)
>>>>   -- can mean 10^3 or 2^10 etc. depending on author's intention
>>>>   -- SI people tend to use 10^N for consistency with other units
>>>
>>> To think that counting is the one situation where it is actually
>>> possible to have perfect precision, and we still manage to mess up the
>>> units...
>>>
>>> I'm a bit torn on this.  I'm an American, so I am supposed to do
>>> something ambiguous and arbitrary (can we count bytes in baker's
>>> dozens?).  I'm also a Chemist, and never met an SI unit I didn't like.
>>>
>>> We do need to keep in mind that the laws of physics dictate that
>>> boolean states can only be combined in groups of 8.  That's a shame,
>>> because kibibits just rolls off the tongue and helps promote healthy
>>> fur.
>>>
>>> Now I need to get back to sleep because I have a 97.7 kibimeter drive
>>> tomorrow...
>>
>> I'm on the side of using the old prefixes.  I just never groked the base-10
>> forms.  Since Gentoo is all about choice, why not make it configurable?
>> Maybe a USE flag or some other switch in make.conf that can be read by
>> Portage to let you choose if you want natural computer size presentations
>> (old prefix) or the human-friendly ones (new prefixes).  We've obviously got
>> the code for both forms in the referenced eclass, so just wrap it in a
>> conditional based on the chosen switch.  That laves the debate up to which
>> value is the default.
> 
> Don't you think this would be a serious overkill?
> 
> If choice for this were to be provided, it should probably land
> in glibc's LC_MEASUREMENT. Though I'm not sure if that would help
> something since most of the countries seem to support the binary
> prefixes. At least the countries using the metric system.

I'll take overkill versus endless bickering over what is really an extremely
minor issue.  If there's already some kind of variable provided by the
system libc (be it glibc, eglibc, uclibc, or freebsd-libc) that can decide
on the preferred measurement system to use, then yeah, we should use that
instead of building our own version.

The "how" we do it is more of a technical thing, and not really what is
being discussed in this thread.  If I knew more about LC_MEASUREMENT and the
code in the affected eclass, I'd probably try to hack up something myself
and propose a patch to -dev, but I think others here, who have more
knowledge on the topic, could work up something much better.

The "what" we do is the point of contention in this thread, and I think
rather than starting a holy war over measurement systems (as sometimes
happens between the majority of the world that uses metric, and the three
countries that use imperial, including the US), just allow for the choice of
both forms, and decide on a sane default.

Personally, I say make the metric version the default (new prefixes), and
leave the choice available to switch to the SI (old prefix) form with a
simple variable switch in a config file some where.

Now, I'm off to prove that black is white, then investigate this whole
"zebra crossing" thing...

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sun, Mar 30, 2014 at 7:05 PM, Joshua Kinard <kumba@gentoo.org> wrote:
> Personally, I say make the metric version the default (new prefixes), and
> leave the choice available to switch to the SI (old prefix) form with a
> simple variable switch in a config file some where.

The metric system IS the SI system.  The new prefixes are not yet SI
standards, but they are ISO standards.  However, the new prefixes
pertain to the old way of doing things.

That is...

System 1 (generally used by programmers in the 60s-90s, but less
universally as time moved on, not compatible with SI):
1 kB = 1024 bytes, report everything in kB

System 2 (aligned with SI and the metric system - used sporadically
until heavily adopted by storage manufacturers for marketing reasons)
1 kB = 1000 bytes, report everything in kB

System 3 (the new ISO standard, compatible with SI but adds to it)
1kB = 1000 bytes
1 KiB = 1024 bytes
report things in whatever units you feel like

The main advantage of the ISO standard isn't the use of either base 2
or base 10, but the fact that you can actually distinguish what base
is in use.

Either system 2/3 could be described as metric in nature - the only
one which isn't is System 1.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Richard Yao]

Lets just stick with the JEDEC standard's way of doing things that came from IBM.

On Mar 30, 2014, at 7:43 PM, Rich Freeman <rich0@gentoo.org> wrote:

> On Sun, Mar 30, 2014 at 7:05 PM, Joshua Kinard <kumba@gentoo.org> wrote:
>> Personally, I say make the metric version the default (new prefixes), and
>> leave the choice available to switch to the SI (old prefix) form with a
>> simple variable switch in a config file some where.
> 
> The metric system IS the SI system.  The new prefixes are not yet SI
> standards, but they are ISO standards.  However, the new prefixes
> pertain to the old way of doing things.
> 
> That is...
> 
> System 1 (generally used by programmers in the 60s-90s, but less
> universally as time moved on, not compatible with SI):
> 1 kB = 1024 bytes, report everything in kB
> 
> System 2 (aligned with SI and the metric system - used sporadically
> until heavily adopted by storage manufacturers for marketing reasons)
> 1 kB = 1000 bytes, report everything in kB
> 
> System 3 (the new ISO standard, compatible with SI but adds to it)
> 1kB = 1000 bytes
> 1 KiB = 1024 bytes
> report things in whatever units you feel like
> 
> The main advantage of the ISO standard isn't the use of either base 2
> or base 10, but the fact that you can actually distinguish what base
> is in use.
> 
> Either system 2/3 could be described as metric in nature - the only
> one which isn't is System 1.
> 
> Rich
> 

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Michał Górny]

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

Dnia 2014-03-30, o godz. 23:13:50
Richard Yao <ryao@gentoo.org> napisał(a):

> Lets just stick with the JEDEC standard's way of doing things that came from IBM.

JEDEC itself admits it have failed with the 'standard way':

| NOTE 2 The definitions of kilo, giga, and mega based on powers of two
| are included only to reflect common usage. IEEE/ASTM SI 10‑1997 states
| "This practice frequently leads to confusion and is deprecated." Further
| confusion results from the popular use of a "megabyte" consisting
| of 1 024 000 bytes to define the capacity of the familiar "1.44‑MB"
| diskette.

http://www.jedec.org/standards-documents/dictionary/terms/mega-m-prefix-units-semiconductor-storage-capacity

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Joshua Kinard]

On 03/31/2014 02:07, Michał Górny wrote:
> Dnia 2014-03-30, o godz. 23:13:50
> Richard Yao <ryao@gentoo.org> napisał(a):
> 
>> Lets just stick with the JEDEC standard's way of doing things that came from IBM.
> 
> JEDEC itself admits it have failed with the 'standard way':
> 
> | NOTE 2 The definitions of kilo, giga, and mega based on powers of two
> | are included only to reflect common usage. IEEE/ASTM SI 10‑1997 states
> | "This practice frequently leads to confusion and is deprecated." Further
> | confusion results from the popular use of a "megabyte" consisting
> | of 1 024 000 bytes to define the capacity of the familiar "1.44‑MB"
> | diskette.
> 
> http://www.jedec.org/standards-documents/dictionary/terms/mega-m-prefix-units-semiconductor-storage-capacity

The problem is, those of us who grew up in those dark ages, who played with
5.25" and 3.5" disks....we're a lost cause.  No hope to save us.  It'll
always be 1,024 bytes to a kilobyte.  Anything else is blasphemy.  Save
yourselves!

Besides, for an outdated standard, it still gets used a lot.  Last I
checked, one can really only buy RAM in sizes of powers of two.  And the
computer will report that size, in powers of two.  Ditto for L1/L2/L3 caches
(look at the top of any kernel dmesg), etc.

In some respect, if all one cares about is free space on a disk drive or how
fast they can stream a movie, then the KiB/MiB thing works.  But if you play
with bits and bytes from time-to-time (and worry about byte alignment) or
sometimes fiddle w/ partition tables in a hex editor...you're going to think
in terms of powers of two.

So both have their uses.  Hence my suggestion of making it a
user-configurable setting.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Michał Górny]

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

Dnia 2014-03-31, o godz. 06:56:19
Joshua Kinard <kumba@gentoo.org> napisał(a):

> On 03/31/2014 02:07, Michał Górny wrote:
> > Dnia 2014-03-30, o godz. 23:13:50
> > Richard Yao <ryao@gentoo.org> napisał(a):
> > 
> >> Lets just stick with the JEDEC standard's way of doing things that came from IBM.
> > 
> > JEDEC itself admits it have failed with the 'standard way':
> > 
> > | NOTE 2 The definitions of kilo, giga, and mega based on powers of two
> > | are included only to reflect common usage. IEEE/ASTM SI 10‑1997 states
> > | "This practice frequently leads to confusion and is deprecated." Further
> > | confusion results from the popular use of a "megabyte" consisting
> > | of 1 024 000 bytes to define the capacity of the familiar "1.44‑MB"
> > | diskette.
> > 
> > http://www.jedec.org/standards-documents/dictionary/terms/mega-m-prefix-units-semiconductor-storage-capacity
> 
> The problem is, those of us who grew up in those dark ages, who played with
> 5.25" and 3.5" disks....we're a lost cause.  No hope to save us.  It'll
> always be 1,024 bytes to a kilobyte.  Anything else is blasphemy.  Save
> yourselves!
> 
> Besides, for an outdated standard, it still gets used a lot.  Last I
> checked, one can really only buy RAM in sizes of powers of two.  And the
> computer will report that size, in powers of two.  Ditto for L1/L2/L3 caches
> (look at the top of any kernel dmesg), etc.
> 
> In some respect, if all one cares about is free space on a disk drive or how
> fast they can stream a movie, then the KiB/MiB thing works.  But if you play
> with bits and bytes from time-to-time (and worry about byte alignment) or
> sometimes fiddle w/ partition tables in a hex editor...you're going to think
> in terms of powers of two.

I feel like there's some misunderstanding here. I didn't really intend
to make everything power-of-10. It's just about the extra 'i' in 'KiB'
for unambiguity with 1000 of 'kilo'.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Mon, Mar 31, 2014 at 11:44 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2014-03-31, o godz. 06:56:19
> Joshua Kinard <kumba@gentoo.org> napisał(a):
>>>
>> In some respect, if all one cares about is free space on a disk drive or how
>> fast they can stream a movie, then the KiB/MiB thing works.  But if you play
>> with bits and bytes from time-to-time (and worry about byte alignment) or
>> sometimes fiddle w/ partition tables in a hex editor...you're going to think
>> in terms of powers of two.

KiB/MiB ARE powers of two.  It is KB/MB which are powers of ten
(depending on who you talk to).

Drive sizes tend to be reported in MB/GB, and memory tends to be
reported in MiB, GiB (though they may or may not use those
abbreviations when doing so).

>
> I feel like there's some misunderstanding here. I didn't really intend
> to make everything power-of-10. It's just about the extra 'i' in 'KiB'
> for unambiguity with 1000 of 'kilo'.

++

That is my main concern.  Use whichever convention makes the most
sense, but make it clear which one you're using.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 31/03/14 01:27 PM, Rich Freeman wrote:
> On Mon, Mar 31, 2014 at 11:44 AM, Michał Górny <mgorny@gentoo.org>
> wrote:
>> Dnia 2014-03-31, o godz. 06:56:19 Joshua Kinard
>> <kumba@gentoo.org> napisał(a):
>>>> 
>>> In some respect, if all one cares about is free space on a disk
>>> drive or how fast they can stream a movie, then the KiB/MiB
>>> thing works.  But if you play with bits and bytes from
>>> time-to-time (and worry about byte alignment) or sometimes
>>> fiddle w/ partition tables in a hex editor...you're going to
>>> think in terms of powers of two.
> 
> KiB/MiB ARE powers of two.  It is KB/MB which are powers of ten 
> (depending on who you talk to).
> 
> Drive sizes tend to be reported in MB/GB, and memory tends to be 
> reported in MiB, GiB (though they may or may not use those 
> abbreviations when doing so).
> 

This is very much old "standard" vs new standard in terms of naming.
For those of us that have been around long enough, Mega/Kilo/etc have
always meant 1024 when addressing computational storage, as per for
instance ANSI/IEEE Std 1084-1986.  However, as people know this did
become (or has always been) used ambiguously and so these terms were
apparently deprecated in favour of MiB, KiB etc by the IEC starting at
around 1996 and with formal adoption 1999 with IEC 60027-2 Amendment 2
(and expanded adoption in ISO/IEC IEC 80000-13:2008)

[*] source: http://en.wikipedia.org/wiki/Binary_prefix

+1 for usage of {K,M,G,T,...}iB as per standard.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlM5rGkACgkQ2ugaI38ACPAM2QD/eNQIRbUTfrGAolqbCPR6fR83
Is+jgG1MClaBeBki3aoBAJVluP0Gq4fWNVdm7Dl0OoT4tL7JIMjadRCO34mn/mmn
=KM13
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Douglas James Dunn]

On Monday, March 31, 2014 01:56:57 PM Ian Stakenvicius wrote:
> On 31/03/14 01:27 PM, Rich Freeman wrote:
> > On Mon, Mar 31, 2014 at 11:44 AM, Michał Górny <mgorny@gentoo.org>
> > 
> > wrote:
> >> Dnia 2014-03-31, o godz. 06:56:19 Joshua Kinard
> >> 
> >> <kumba@gentoo.org> napisał(a):
> >>> In some respect, if all one cares about is free space on a disk
> >>> drive or how fast they can stream a movie, then the KiB/MiB
> >>> thing works.  But if you play with bits and bytes from
> >>> time-to-time (and worry about byte alignment) or sometimes
> >>> fiddle w/ partition tables in a hex editor...you're going to
> >>> think in terms of powers of two.
> > 
> > KiB/MiB ARE powers of two.  It is KB/MB which are powers of ten
> > (depending on who you talk to).
> > 
> > Drive sizes tend to be reported in MB/GB, and memory tends to be
> > reported in MiB, GiB (though they may or may not use those
> > abbreviations when doing so).
> 
> This is very much old "standard" vs new standard in terms of naming.
> For those of us that have been around long enough, Mega/Kilo/etc have
> always meant 1024 when addressing computational storage, as per for
> instance ANSI/IEEE Std 1084-1986.  However, as people know this did
> become (or has always been) used ambiguously and so these terms were
> apparently deprecated in favour of MiB, KiB etc by the IEC starting at
> around 1996 and with formal adoption 1999 with IEC 60027-2 Amendment 2
> (and expanded adoption in ISO/IEC IEC 80000-13:2008)
> 
> [*] source: http://en.wikipedia.org/wiki/Binary_prefix
> 
> +1 for usage of {K,M,G,T,...}iB as per standard.


+1, the IEC is the way everyone is going, for reference

https://en.wikipedia.org/wiki/Timeline_of_binary_prefixes

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[William Hubbs]

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

On Mon, Mar 31, 2014 at 02:12:18PM -0400, Douglas James Dunn wrote:
> On Monday, March 31, 2014 01:56:57 PM Ian Stakenvicius wrote:
> > On 31/03/14 01:27 PM, Rich Freeman wrote:
> > > On Mon, Mar 31, 2014 at 11:44 AM, Michał Górny <mgorny@gentoo.org>
> > > 
> > > wrote:
> > >> Dnia 2014-03-31, o godz. 06:56:19 Joshua Kinard
> > >> 
> > >> <kumba@gentoo.org> napisał(a):
> > >>> In some respect, if all one cares about is free space on a disk
> > >>> drive or how fast they can stream a movie, then the KiB/MiB
> > >>> thing works.  But if you play with bits and bytes from
> > >>> time-to-time (and worry about byte alignment) or sometimes
> > >>> fiddle w/ partition tables in a hex editor...you're going to
> > >>> think in terms of powers of two.
> > > 
> > > KiB/MiB ARE powers of two.  It is KB/MB which are powers of ten
> > > (depending on who you talk to).
> > > 
> > > Drive sizes tend to be reported in MB/GB, and memory tends to be
> > > reported in MiB, GiB (though they may or may not use those
> > > abbreviations when doing so).
> > 
> > This is very much old "standard" vs new standard in terms of naming.
> > For those of us that have been around long enough, Mega/Kilo/etc have
> > always meant 1024 when addressing computational storage, as per for
> > instance ANSI/IEEE Std 1084-1986.  However, as people know this did
> > become (or has always been) used ambiguously and so these terms were
> > apparently deprecated in favour of MiB, KiB etc by the IEC starting at
> > around 1996 and with formal adoption 1999 with IEC 60027-2 Amendment 2
> > (and expanded adoption in ISO/IEC IEC 80000-13:2008)
> > 
> > [*] source: http://en.wikipedia.org/wiki/Binary_prefix
> > 
> > +1 for usage of {K,M,G,T,...}iB as per standard.
> 
> 
> +1, the IEC is the way everyone is going, for reference
> 
> https://en.wikipedia.org/wiki/Timeline_of_binary_prefixes

+1 for me too on this.

William


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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ulrich Mueller]

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

>>>>> On Mon, 31 Mar 2014, William Hubbs wrote:

> On Mon, Mar 31, 2014 at 02:12:18PM -0400, Douglas James Dunn wrote:
>> On Monday, March 31, 2014 01:56:57 PM Ian Stakenvicius wrote:
>> > This is very much old "standard" vs new standard in terms of naming.
>> > For those of us that have been around long enough, Mega/Kilo/etc have
>> > always meant 1024 when addressing computational storage, as per for
>> > instance ANSI/IEEE Std 1084-1986.  However, as people know this did
>> > become (or has always been) used ambiguously and so these terms were
>> > apparently deprecated in favour of MiB, KiB etc by the IEC starting at
>> > around 1996 and with formal adoption 1999 with IEC 60027-2 Amendment 2
>> > (and expanded adoption in ISO/IEC IEC 80000-13:2008)
>> > 
>> > [*] source: http://en.wikipedia.org/wiki/Binary_prefix
>> > 
>> > +1 for usage of {K,M,G,T,...}iB as per standard.
>> 
>> +1, the IEC is the way everyone is going, for reference
>> 
>> https://en.wikipedia.org/wiki/Timeline_of_binary_prefixes

> +1 for me too on this.

The rationale for using the IEC prefixes in Linux summarises things
well:

| Best practice in editing a technical or standards document is to
| (a) avoid ambiguous usages, seek clarity and precision; and
| (b) to use, follow and reference international standards.

So, +1 from me too.

Ulrich

[1] http://lkml.iu.edu/hypermail/linux/kernel/0112.2/1068.html

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Brian Dolbec]

On Mon, 31 Mar 2014 06:56:19 -0400
Joshua Kinard <kumba@gentoo.org> wrote:

> The problem is, those of us who grew up in those dark ages, who
> played with 5.25" and 3.5" disks....

You forgot cassettes... oops, you are probably too young for those ;)

For the many that don't even know what a cassette is:

http://en.wikipedia.org/wiki/Compact_Cassette


> we're a lost cause.  No hope to
> save us.  It'll always be 1,024 bytes to a kilobyte.  Anything else
> is blasphemy.  Save yourselves!
> 

+1

> Besides, for an outdated standard, it still gets used a lot.  Last I
> checked, one can really only buy RAM in sizes of powers of two.  And
> the computer will report that size, in powers of two.  Ditto for
> L1/L2/L3 caches (look at the top of any kernel dmesg), etc.
> 
> In some respect, if all one cares about is free space on a disk drive
> or how fast they can stream a movie, then the KiB/MiB thing works.
> But if you play with bits and bytes from time-to-time (and worry
> about byte alignment) or sometimes fiddle w/ partition tables in a
> hex editor...you're going to think in terms of powers of two.
> 
> So both have their uses.  Hence my suggestion of making it a
> user-configurable setting.
> 

+1

-- 
Brian Dolbec <dolsen>

[semi-OT] Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Andreas K. Huettel]

Am Montag, 31. März 2014, 17:58:08 schrieb Brian Dolbec:
>
> > So both have their uses.  Hence my suggestion of making it a
> > user-configurable setting.
> 
> +1

Which reminds me of the (European) professor who accepted a job at an US'ian 
university. Came with detailed plans about the experimental setup to the 
workshop. 

1 week later: "Are you really sure you want it built like this? It'll be 
expensive." "Yes, of course."

2 weeks later: "Are you really sure you want it built like this? It'll be 
expensive." "Yes, of course, the plans are all double-checked and correct."

6 months later: items arrive, cost a few hundred k$, are completely useless 
since the plans were in mm and the execution in inch...

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ciaran McCreesh]

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

On Sun, 30 Mar 2014 05:23:08 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> To think that counting is the one situation where it is actually
> possible to have perfect precision, and we still manage to mess up the
> units...

Because the difference between 1000 and 1024 in this context is
completely irrelevant. This is the ultimate bikeshed, and ISO/IEC is a
rather unpleasant shade of mauve.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sun, Mar 30, 2014 at 11:35 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 30 Mar 2014 05:23:08 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>> To think that counting is the one situation where it is actually
>> possible to have perfect precision, and we still manage to mess up the
>> units...
>
> Because the difference between 1000 and 1024 in this context is
> completely irrelevant. This is the ultimate bikeshed, and ISO/IEC is a
> rather unpleasant shade of mauve.

The whole point of SI is that it works beautifully when you start
mixing units.

Storage density could be expressed in GB/mm^2 or GiB/mm^2.  The former
is FAR more useful.

1 GB/mm^2 = 1PB/m^2 = 1 kB/μm^2.
1 GiB/mm^2 ~= 0.95 PiB/m^2 ~= 1.05 KiB/μm^2

And heaven forbid you just use GB to mean 2^30 bytes - lots of
opportunity for error.  However, even with unambiguous units the fact
that different elements of the compound units end up converting with
different bases makes the math not work out cleanly.

As long as you stay trapped in your nicely-discrete world of the
computer unit complexity doesn't matter so much as long as you stay
consistent (which isn't made easy by the fact that there are warring
factions over the definition of the kB).  As soon as you start getting
into anything that involves the real world and engineering you can't
avoid the units used to measure things in the real world.

If you don't care about the math coming out cleanly then we might as
well go back to using short tons, inches, and torrs.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ciaran McCreesh]

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

On Sun, 30 Mar 2014 12:27:34 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> As soon as you start getting into anything that involves the real
> world and engineering

Which isn't the case here, so this whole thing is irrelevant.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sun, Mar 30, 2014 at 12:31 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 30 Mar 2014 12:27:34 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>> As soon as you start getting into anything that involves the real
>> world and engineering
>
> Which isn't the case here, so this whole thing is irrelevant.

What prevents the output of a tool from being used in an engineering
context?  In any case, my concern is more with ambiguity (when
software tells me I have 1GB of free space, what does that mean?).  I
think GB are more useful than GiB in most cases (though I explicitly
stated in my first proposal that there are situations where this isn't
the case), but I care more about ambiguity.

Since definitions of units are generally standardized across all
potential uses (do you want a km to be different depending on whether
you're measuring road length, speed, or wavelengths?), it only made
sense for the ISO/etc to pick definitions that were useful in the
broadest sense.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ciaran McCreesh]

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

On Sun, 30 Mar 2014 12:39:56 -0400
Rich Freeman <rich@thefreemanclan.net> wrote:
> On Sun, Mar 30, 2014 at 12:31 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > On Sun, 30 Mar 2014 12:27:34 -0400
> > Rich Freeman <rich0@gentoo.org> wrote:
> >> As soon as you start getting into anything that involves the real
> >> world and engineering
> >
> > Which isn't the case here, so this whole thing is irrelevant.
> 
> What prevents the output of a tool from being used in an engineering
> context?  In any case, my concern is more with ambiguity (when
> software tells me I have 1GB of free space, what does that mean?).  I
> think GB are more useful than GiB in most cases (though I explicitly
> stated in my first proposal that there are situations where this isn't
> the case), but I care more about ambiguity.

When you're told you'll need 1GB of disk space, if you have exactly 1GB
+ 1 byte of disk space left then you need more disk space whichever way
things are being measured.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sun, Mar 30, 2014 at 12:48 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
>
> When you're told you'll need 1GB of disk space, if you have exactly 1GB
> + 1 byte of disk space left then you need more disk space whichever way
> things are being measured.

So, can you fit a 995MB file on a filesystem with 1GB of space
remaining?  The answer is a big depends when the authors of du, ls,
and df can't agree on definitions.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sun, Mar 30, 2014 at 12:48 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> When you're told you'll need 1GB of disk space, if you have exactly 1GB
> + 1 byte of disk space left then you need more disk space whichever way
> things are being measured.

So, can you fit a 995MB file on a filesystem with 1GB of space
remaining?  The answer is a big depends when the authors of du, ls,
and df (and their counterparts on other operating systems) can't agree
on definitions.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ciaran McCreesh]

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

On Sun, 30 Mar 2014 13:01:58 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> On Sun, Mar 30, 2014 at 12:48 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > When you're told you'll need 1GB of disk space, if you have exactly
> > 1GB
> > + 1 byte of disk space left then you need more disk space whichever
> > way things are being measured.
> 
> So, can you fit a 995MB file on a filesystem with 1GB of space
> remaining?  The answer is a big depends when the authors of du, ls,
> and df (and their counterparts on other operating systems) can't agree
> on definitions.

The answer is that if you need to try, you're in trouble. But since
check-reqs doesn't give you that kind of precision, no-one cares anyway.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sun, Mar 30, 2014 at 12:31 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 30 Mar 2014 12:27:34 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>> As soon as you start getting into anything that involves the real
>> world and engineering
>
> Which isn't the case here, so this whole thing is irrelevant.

What prevents the output of a tool from being used in an engineering
context?  In any case, my concern is more with ambiguity (when
software tells me I have 1GB of free space, what does that mean?).  I
think GB are more useful than GiB in most cases (though I explicitly
stated in my first proposal that there are situations where this isn't
the case), but I care more about ambiguity.

Since definitions of units are generally standardized across all
potential uses (do you want a km to be different depending on whether
you're measuring road length, speed, or wavelengths?), it only made
sense for the ISO/etc to pick definitions that were useful in the
broadest sense.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Douglas James Dunn]

On 03/30/2014 12:40 PM, Rich Freeman wrote:
> On Sun, Mar 30, 2014 at 12:31 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>> On Sun, 30 Mar 2014 12:27:34 -0400
>> Rich Freeman <rich0@gentoo.org> wrote:
>>> As soon as you start getting into anything that involves the real
>>> world and engineering
>> Which isn't the case here, so this whole thing is irrelevant.
> What prevents the output of a tool from being used in an engineering
> context?  In any case, my concern is more with ambiguity (when
> software tells me I have 1GB of free space, what does that mean?).  I
> think GB are more useful than GiB in most cases (though I explicitly
> stated in my first proposal that there are situations where this isn't
> the case), but I care more about ambiguity.
>
> Since definitions of units are generally standardized across all
> potential uses (do you want a km to be different depending on whether
> you're measuring road length, speed, or wavelengths?), it only made
> sense for the ISO/etc to pick definitions that were useful in the
> broadest sense.
>
> Rich
>
The system you are most familiar with really depends on what Operating
System you use.  if you don't use computers you probably were exposed to
either the SI units or imperial base 10 units. 

Microsoft Windows uses and has historically used the JDEC System, MB,
KB, GB in base 2,

Macintosh OSX uses SI units,

Unix as far as i can rember reading the different different versions of
the programmers manual has always stated things in IEC, i assume they
just used bits before that? i think IEC came about sometime in the mid 90's

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sun, Mar 30, 2014 at 7:44 PM, Douglas James Dunn
<djdunn.safety@gmail.com> wrote:
> The system you are most familiar with really depends on what Operating
> System you use.  if you don't use computers you probably were exposed to
> either the SI units or imperial base 10 units.

SI units ARE in base 10.  Most imperial units aren't in base 10, and
the SI prefixes aren't generally used with imperial units.  You don't
usually report height in centiyards, etc.

There seems to be some kind of misconception that this has something
to do with imperial vs metric units.

Bits and bytes are such a modern concept that they were pseudo-metric
from the start, but programmers tended to use the SI prefixes in
non-SI ways - defining a kilobyte as 1024 bytes.  "Kilo" is an SI
prefix, but the SI defines it as 1000, not 1024.

The 1024-byte kilobyte was never metric or SI or imperial.  Fairly
recently JEDEC codified the 1024-byte kilobyte, but also endorsed the
1024-byte kibibyte, and the usage obviously predates that standard.
Before then, programmers never really had a "standard" for the
kilobyte.  Since programmers don't tend to do a lot of compound units,
getting their terms endorsed by a standards body was probably not much
of a priority.  If they had gone to the SI/ISO (or whatever was around
in the 60s) they'd almost certainly have been shot down on having a
1024-byte kilobyte.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Douglas Dunn]

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

On Sun, Mar 30, 2014 at 7:54 PM, Rich Freeman <rich0@gentoo.org> wrote:

> On Sun, Mar 30, 2014 at 7:44 PM, Douglas James Dunn
> <djdunn.safety@gmail.com> wrote:
> > The system you are most familiar with really depends on what Operating
> > System you use.  if you don't use computers you probably were exposed to
> > either the SI units or imperial base 10 units.
>
> SI units ARE in base 10.  Most imperial units aren't in base 10, and
> the SI prefixes aren't generally used with imperial units.  You don't
> usually report height in centiyards, etc.
>
> There seems to be some kind of misconception that this has something
> to do with imperial vs metric units.
>
> Bits and bytes are such a modern concept that they were pseudo-metric
> from the start, but programmers tended to use the SI prefixes in
> non-SI ways - defining a kilobyte as 1024 bytes.  "Kilo" is an SI
> prefix, but the SI defines it as 1000, not 1024.
>
> The 1024-byte kilobyte was never metric or SI or imperial.  Fairly
> recently JEDEC codified the 1024-byte kilobyte, but also endorsed the
> 1024-byte kibibyte, and the usage obviously predates that standard.
> Before then, programmers never really had a "standard" for the
> kilobyte.  Since programmers don't tend to do a lot of compound units,
> getting their terms endorsed by a standards body was probably not much
> of a priority.  If they had gone to the SI/ISO (or whatever was around
> in the 60s) they'd almost certainly have been shot down on having a
> 1024-byte kilobyte.
>
> Rich
>
>
I called it imperial base 10, in the fact that you count 1-9 before hitting
10 then 10-19 before hitting 20, rather than base 2, or whatever base you
apply, not the fact that the units themselves are, and i realize that SI
are in base 10 also.

[-- Attachment #2: Type: text/html, Size: 2415 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Douglas Dunn]

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

On Sun, Mar 30, 2014 at 7:59 PM, Douglas Dunn <djdunn.safety@gmail.com>wrote:

>
>
>
> On Sun, Mar 30, 2014 at 7:54 PM, Rich Freeman <rich0@gentoo.org> wrote:
>
>> On Sun, Mar 30, 2014 at 7:44 PM, Douglas James Dunn
>> <djdunn.safety@gmail.com> wrote:
>> > The system you are most familiar with really depends on what Operating
>> > System you use.  if you don't use computers you probably were exposed to
>> > either the SI units or imperial base 10 units.
>>
>> SI units ARE in base 10.  Most imperial units aren't in base 10, and
>> the SI prefixes aren't generally used with imperial units.  You don't
>> usually report height in centiyards, etc.
>>
>> There seems to be some kind of misconception that this has something
>> to do with imperial vs metric units.
>>
>> Bits and bytes are such a modern concept that they were pseudo-metric
>> from the start, but programmers tended to use the SI prefixes in
>> non-SI ways - defining a kilobyte as 1024 bytes.  "Kilo" is an SI
>> prefix, but the SI defines it as 1000, not 1024.
>>
>> The 1024-byte kilobyte was never metric or SI or imperial.  Fairly
>> recently JEDEC codified the 1024-byte kilobyte, but also endorsed the
>> 1024-byte kibibyte, and the usage obviously predates that standard.
>> Before then, programmers never really had a "standard" for the
>> kilobyte.  Since programmers don't tend to do a lot of compound units,
>> getting their terms endorsed by a standards body was probably not much
>> of a priority.  If they had gone to the SI/ISO (or whatever was around
>> in the 60s) they'd almost certainly have been shot down on having a
>> 1024-byte kilobyte.
>>
>> Rich
>>
>>
> I called it imperial base 10, in the fact that you count 1-9 before
> hitting 10 then 10-19 before hitting 20, rather than base 2, or whatever
> base you apply, not the fact that the units themselves are, and i realize
> that SI are in base 10 also.
>

the real issue though seems to be asking if we want the default to be in
base 2 aka IEC, or base 10 aka SI, it seems that almost everywhere the JDEC
binary units are being phased out in favor of IEC to avoid confusion with
the SI.  I believe that the NIST, the national institute and standards and
technology, in the usa, require the IEC units and not the JDEC for binary
byte multiples since about 2008

now whether you want to use base 2 or base 10, it probably comes down to
what you are doing, how you are doing it, and in some cases, HEX might be
even better or easier to work with. in the spirit of gentoo, i foresee some
eselect setting switching between binary and decimal systems?

[-- Attachment #2: Type: text/html, Size: 3643 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Denis Dupeyron]

On Sun, Mar 30, 2014 at 10:27 AM, Rich Freeman <rich0@gentoo.org> wrote:
> The whole point of SI is that it works beautifully when you start
> mixing units.

Agreed. The SI system is better by a mile.

Denis.

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 3174 bytes --]

Am Donnerstag, 27. März 2014, 14:40:47 schrieb Anthony G. Basile:
> Hi everyone,
> 
> The council will be meeing on April 8, 2014 at 1900 UTC.  Please bring
> forward any agenda items you would like discussed.
> 
> --Tony

Here are several resolution drafts which I would like to ask my council 
colleagues to vote on. Part of the text is based on suggestions by other 
council members.

1) The council strongly disapproves of any developers unilaterally reverting 
QA team actions. While the case decision lies with QA and ComRel teams, the 
council welcomes the idea of immediate sanctions in such a case. An individual 
developer who disagrees with an action made in the name of QA, whether the 
action is proper or not, MUST follow the escalation procedures set forth in 
GLEP 48, and is encouraged to work with QA, ComRel or eventually the council 
to settle any concerns. The council will follow up on any accusations of QA 
abuse the same way as on any commit that is in conflict with a QA action.

2) The council recognizes that there are some open questions around when 
individuals in QA ought to take action, and how internal disagreements get 
resolved. The council would like to ask QA to design its own operating 
procedures and publish them. There should be a reasonably clear process so 
that QA members can act in the confidence that they are doing things properly, 
and the rest of the community can be assured that there is accountability. The 
council requests an update on the progress of establishing procedures prior to 
its next monthly meeting.

3) The council believes that a wide announcement and if needed discussion of 
changes to central parts of Gentoo (as, e.g., system packages, profiles, 
global use-flags) should be preferred. In particular, only informing "relevant 
people" makes no sense if others will also be affected.

4) While it is any developer's choice not to participate on the gentoo-dev and 
gentoo-project mailing lists, they nevertheless serve as main communication 
channels. If something has been discussed there, and then action has been 
taken, the council regards ignorance of the discussion not as a good 
foundation for protests against the actions.

5) The council encourages teams maintaining central parts of Gentoo to accept 
new developers as team members and teach them the required knowledge and 
intricacies. We consider this important to ensure long-term continuity and 
increase the bus factor in critical areas.

Rationale:
about 1)
If a cop pulls you over, you don't beat him up or just drive on. Even if you 
think the traffic light was still yellow or even green.

about 3)
Nobody asks for consensus (which we'll never get, I'm being realistic (and it 
should be pink with yellow stripes)). 
Whether discussion is needed, well if I announce something, either discussion 
will follow or not. I've made announcements about the profiles already that 
didnt get a single reply. Either noone understood what I was writing, or noone 
disagreed...

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Andreas K. Huettel:
> 5) The council encourages teams maintaining central parts of Gentoo
> to accept new developers as team members and teach them the
> required knowledge and intricacies. We consider this important to
> ensure long-term continuity and increase the bus factor in critical
> areas.
> 

Or don't accept them as team members in the first place, which is
perfectly fine if you can still contribute as a non-team member.

Letting someone in and then starting to teach him seems like the wrong
approach to me.

We should encourage the opposite order.
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTQUzSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgaq4QAI3m7SwF6bBrgeeO9VlwKpek
1+iRurVxuzeo/HpTE8RCnqtqKeSritBwT5ISgM8NaSfIQoTm67/M3KZwb2wgih0E
uzG4UJ9u+9LwJYgGdfgDKIBgLrnbDKxzMsl1+AcK0o8dKYE2uK+/HCdwGAUO9uqe
AAP02LrDu2/t0DssEBmJrbGsxRxyuVpbcT5kSnYAPrs9M2asMNjJXuHjSt94wWKk
abvVc/oTOHNxyvR93+69aeMfjhKJqUau6L+bJs2NwdsIer+Yfp/h9DavVDZzh6TC
STGaeH5ZALB2hYVnhtSJh2FCUNKrb0ldArKzVOpz2cSWuIKlW+oCC3qci2/s1bMD
eZEMffE7ZCTDQ5isqjRF9msvmlF1VntaCxzNT1hvip3+PxSQ8DfYwBrEPRQprgVp
4Qe9yeCP1T0/HvrgXFKxkzTNUMKXo1iynKrSi870kPiDBTjyi7sA2frm0EU/s0Wv
Xs4Q8HXVHvQDdozYDM5RU5WMTAc4YWe6yaUYeaDhSfHA0zalR1x3pLQk5ucts3xr
vQtU7rbRuvdjoywKbBuyab//XQDzjErKSItecgbJ+pWhBXArJj9y+Lhwhraiv+tZ
d1erl1eFIMNRdlACklHcWh/ITq2c8LHOoYE4td4pxfeic1GZn9GCJb7ofFG1nsdh
1TH/REelV9AG8/7Btk0X
=o8Ub
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ciaran McCreesh]

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

On Sun, 06 Apr 2014 12:47:14 +0000
hasufell <hasufell@gentoo.org> wrote:
> Andreas K. Huettel:
> > 5) The council encourages teams maintaining central parts of Gentoo
> > to accept new developers as team members and teach them the
> > required knowledge and intricacies. We consider this important to
> > ensure long-term continuity and increase the bus factor in critical
> > areas.
> > 
> 
> Or don't accept them as team members in the first place, which is
> perfectly fine if you can still contribute as a non-team member.
> 
> Letting someone in and then starting to teach him seems like the wrong
> approach to me.
> 
> We should encourage the opposite order.

That's all very well, but there are maybe two or three Gentoo
developers left who actually understand all the details and how the big
picture works when it comes to ebuilds.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ciaran McCreesh:
> On Sun, 06 Apr 2014 12:47:14 +0000 hasufell <hasufell@gentoo.org>
> wrote:
>> Andreas K. Huettel:
>>> 5) The council encourages teams maintaining central parts of
>>> Gentoo to accept new developers as team members and teach them
>>> the required knowledge and intricacies. We consider this
>>> important to ensure long-term continuity and increase the bus
>>> factor in critical areas.
>>> 
>> 
>> Or don't accept them as team members in the first place, which
>> is perfectly fine if you can still contribute as a non-team
>> member.
>> 
>> Letting someone in and then starting to teach him seems like the
>> wrong approach to me.
>> 
>> We should encourage the opposite order.
> 
> That's all very well, but there are maybe two or three Gentoo 
> developers left who actually understand all the details and how the
> big picture works when it comes to ebuilds.
> 

:)
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTQU5LXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgvUQQAJdrtaXQfIb1+JujJpn+Xws2
8/QGASQcfv9KockLQn69cU3kCoL3ShgE9FN469dVGKcryUBoDeIMdgteuS2O38Vo
9B9FnUUqlMVQ8tHDdtqChIK6+6JdD5rD8ebXmvjZraqJ7XeJR60JePsaZ5xc6sCY
NLLkn+Ezcl+N4XjxuA8hsw8VsiYboGRSPkdy2xiXDDoiYB4Rv4x2ekg+PBGj5qSu
jgHn6J3UpejCPAlQMi8Bi6SZX8hjtNhw8+gK7/d1v41GxhoOdZOeL8GfoG4Q5eyy
JLF011iN0UxSkPRpl4xn6VliXMDDk6+4OCx2VRIU6jVRX98ZWO8Q2PWqEcMST8NA
T/I5StHVKyJilzcgbx9unu7AgiN9Xdp/AYynY1Uv9UbLRoKXLqm03WMva6g1zlCL
rwapqyIINjdQ27AOU0WcFXtTOfGMk1wvN7Zhu4Qn1GCAQF6BqEbIQmA6856V6Gnu
LzlucCex+zSRlz4AVIj5JlyQw42hmhWpaNDe/Um+ugxmuCLqmhCp0mgaVhNy0YRH
h4+gYQMoqbMXklqRPHXNIp3ssEntFbF9Fzi1AaCE44mPa+C+QxqTIbHmFJYHQ8mu
556RkdSwkq+jrEGB9jyvz9hYAuKdmGo6V+fMWXaVUXxeAwZ3WXwKXgH73C9stvRG
c3u2IfWlsw/bpXFjERBA
=vXDH
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Samuli Suominen]

On 06/04/14 15:47, hasufell wrote:
> Andreas K. Huettel:
> > 5) The council encourages teams maintaining central parts of Gentoo
> > to accept new developers as team members and teach them the
> > required knowledge and intricacies. We consider this important to
> > ensure long-term continuity and increase the bus factor in critical
> > areas.
>
>
> Or don't accept them as team members in the first place, which is
> perfectly fine if you can still contribute as a non-team member.

I agree, new developers shouldn't be allowed in the QA team, there
should be some 5 year limit
at least as safe kludge to avoid disrespect like this:

#gentoo-qa, yesterday:

21:37 <@Zero_Chaos> floppym: honestly there are a few "senior" gentoo
developers which could be shot in the head for all I care.

#gentoo-qa, today:

09:16 <@xiaomiao> if you don't ... well ... one dev more or less isn't
*that* much difference, we can deal with it
09:17 <@xiaomiao> blah policy ... it took me months just to get PMS
fixed with a two-line patch

Publicly stating he doesn't care about policies, I read that as only
caring about his personal opinion and then,
abusing the powers gained from the membership.

> Letting someone in and then starting to teach him seems like the wrong
> approach to me.
>
> We should encourage the opposite order.

I agree. Specially when some of the new developers who gain a QA
membership think it elevates them into higher
platform than others who have been involved for years, making them
stubborn, in a way they don't listen to others.

I didn't want to send this mail, but I felt I had to, because this has
gone too far.

- Samuli

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I generally don't speak up when people are flaming. I've followed this
mailing list and been involved with Gentoo for far too long. I.e. I
have become defeatist about the attitudes of certain developers.

On 06/04/14 17:10, Samuli Suominen wrote:
> 21:37 <@Zero_Chaos> floppym: honestly there are a few "senior"
> gentoo developers which could be shot in the head for all I care.
However -- despite how jaded I have become with all the flaming, and
despite how little attention I pay it these days -- I can't help but
be disappointed that someone not only associated with Gentoo, but in
such a position as Zero_Chaos is in, is allowed to make such statements.

Is this what I can expect from sticking around in Gentoo?
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlNBctYACgkQRtClrXBQc7W13wEApJUYDsg8nDBHiasdddCHFFrS
dALPNgdQtMveXypU3swA/A+rQIVbI0UjOWJipFTqYPm82xxBYr0NgNWD42dXmi6v
=cQNc
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Sun, 06 Apr 2014 17:29:26 +0200
Alexander Berntsen <bernalex@gentoo.org> wrote:

> > 21:37 <@Zero_Chaos> floppym: honestly there are a few "senior"
> > gentoo developers which could be shot in the head for all I care.
> However -- despite how jaded I have become with all the flaming, and
> despite how little attention I pay it these days -- I can't help but
> be disappointed that someone not only associated with Gentoo, but in
> such a position as Zero_Chaos is in, is allowed to make such
> statements.

ComRel is aware of it; note though, that this is pulled out of context.

> Is this what I can expect from sticking around in Gentoo?

When people (yes, multiple) resort to reverting commits and/or filing
ComRel bugs instead of appropriate discussion and escalation ... yes.

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Tom Wijsman:
>> Is this what I can expect from sticking around in Gentoo?
> 
> When people (yes, multiple) resort to reverting commits and/or
> filing ComRel bugs instead of appropriate discussion and escalation
> ... yes.
> 

No, this does not conform with CoC. QA members don't have a special
right to be insulting on a non-technical level, even if people don't
follow their policies.

I am used to rude/blunt language and often prefer it over other
forms... but there is a line when it becomes random abusive language.
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTQYiEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgGakP/iHPIV8+8ljp0GNJUB0khIC+
OnHWmiQhTrkcPA8z0mCPty7EOlHNvuSOZolFKpKkDdosEpnBZuffgi3c5SiliyPj
TWTgHJum6nnUxKf6PJacIeWK2LHqXDEx+crEs+OgvQJ2hYJfWL2Bb8jM+M7GCXYA
7kuq5YInnxY4sTW2CWZQdL0sxPht5iSVgwv2kzYBINO4z7vHmNn6Yqv0nRpNI+ee
U9vxjcl3Ygpc9qL7M1BM2EGcvnh7id6gnVXk8VY+DKSLcyFDhCN5nVteiwYi36I7
8qNkWZdRiPGEAwshYCSx1QsGjfsiNvFQninaNu19CuxhpSAKFh95pwPY5skElfxx
4RPC+ifjkmWlQpf+/ZZVVEq6An1kFX5jCJbYHRFKDvM/j9jSih9EvBPvH+ZG/iGZ
6a4x2/VcTZMgfJ3AH6CgzkVYcJv1Ujlpg6HF/c8S/P30Mj0CdqG6F9eAI0PbD6+r
wU4jb9pgrrUZRwUmuBpZ4SbhM8exbOvIGyYHY3x0noTONqlVR6ICENud5v+SYRKq
HrqrIFrIxlXnPBK24cBwlDvq3DUoa4wzunNk2mjxqtas0pmmZmFTV9xXtWqv0CJP
DNglfm1xg01G070rz8wE8hxjGagNOBaAdPYWDPxNlujofBW7o/7T+Ccj/N0nzWb1
Wx5ShbO6kf6TGPTw5pod
=tZBS
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sun, Apr 6, 2014 at 1:01 PM, hasufell <hasufell@gentoo.org> wrote:
> Tom Wijsman:
>>> Is this what I can expect from sticking around in Gentoo?
>>
>> When people (yes, multiple) resort to reverting commits and/or
>> filing ComRel bugs instead of appropriate discussion and escalation
>> ... yes.
>>
>
> No, this does not conform with CoC. QA members don't have a special
> right to be insulting on a non-technical level, even if people don't
> follow their policies.
>
> I am used to rude/blunt language and often prefer it over other
> forms... but there is a line when it becomes random abusive language.

++

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Sun, 06 Apr 2014 17:01:56 +0000
hasufell <hasufell@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Tom Wijsman:
> >> Is this what I can expect from sticking around in Gentoo?
> > 
> > When people (yes, multiple) resort to reverting commits and/or
> > filing ComRel bugs instead of appropriate discussion and escalation
> > ... yes.
> > 
> 
> No, this does not conform with CoC. QA members don't have a special
> right to be insulting on a non-technical level, even if people don't
> follow their policies.

Alexander talks about expectation, not about conformity; but if multiple
people resort to reverting commits, or don't do appropriate discussion,
that would indeed not be conform with CoC as it is quite disrespectful.

> I am used to rude/blunt language and often prefer it over other
> forms... but there is a line when it becomes random abusive language.

+1 Note that we're not disagreeing here.

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[hasufell]

Tom Wijsman:
> On Sun, 06 Apr 2014 17:01:56 +0000
> hasufell <hasufell@gentoo.org> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> Tom Wijsman:
>>>> Is this what I can expect from sticking around in Gentoo?
>>>
>>> When people (yes, multiple) resort to reverting commits and/or
>>> filing ComRel bugs instead of appropriate discussion and escalation
>>> ... yes.
>>>
>>
>> No, this does not conform with CoC. QA members don't have a special
>> right to be insulting on a non-technical level, even if people don't
>> follow their policies.
> 
> Alexander talks about expectation, not about conformity; but if multiple
> people resort to reverting commits, or don't do appropriate discussion,
> that would indeed not be conform with CoC as it is quite disrespectful.
> 
>> I am used to rude/blunt language and often prefer it over other
>> forms... but there is a line when it becomes random abusive language.
> 
> +1 Note that we're not disagreeing here.
> 

So you are saying we all can expect abusive language from QA members in
the case of someone not respecting some policy?

That's a weird statement. I am not sure if you really meant it... that's
why I am asking.

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Sun, 06 Apr 2014 17:48:33 +0000
hasufell <hasufell@gentoo.org> wrote:

> Tom Wijsman:
> > On Sun, 06 Apr 2014 17:01:56 +0000
> > hasufell <hasufell@gentoo.org> wrote:
> > 
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA512
> >>
> >> Tom Wijsman:
> >>>> Is this what I can expect from sticking around in Gentoo?
> >>>
> >>> When people (yes, multiple) resort to reverting commits and/or
> >>> filing ComRel bugs instead of appropriate discussion and
> >>> escalation ... yes.
> >>>
> >>
> >> No, this does not conform with CoC. QA members don't have a special
> >> right to be insulting on a non-technical level, even if people
> >> don't follow their policies.
> > 
> > Alexander talks about expectation, not about conformity; but if
> > multiple people resort to reverting commits, or don't do
> > appropriate discussion, that would indeed not be conform with CoC
> > as it is quite disrespectful.
> > 
> >> I am used to rude/blunt language and often prefer it over other
> >> forms... but there is a line when it becomes random abusive
> >> language.
> > 
> > +1 Note that we're not disagreeing here. 
> 
> So you are saying we all can expect abusive language from QA members
> in the case of someone not respecting some policy?

To be clear; for QA members, I hope they would not act as such, but
I cannot guarantee that for every individual in and outside the QA team.

> That's a weird statement.

Only when you interpret expectations as actions that'll happen; but for
it to happen, people need to go really far, that's where common sense,
policy, other QA members, ComRel and Council come in to draw the line.

> I am not sure if you really meant it... that's why I am asking.

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[hasufell]

Tom Wijsman:
> On Sun, 06 Apr 2014 17:48:33 +0000
> hasufell <hasufell@gentoo.org> wrote:
> 
>> Tom Wijsman:
>>> On Sun, 06 Apr 2014 17:01:56 +0000
>>> hasufell <hasufell@gentoo.org> wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA512
>>>>
>>>> Tom Wijsman:
>>>>>> Is this what I can expect from sticking around in Gentoo?
>>>>>
>>>>> When people (yes, multiple) resort to reverting commits and/or
>>>>> filing ComRel bugs instead of appropriate discussion and
>>>>> escalation ... yes.
>>>>>
>>>>
>>>> No, this does not conform with CoC. QA members don't have a special
>>>> right to be insulting on a non-technical level, even if people
>>>> don't follow their policies.
>>>
>>> Alexander talks about expectation, not about conformity; but if
>>> multiple people resort to reverting commits, or don't do
>>> appropriate discussion, that would indeed not be conform with CoC
>>> as it is quite disrespectful.
>>>
>>>> I am used to rude/blunt language and often prefer it over other
>>>> forms... but there is a line when it becomes random abusive
>>>> language.
>>>
>>> +1 Note that we're not disagreeing here. 
>>
>> So you are saying we all can expect abusive language from QA members
>> in the case of someone not respecting some policy?
> 
> To be clear; for QA members, I hope they would not act as such, but
> I cannot guarantee that for every individual in and outside the QA team.
> 
>> That's a weird statement.
> 
> Only when you interpret expectations as actions that'll happen; but for
> it to happen, people need to go really far, that's where common sense,
> policy, other QA members, ComRel and Council come in to draw the line.
> 
>> I am not sure if you really meant it... that's why I am asking.
> 

That's not good enough at all. I expect more clear words from the QA
lead on this.

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Mon, 07 Apr 2014 15:08:02 +0000
hasufell <hasufell@gentoo.org> wrote:

> Tom Wijsman:
> > On Sun, 06 Apr 2014 17:48:33 +0000
> > hasufell <hasufell@gentoo.org> wrote:
> >
> >> So you are saying we all can expect abusive language from QA
> >> members in the case of someone not respecting some policy?
> > 
> > To be clear; for QA members, I hope they would not act as such, but
> > I cannot guarantee that for every individual in and outside the QA
> > team.
> > 
> >> That's a weird statement.
> > 
> > Only when you interpret expectations as actions that'll happen; but
> > for it to happen, people need to go really far, that's where common
> > sense, policy, other QA members, ComRel and Council come in to draw
> > the line.
> > 
> >> I am not sure if you really meant it... that's why I am asking.
> > 
> 
> That's not good enough at all. I expect more clear words from the QA
> lead on this.

The policy is clear enough on that; if not, we should fix that instead.

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rick "Zero_Chaos" Farina]

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

On 04/06/2014 01:01 PM, hasufell wrote:
> Tom Wijsman:
>>> Is this what I can expect from sticking around in Gentoo?
> 
>> When people (yes, multiple) resort to reverting commits and/or
>> filing ComRel bugs instead of appropriate discussion and escalation
>> ... yes.
> 
> 
> No, this does not conform with CoC. QA members don't have a special
> right to be insulting on a non-technical level, even if people don't
> follow their policies.
> 
> I am used to rude/blunt language and often prefer it over other
> forms... but there is a line when it becomes random abusive language.
> 
> 
I'm not going to challenge what is a CoC violation vs what isn't, but
I'd like it to be clear that no one should consider themselves above
conforming to the CoC, ever, for any reason.  Not QA, not me, not any
member of the community, developer or otherwise.  If someone needs to be
smacked down for being a d-bag now and again (very possibly me) then it
would be a good life lesson.

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

iQIcBAEBAgAGBQJTQbLlAAoJEKXdFCfdEflKBBMP/iiXRDapVMJYru1wwRsKgIiO
MJp91SP5TaeouIS3CWxbSxR4feAmHbCXIZ8j8xCu1k09CO4fSb0pCFuoQ/baDEHF
OuMSax5WzJy2+KsSIoXZwoK7Csx3OisfT1x61xZ5eAs9FetRT3H50RNMmC9w9Y67
WzQzm8v5iZp/Tcz6Fg2/MWtdAiYoAyUkvnmFPWBQzQRsDtGJixe/N+Y+jLtUdmSE
zCnnse1Y1MZTbHJqbuyjMdqYIyeDf4OroQ4U3rUjlYB14oQfjkhf06jM/rxR/tM2
LstUOxiRE6o0l30feiXpZs8vMMAwkXDx/H+DhoyCyzgSgTR75ztyujC6iSeB9zul
IPRqH3wxiRmcSshFq2mi7REXMHIAt6dW9e40FN2H6LA1/FKTahQXXmQg5RC57MXI
CYNh8aIVyLNbGdz3QWRCfFQkRgqPgA5RH5tjZWxOm4wtnyzrwdxejGToCwlN1p3Q
hssKZmubdo7i/HvhcvBx8k27Q4HSWPW6+VA3/wfxEojb3nqA1+N4rfkhAbsIJjxd
GbtSAe9y+PQRB+qKJRoyS5LenWZvH77d4htGRDceC65MYSFVXiVpcC7FUax7TVV0
SZGAfCcxoxyRcHyLHQVK9atD6UPlyLQl/h416jw92FuX0R2N4Y/V1bOA+cFmHOVV
xdPE/j2TXbsCJygjerla
=RX5v
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Sun, Apr 6, 2014 at 11:29 AM, Alexander Berntsen <bernalex@gentoo.org> wrote:
> However -- despite how jaded I have become with all the flaming, and
> despite how little attention I pay it these days -- I can't help but
> be disappointed that someone not only associated with Gentoo, but in
> such a position as Zero_Chaos is in, is allowed to make such statements.

Unfortunately sniping on lists/IRC/etc has been an issue for a while.
I'm all for actions to try to reduce it, but part of the problem is
that anybody actually tries to do anything about it everybody screams
bloody murder (the proctors being the ultimate example of this).

If somebody finds themselves the victim of this sort of behavior I
recommend taking it up with Comrel, and Council if unsatisfied.
Likewise if somebody feels they have been abused by QA I'd recommend
the same.  What I wouldn't suggest doing is just getting your own
hands dirty in retaliation.

This whole matter has been one debatable judgement call after another
for the most part.  The only thing that was an explicit contradiction
of written policy (GLEP 48) was reverting a QA mask.  Everything else
is the more grey area of code of conduct, how to deal with conduct,
inclusive behaviors, etc.  I think that all-around there is much we
can all learn from it, but if we punished people for most of this
stuff we'd have to punish just about everybody in the community sooner
or later.

For most of this stuff I really think the old proctor solutions of a
warning or a day-long list/IRC ban would be perfectly appropriate.  It
gets the message across while being little more than an inconvenience.
 That is very much the domain of Comrel.

The only thing that strongly concerns me here was the revert of a QA
mask.  Not only is this a policy violation, but it is an abuse of cvs
commit rights.  I don't care for some of the attitude on the lists,
and perhaps some reading this don't care for my own opinion.  I think
we need to draw a harder line when it comes to cvs access.  As
developers we effectively have root access to each other's boxes, and
to those belonging to every member of the community.  Granted, this
was a fairly minor abuse of commit rights as such things go, and I'm
fine with a fairly minor response.  I just get concerned when people
intentionally violate policy with regard to commits and are apparently
unrepentant about it (at least on the lists, and I do want to leave it
in Comrel's hands because I don't think that impersonal idealism is
the best way to handle the dispensing of "justice").

If you're the victim of QA abuse, complain, and do it as loudly (but
constructively) as you wish.  If the situation doesn't get resolved,
hold the Council accountable, and vote us out if necessary.  What we
must not be doing is getting into commit wars.

I think we've been doing a pretty good job at finding compromises with
all the controversial matters that have hit the distro over the years
(PMS, paludis, systemd, udev, eudev, /usr, etc).  What makes us work
as a distro is that even when we disagree we allow each other to make
progress on the projects we're interested in, and as a result our
users get the best of every option.  We can't afford to allow
legitimate debate to turn into a culture of possessiveness where
packages become personal property and we begin to undermine each
other's work.

So, that is my two cents, but ultimately how we work together as a
community ought to be up to the community.  We should all be holding
each other accountable, and agreeing on the rules that govern us.  I'd
be shocked if many didn't disagree with something I've written, and
I'm happy to hear about it on this list, by email, or in IRC.  I don't
want my vote on these matters to be just a matter of personal opinion,
though since everybody is affected by it you have the right to hear it
all the same.

Perhaps I'll just leave all of us with this parting "advice:"
http://en.wikipedia.org/wiki/Clean_hands

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Pacho Ramos]

El dom, 06-04-2014 a las 13:02 -0400, Rich Freeman escribió:
[...]
> The only thing that strongly concerns me here was the revert of a QA
> mask.  Not only is this a policy violation, but it is an abuse of cvs
> commit rights.  I don't care for some of the attitude on the lists,
> and perhaps some reading this don't care for my own opinion.  I think
> we need to draw a harder line when it comes to cvs access.  As
> developers we effectively have root access to each other's boxes, and
> to those belonging to every member of the community.  Granted, this
> was a fairly minor abuse of commit rights as such things go, and I'm
> fine with a fairly minor response.  I just get concerned when people
> intentionally violate policy with regard to commits and are apparently
> unrepentant about it (at least on the lists, and I do want to leave it
> in Comrel's hands because I don't think that impersonal idealism is
> the best way to handle the dispensing of "justice").
> 
> If you're the victim of QA abuse, complain, and do it as loudly (but
> constructively) as you wish.  If the situation doesn't get resolved,
> hold the Council accountable, and vote us out if necessary.  What we
> must not be doing is getting into commit wars.

I think that one step to try to fix things like this would be to clarify
how QA decisions need to be taken. Looks like there was some confusion
related with how many QA team members were in favor and against of
hardmasking the new *udev* virtuals and, then, this lead to the whole
problem escalation. What we should try to do is to clarify how QA
decisions need to be taken. Do they need to be approved by a majority of
the team? Only some of them? I have read
https://wiki.gentoo.org/wiki/Project:Quality_Assurance but I see no note
about how QA team take actions and the "procedure" to follow and expect.

Thanks for the information and help :)

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Sun, 06 Apr 2014 23:22:27 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> I think that one step to try to fix things like this would be to
> clarify how QA decisions need to be taken. Looks like there was some
> confusion related with how many QA team members were in favor and
> against of hardmasking the new *udev* virtuals and,

There is no confusion, because it was escalated too fast; instead of
appropriately addressing the QA _team_ and waiting for response first.

> then, this lead to the whole problem escalation.

This is already present in GLEP 48[1]:

    In the event that a developer still insists that a package does not
    break QA standards, an appeal can be made at the next council
    meeting. The package should be dealt with per QA's request until
    such a time that a decision is made by the council.

Note however that escalating in steps still applies; talk first to the
QA developer, then talk to the QA team [qa@gentoo.org], then talk to
others on the gentoo-dev ML and/or then talk to the Gentoo Council.

If everyone goes straight to higher instances, thus doesn't communicate;
we'll have these talks happen every month, as happened twice now.

> What we should try to do is to clarify how QA decisions need to be
> taken. Do they need to be approved by a majority of the team? Only
> some of them? I have read
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance but I see no
> note about how QA team take actions and the "procedure" to follow and
> expect.

This is also already present in GLEP 48[1]:

    In the case of disagreement among QA members the majority of
    established QA members must agree with the action. Some examples of
    disagreements are whether the perceived problem violates the policy
    or whether the solution makes the situation worse.

We know what to do; however, we can't do it if we're not addressed.

The entire event happened at night hours in the weekend with barely any
QA members awake; so, at the very least, mail us [qa@g.o] and wait 24h.

 [1]: https://wiki.gentoo.org/wiki/GLEP:48

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Mon, Apr 7, 2014 at 7:36 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> This is also already present in GLEP 48[1]:
>
>     In the case of disagreement among QA members the majority of
>     established QA members must agree with the action. Some examples of
>     disagreements are whether the perceived problem violates the policy
>     or whether the solution makes the situation worse.
>
> We know what to do; however, we can't do it if we're not addressed.

So, I already sent this suggestion to qa@ last week, but:

I would recommend that QA consider some questions that at least seem
to be poorly understood (perhaps the process should be on the wiki):
1.  When should a QA member seek action regarding something in the tree?
2.  Does a QA member need to seek approval for their actions, and when?
3.  When seeking approval, how should a QA member do so?  How long do
they need to wait for a reply before taking action?
4.  How should the sought action be clearly communicated to those
whose approval is sought, and how should approval or disapproval be
communicated?

From what I've gathered about this case from IRC/etc there was a lot
of informal but probably well-intended communication going on and some
of it ended up being ambiguous.  This is hardly new to teams in Gentoo
- I've read some Council logs in the past and had trouble
understanding what was actually decided.  A good practice is to
clearly state a motion/proposal/etc, and then have everybody clearly
say they approve or do not approve it.  Bugzilla is a great place to
document such things if everybody isn't in IRC at the same time, and
it produces a log.  But, it is up to QA to define its processes.

What is in the GLEP is really just a basic policy - you need to come
up with a way of "operationalizing" it.  It is great that in the event
of a disagreement that majority approval is needed within QA, but in
this case not everybody in QA was consulted before the mask, and the
discussion wasn't formalized so it isn't obvious that disapproval
was/wasn't given.  There are no written policies, so I can't really
say zero_chaos broke any rules (nothing says you have to ask before
doing, or that when asking you need to explicitly get approval vs not
explicitly getting disapproval).

What we also don't want is a situation where one person in QA does
something.  Then somebody else objects and undoes it pending a vote.
Then the vote comes in and it gets reverted again.  Then the impacted
developer appeals to council or the problem gets fixed and then the
mask/etc gets dropped.  At that point all our users ragequit because
they just had a package upgraded three times and downgrated twice.

QA needs to provide guidance around when (in general) their members
should apply masks, and what steps if any they should take before
doing so.  If there is objection to what they come up with, we can
deal with it, but it would be beneficial to at least come up with
something.

That said, the Council/Trustees could probably afford to do the same.
:)  I think we've been following fairly good practices around making
clear decisions this year, but it isn't like it is written down
anywhere.  It has been a problem in the past.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Mon, 7 Apr 2014 07:49:47 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Apr 7, 2014 at 7:36 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> > This is also already present in GLEP 48[1]:
> >
> >     In the case of disagreement among QA members the majority of
> >     established QA members must agree with the action. Some
> > examples of disagreements are whether the perceived problem
> > violates the policy or whether the solution makes the situation
> > worse.
> >
> > We know what to do; however, we can't do it if we're not addressed.
> 
> So, I already sent this suggestion to qa@ last week, but:
> 
> I would recommend that QA consider some questions that at least seem
> to be poorly understood (perhaps the process should be on the wiki):
> 1.  When should a QA member seek action regarding something in the
> tree? 2.  Does a QA member need to seek approval for their actions,
> and when? 3.  When seeking approval, how should a QA member do so?
> How long do they need to wait for a reply before taking action?
> 4.  How should the sought action be clearly communicated to those
> whose approval is sought, and how should approval or disapproval be
> communicated?

There are answered by GLEP 48[1] or by how we already operate:

1.  As stated in "[...] look out for the best interests of all
developers, as well as our users. [...] ensure developers have the
information they need, and that packages are maintained. [...] ensure
tree policies are respected [...]".

2. No, "In the case of disagreement among QA members the majority of
established QA members must agree with the action. [...]".

3. A mail to qa@gentoo.org and/or an agenda item, wait until a vote
or lead decision has been made; we already do things like this.

4. For qa@gentoo.org they can directly see the result; as for the
meeting, summarizing mails and summaries are published after meeting.

These have been well understood for a while now; even from before the
first QA meeting, which took place on 29 January 2014[2].

[1]: "GLEP 48"
https://wiki.gentoo.org/wiki/GLEP:48

[2]: "QA Meeting Summaries"
http://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries

> [...] A good practice is to clearly state a motion/proposal/etc, and
> then have everybody clearly say they approve or do not approve it.

This is already done in meetings; however, note that this is impossible
when nobody is around at night hours in the weekend outside a meeting.

> [...]

Thanks, I appreciate your efforts to help us out but I believe we've
already beyond that step months ago; the QA team's operations are fine,
the problem lies elsewhere. Yet, I will try to mitigate it next time.

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Samuli Suominen]

On 07/04/14 15:36, Tom Wijsman wrote:
> Thanks, I appreciate your efforts to help us out but I believe we've
> already beyond that step months ago; the QA team's operations are
> fine, the problem lies elsewhere. Yet, I will try to mitigate it next
> time. 

I find the GLEP 48 to be confusing in parts where it says "QA team, this
and that",
as in, exactly what does the "QA team" mean, can it be just an
individual member
without the rest of the team's approval, or even a vote?
I believe it means multiple people, not just one individual, since
that'd really mean
what I said earlier in these threads, that everyone should be part of
the QA team
just to protect their work from others who don't agree with everything
you do :(

- Samuli

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Mon, 07 Apr 2014 15:44:39 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> 
> On 07/04/14 15:36, Tom Wijsman wrote:
> > Thanks, I appreciate your efforts to help us out but I believe we've
> > already beyond that step months ago; the QA team's operations are
> > fine, the problem lies elsewhere. Yet, I will try to mitigate it
> > next time. 
> 
> I find the GLEP 48 to be confusing in parts where it says "QA team,
> this and that",
> as in, exactly what does the "QA team" mean, can it be just an
> individual member
> without the rest of the team's approval, or even a vote?
> I believe it means multiple people, not just one individual, since
> that'd really mean
> what I said earlier in these threads, that everyone should be part of
> the QA team
> just to protect their work from others who don't agree with everything
> you do :(

Multiple people, as it is a team; put on QA agenda for discussion.

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Mon, Apr 7, 2014 at 8:36 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Mon, 7 Apr 2014 07:49:47 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>> I would recommend that QA consider some questions that at least seem
>> to be poorly understood (perhaps the process should be on the wiki):
>> 1.  When should a QA member seek action regarding something in the
>> tree? 2.  Does a QA member need to seek approval for their actions,
>> and when? 3.  When seeking approval, how should a QA member do so?
>> How long do they need to wait for a reply before taking action?
>> 4.  How should the sought action be clearly communicated to those
>> whose approval is sought, and how should approval or disapproval be
>> communicated?
>
> There are answered by GLEP 48[1] or by how we already operate:

"how we already operate" isn't a documented practice.  I wouldn't
bring it up if there wasn't apparent confusion.

>
> 1.  As stated in "[...] look out for the best interests of all
> developers, as well as our users. [...] ensure developers have the
> information they need, and that packages are maintained. [...] ensure
> tree policies are respected [...]".

So, if any individual in QA on their own feels that taking an action
in the name of QA furthers these goals, they may do so?

>
> 2. No, "In the case of disagreement among QA members the majority of
> established QA members must agree with the action. [...]".

My question is whether they need to seek approval, and when.  I can
read the GLEP just fine.  I'm not sure what you mean by, "No."  Are
you saying they don't need to seek approval before taking action?
Honestly, this kind of ambiguity is exactly what I want us to avoid
when we get into the operations of QA.  It is better to say, "no,
pre-approval of individual QA actions is not needed because..." or
"no, pre-approval of individual actions IS needed because..."  Short
answers to complex questions lead to interpretation.

I think it is an important thing to clarify.  Are you suggesting a
workflow where any individual in QA can take an action they feel is
necessary, and then the rest of QA only comes into it if somebody
notices and disagrees, at which point the action gets undone?  Or is
the workflow that when somebody wants to take an action they first run
it past the team?

>
> 3. A mail to qa@gentoo.org and/or an agenda item, wait until a vote
> or lead decision has been made; we already do things like this.

Well, clearly nobody waited for a vote on this one.  At least, I can
find no record of a vote approving the mask on the new virtuals.  If
this is only done after a QA action is taken if there is disagreement,
then we should clarify what happens in the meantime (does the mask/etc
stay in place for a few weeks?).  I think the importance of clarifying
when individuals should act on their own becomes more important if any
team discussion only comes after the fact.  If team discussion happens
before actions are taken then there is less risk of inconsistent
actions, but of course more latency before action can be taken.

>
>> [...] A good practice is to clearly state a motion/proposal/etc, and
>> then have everybody clearly say they approve or do not approve it.
>
> This is already done in meetings; however, note that this is impossible
> when nobody is around at night hours in the weekend outside a meeting.

The Trustees do this sort of thing all the time.  Log a bug, document
a proposal, and individuals leave their votes in comments.  Generally
it is done for things that are more routine and don't require
discussion.  It has been suggested for the Council but so far the need
hasn't arisen.

I think it is important to have a way to deal with issues outside of
meetings for a team like QA which is much closer to the daily
operations of Gentoo.  For another example from the Trustees, the
Foundation grants Infra an annual budget and when they need to make
purchases they just log bugs and the Treasurer approves them and cuts
checks without any need for all the Trustees to vote.  If something
bigger than a RAID drive failure comes up then they put in a funding
request like anybody else.

> Thanks, I appreciate your efforts to help us out but I believe we've
> already beyond that step months ago; the QA team's operations are fine,
> the problem lies elsewhere. Yet, I will try to mitigate it next time.

The thing that bothers me about this particular case is that I've
heard several on QA mention that they intended to express disagreement
with zero_chaos's actions, but that their intent was never clearly
stated as outright disapproval and was interpreted as just "be careful
/ think twice / etc" advice.  It wasn't clear that their approval was
needed before taking action, and their disapproval wasn't explicit
either.

I don't want to suggest that if QA spots a rootkit in a package that
they need to wait for a monthly meeting to do something about it.
Common sense needs to prevail.  However, when the house isn't on fire
it wouldn't hurt to have a somewhat orderly way to go about
interventions.

I don't think you need a perfect set of rules either.  Any guideline
is going to be subject to interpretation, and I'm not into crucifying
people over that.  The goal though is to push back the grey areas
reasonably far, and then rely on good attitudes and common sense to
get us through the rest.

I really don't want to beat up on QA here.  I think you guys are
generally doing great work.  I just think that there is probably a
little room for improvement/transparency.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Mon, 7 Apr 2014 09:30:44 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> "how we already operate" isn't a documented practice.  I wouldn't
> bring it up if there wasn't apparent confusion.

It can be deduced from how we already operate, there isn't confusion
about that as months have passed; but yes, that could possible be
useful for new members that would join. Added another QA agenda item.

> > 1.  As stated in "[...] look out for the best interests of all
> > developers, as well as our users. [...] ensure developers have the
> > information they need, and that packages are maintained. [...]
> > ensure tree policies are respected [...]".
> 
> So, if any individual in QA on their own feels that taking an action
> in the name of QA furthers these goals, they may do so?

A definitive answer to this is hard to give, it depends on the action.
It boils down to communicating about it as well as common sense; and
that's why there is the GLEP answer to question (2), which gives some
room for QA members to do something and not have these actions wait.

> > 2. No, "In the case of disagreement among QA members the majority of
> > established QA members must agree with the action. [...]".
> 
> My question is whether they need to seek approval, and when. 
>
> I can read the GLEP just fine.  I'm not sure what you mean by, "No."
> Are you saying they don't need to seek approval before taking action?

As per GLEP 48, when there is disagreement (or doubt that there is). If
they're sure about their thoughts, why do they need to seek approval?

If this isn't the way we are expected to operate, then the GLEP should
be updated about this; but I don't think this is a resolution to this.

(And yes; as earlier in this thread, this is about expectations again)

> Honestly, this kind of ambiguity is exactly what I want us to avoid
> when we get into the operations of QA.  It is better to say, "no,
> pre-approval of individual QA actions is not needed because..." or
> "no, pre-approval of individual actions IS needed because..." Short
> answers to complex questions lead to interpretation.

This makes extra policy where there is none; and thus, the lack of there
being a policy is the answer here. The policy in answer (2) limits that.

> I think it is an important thing to clarify.  Are you suggesting a
> workflow where any individual in QA can take an action they feel is
> necessary, and then the rest of QA only comes into it if somebody
> notices and disagrees, at which point the action gets undone?  Or is
> the workflow that when somebody wants to take an action they first run
> it past the team?

There is no suggestion from me, what is and isn't in GLEP 48 works fine.
 
> Well, clearly nobody waited for a vote on this one. At least, I can
> find no record of a vote approving the mask on the new virtuals.

For there to be a vote the team needs to be aware; and as nobody that
disagreed send a mail out to them, nothing happened.

> If this is only done after a QA action is taken if there is
> disagreement, then we should clarify what happens in the meantime
> (does the mask/etc stay in place for a few weeks?).

As deputy lead, soon after, I've requested the mask to temporarily
stay until the team comes together to discuss it and/or decide if it
can stay or gets unmasked; as a lead, the day after, creffett decided to
take away the mask and asked Zero_Chaos to get approval from the team.

The mask, per GLEP 48, stays unless QA team or a lead decides otherwise.

> I think the importance of clarifying when individuals should act on
> their own becomes more important if any team discussion only comes
> after the fact.  If team discussion happens before actions are taken
> then there is less risk of inconsistent actions, but of course more
> latency before action can be taken.

I don't see how we would have ever been able to predict this case.

> The Trustees do this sort of thing all the time.  Log a bug, document
> a proposal, and individuals leave their votes in comments.  Generally
> it is done for things that are more routine and don't require
> discussion.  It has been suggested for the Council but so far the need
> hasn't arisen.

Neither has it for QA team; if someone feels so, he / she will do that. 

> I think it is important to have a way to deal with issues outside of
> meetings for a team like QA which is much closer to the daily
> operations of Gentoo.

Mail to the alias or filing a bug works; in this case, neither happened.

> The thing that bothers me about this particular case is that I've
> heard several on QA mention that they intended to express disagreement
> with zero_chaos's actions, but that their intent was never clearly
> stated as outright disapproval and was interpreted as just "be careful
> / think twice / etc" advice. 
>
> It wasn't clear that their approval was needed before taking action,

There is no policy that indicates approval is needed.

> and their disapproval wasn't explicit either.

Disapprovals were clearly put out to the QA leads; the first one was
retracted as a change in mind happened at that point, I wasn't around
when the second happened but it resulted in the removal of the mask.

It should be more explicit and send out to the whole QA team, not
just leads; this again brings us back to escalate in small steps, which
is something that applies to whole Gentoo and not just to the QA team.

> I don't want to suggest that if QA spots a rootkit in a package that
> they need to wait for a monthly meeting to do something about it.

And that's why a definitive answer to your question is hard to give.

> Common sense needs to prevail.  However, when the house isn't on fire
> it wouldn't hurt to have a somewhat orderly way to go about
> interventions.

That can happen in the form of stepwise escalations.

> I don't think you need a perfect set of rules either.  Any guideline
> is going to be subject to interpretation, and I'm not into crucifying
> people over that.  The goal though is to push back the grey areas
> reasonably far, and then rely on good attitudes and common sense to
> get us through the rest.
> 
> I really don't want to beat up on QA here.  I think you guys are
> generally doing great work.  I just think that there is probably a
> little room for improvement/transparency.

+1 Agreed; as stated on the ComRel bug, this is a case where we _all_
can learn from. Just by this case happening and thinking it through;
there are already a lot of preventative measures that come up in mind,
next time it happens people will be taken apart, their viewpoints will
be listened to in detail, helped further to properly escalate it, ...

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Chris Reffett]

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

On 04/07/2014 09:30 AM, Rich Freeman wrote:
> On Mon, Apr 7, 2014 at 8:36 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
>> 2. No, "In the case of disagreement among QA members the majority of
>> established QA members must agree with the action. [...]".
> 
> My question is whether they need to seek approval, and when.  I can
> read the GLEP just fine.  I'm not sure what you mean by, "No."  Are
> you saying they don't need to seek approval before taking action?
> Honestly, this kind of ambiguity is exactly what I want us to avoid
> when we get into the operations of QA.  It is better to say, "no,
> pre-approval of individual QA actions is not needed because..." or
> "no, pre-approval of individual actions IS needed because..."  Short
> answers to complex questions lead to interpretation.
> 
> I think it is an important thing to clarify.  Are you suggesting a
> workflow where any individual in QA can take an action they feel is
> necessary, and then the rest of QA only comes into it if somebody
> notices and disagrees, at which point the action gets undone?  Or is
> the workflow that when somebody wants to take an action they first run
> it past the team?
> 
>>
>> 3. A mail to qa@gentoo.org and/or an agenda item, wait until a vote
>> or lead decision has been made; we already do things like this.
> 
> Well, clearly nobody waited for a vote on this one.  At least, I can
> find no record of a vote approving the mask on the new virtuals.  If
> this is only done after a QA action is taken if there is disagreement,
> then we should clarify what happens in the meantime (does the mask/etc
> stay in place for a few weeks?).  I think the importance of clarifying
> when individuals should act on their own becomes more important if any
> team discussion only comes after the fact.  If team discussion happens
> before actions are taken then there is less risk of inconsistent
> actions, but of course more latency before action can be taken.
> 
Most of this already has policy. Quoting from our notification rules,
agreed upon in one of our earliest meetings:

"We fix and send a friendly reminder to the maintainer(s) for trivial
fixes; open bug, wait 2 weeks, make the change for larger but
non-critical fixes; make the change and send a notification for critical
fixes."

This does not actually cover the QA team taking non-emergency action
without filing a bug, nor does it specify whether these decisions need
to be discussed among the team. Those will need to be sorted out at a
future QA team meeting, and we will also be discussing how to deal with
internal disagreements and writing down our procedures more explicitly.
However, I think that it is reasonably to infer from this existing
policy that unilateral action should only be taken in an emergency (and
by emergency I mean something like an ebuild potentially breaking
systems). This was not an emergency, and from my understanding it could
have waited a bit longer for team discussion. Zero_Chaos's actions were
taken too hastily, and he and I will be discussing this. I was not there
at the time, so I do not have all of the facts, but this is what it
looks like from a cold read of the situation. I know that the virtuals
were introduced without discussion, which was not good, but the quick
action was not the right action, and I am not entirely convinced that
this was a QA problem. This was a people issue (not notifying about a
new thing), not a technical issue, and so I don't think we should have
been involved in the first place. ssuominen's revert of a mask was also
inappropriate.

I also am disappointed by the constant bickering and sniping going on
both in IRC and on-list. I think all of us should be polite and
professional, even when disagreeing with somebody. Pretty much all
parties involved in this argument have been disrespectful to each other,
and I am not okay with that.

Finally, the QA team will be discussing what we should and should not be
tackling, and when it is okay to call an action a QA action. Like I said
earlier, I'm not sure that this was something we should have been
involved in, and so we will need to think that part through. We will
also be covering potential consequences for willy-nilly flashing of the
QA "badge" (a problem several people on this thread have pointed out).

tl;dr: introducing the new virtuals without discussion: bad. Unilateral
masking in a non-emergency: bad. Reverting QA stuff: bad. QA action
workflow: will be discussed, clarified, and written down. People
bickering uselessly: bad. What qualifies as a QA action and when it's
okay to call it such, and consequences of doing so improperly: to be
discussed.

Chris Reffett
Gentoo QA Lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1031 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rich Freeman]

On Mon, Apr 7, 2014 at 12:36 PM, Chris Reffett <creffett@gentoo.org> wrote:
>
> <lots of great stuff>

++
++
++

> Finally, the QA team will be discussing what we should and should not be
> tackling, and when it is okay to call an action a QA action.

Thanks - I appreciate that you can't always be around.  This is really
what I was looking for from QA.

The GLEP is fairly open-ended, and this came up in the Council
meetings before we reconstituted QA.  There was even debate over
whether we should appoint anybody to QA until we clarify policy.
Instead we took the minimal step of making the QA lead accountable to
the Council but mostly leaving the GLEP alone in the hope that QA
could help establish its own direction.

As I said, for the most part I think it has been going well.  Anytime
I pop into -qa on irc I see a lot of work that frankly we should all
be a lot more appreciative of.

Please do continue to work with your team to clarify policy.  I'd
encourage the rest of the community to do whatever you can to make
their lives easier.

AND TALK TO EACH OTHER!!!!  If the council could turn that into a
policy I'm sure we would...

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[hasufell]

Chris Reffett:
[...]


Thanks for the clear words.


> Pretty much all
> parties involved in this argument have been disrespectful to each other,
> and I am not okay with that.
> 

Except this diplomatic phrase.

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Mon, 07 Apr 2014 18:45:31 +0000
hasufell <hasufell@gentoo.org> wrote:

> Chris Reffett:
> > Pretty much all parties involved in this argument have been
> > disrespectful to each other, and I am not okay with that.
> 
> Except this diplomatic phrase.

That is so when you perceive an observation and opinion as diplomatic.

If we say that everyone involved could learn, that doesn't mean they
must, it's up for themselves to decide if they want to learn from it;
we might or might not be okay with that, depending on what was learned.

It doesn't appear to be diplomatic; as has been made clear early in this
thread, by policy as well as expectations, rehashed by deputy and lead.

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Pacho Ramos]

El lun, 07-04-2014 a las 14:36 +0200, Tom Wijsman escribió:
> On Mon, 7 Apr 2014 07:49:47 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> 
> > On Mon, Apr 7, 2014 at 7:36 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> > > This is also already present in GLEP 48[1]:
> > >
> > >     In the case of disagreement among QA members the majority of
> > >     established QA members must agree with the action. Some
> > > examples of disagreements are whether the perceived problem
> > > violates the policy or whether the solution makes the situation
> > > worse.
> > >
> > > We know what to do; however, we can't do it if we're not addressed.
> > 
> > So, I already sent this suggestion to qa@ last week, but:
> > 
> > I would recommend that QA consider some questions that at least seem
> > to be poorly understood (perhaps the process should be on the wiki):
> > 1.  When should a QA member seek action regarding something in the
> > tree? 2.  Does a QA member need to seek approval for their actions,
> > and when? 3.  When seeking approval, how should a QA member do so?
> > How long do they need to wait for a reply before taking action?
> > 4.  How should the sought action be clearly communicated to those
> > whose approval is sought, and how should approval or disapproval be
> > communicated?
> 
> There are answered by GLEP 48[1] or by how we already operate:
> 
> 1.  As stated in "[...] look out for the best interests of all
> developers, as well as our users. [...] ensure developers have the
> information they need, and that packages are maintained. [...] ensure
> tree policies are respected [...]".
> 
> 2. No, "In the case of disagreement among QA members the majority of
> established QA members must agree with the action. [...]".
> 
> 3. A mail to qa@gentoo.org and/or an agenda item, wait until a vote
> or lead decision has been made; we already do things like this.
> 
> 4. For qa@gentoo.org they can directly see the result; as for the
> meeting, summarizing mails and summaries are published after meeting.
> 
> These have been well understood for a while now; even from before the
> first QA meeting, which took place on 29 January 2014[2].
> 
> [1]: "GLEP 48"
> https://wiki.gentoo.org/wiki/GLEP:48
> 
> [2]: "QA Meeting Summaries"
> http://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries
> 
> > [...] A good practice is to clearly state a motion/proposal/etc, and
> > then have everybody clearly say they approve or do not approve it.
> 
> This is already done in meetings; however, note that this is impossible
> when nobody is around at night hours in the weekend outside a meeting.
> 
> > [...]
> 
> Thanks, I appreciate your efforts to help us out but I believe we've
> already beyond that step months ago; the QA team's operations are fine,
> the problem lies elsewhere. Yet, I will try to mitigate it next time.
> 

Thanks for the clarification (also Rich questions were mostly the same I
was wondering about :D)

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Samuli Suominen]

On 07/04/14 14:49, Rich Freeman wrote:
> On Mon, Apr 7, 2014 at 7:36 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
>> This is also already present in GLEP 48[1]:
>>
>>     In the case of disagreement among QA members the majority of
>>     established QA members must agree with the action. Some examples of
>>     disagreements are whether the perceived problem violates the policy
>>     or whether the solution makes the situation worse.
>>
>> We know what to do; however, we can't do it if we're not addressed.
> So, I already sent this suggestion to qa@ last week, but:
>
> I would recommend that QA consider some questions that at least seem
> to be poorly understood (perhaps the process should be on the wiki):
> 1.  When should a QA member seek action regarding something in the tree?

Direct action? When there is something visibly broken[1], or a policy
has been violated

[1] The definition of broken doesn't apply to controversial design models,
for which...

...indirect action can be taken, like putting it on council's next agenda

> 2.  Does a QA member need to seek approval for their actions, and when?

When he wants to change something despite no policies being violated, nor
anything being actually broken[1]

[1] See above.

> 3.  When seeking approval, how should a QA member do so?  How long do
> they need to wait for a reply before taking action?

For long as it takes to get everyone available for a majority vote
and/or putting
it on council's agenda and waiting until the vote has been done in their
side.

> What we also don't want is a situation where one person in QA does
> something.  Then somebody else objects and undoes it pending a vote.
> Then the vote comes in and it gets reverted again.  Then the impacted
> developer appeals to council or the problem gets fixed and then the
> mask/etc gets dropped.  At that point all our users ragequit because
> they just had a package upgraded three times and downgrated twice.

That's why individual QA members, or even two of them, as some people
team up in a nasty way, shouldn't have too much powers to begin with.
For anything even slightly controversial, they should always seek for a
majority vote, and that vote should result in a clear action, like written
down policy/guideline.

I'm not sure where to draw the line between requiring a majority QA vote,
or when to push it to council.
Problem with just having a majority QA vote, is that the voting happens in
a unscheduled (or very late scheduled) meeting at IRC, and there isn't prior
discussion on the ML where objections could be raised by non-members.

Let's not make this a dictatorship. :-/

- Samuli

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Mon, 07 Apr 2014 17:52:46 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> 
> On 07/04/14 14:49, Rich Freeman wrote:
> > So, I already sent this suggestion to qa@ last week, but:
> >
> > I would recommend that QA consider some questions that at least seem
> > to be poorly understood (perhaps the process should be on the wiki):
> > 1.  When should a QA member seek action regarding something in the
> > tree?
> 
> Direct action? When there is something visibly broken[1], or a policy
> has been violated
> 
> [1] The definition of broken doesn't apply to controversial design
> models, for which...
> 
> ...indirect action can be taken, like putting it on council's next
> agenda

Outside of the context of the case; what is suggested here conflicts
with what GLEP 48[1] states, "In the event that a developer still
insists that a package does not break QA standards, an appeal can be
made at the next council meeting.", furthermore, bringing everything
straight to the Gentoo Council like this neglects the QA team's purpose.

[1]: https://wiki.gentoo.org/wiki/GLEP:48
 
> > 2.  Does a QA member need to seek approval for their actions, and
> > when?
> 
> When he wants to change something despite no policies being violated,
> nor anything being actually broken[1]
> 
> [1] See above.

Who would decide how over whether it is a violation or brokenness?

> > 3.  When seeking approval, how should a QA member do so?  How long
> > do they need to wait for a reply before taking action?
> 
> For long as it takes to get everyone available for a majority vote
> and/or putting
> it on council's agenda and waiting until the vote has been done in
> their side.

This is a long sentence, can you clarify it by splitting it up to
avoid misinterpretation? In particular, if I have read it right, why
should Gentoo Council and Gentoo QA be contacted at the same time when
Gentoo QA is yet to decide on the matter? We already do wait as such.

> > What we also don't want is a situation where one person in QA does
> > something.  Then somebody else objects and undoes it pending a vote.
> > Then the vote comes in and it gets reverted again.  Then the
> > impacted developer appeals to council or the problem gets fixed and
> > then the mask/etc gets dropped.  At that point all our users
> > ragequit because they just had a package upgraded three times and
> > downgrated twice.
> 
> That's why individual QA members, or even two of them, as some people
> team up in a nasty way, shouldn't have too much powers to begin with.

In this case, it's a temporary mask that doesn't stop your work at all;
but granted, we shouldn't be able to go too far, but then where should
the line be drawn (on our bikes)?

> For anything even slightly controversial, they should always seek for
> a majority vote, and that vote should result in a clear action, like
> written down policy/guideline.

When is something controversial (about my bike)?

> I'm not sure where to draw the line between requiring a majority QA
> vote, or when to push it to council.

First do the former, then do the latter; no need to draw a line. :)

> Problem with just having a majority QA vote, is that the voting
> happens in a unscheduled (or very late scheduled) meeting at IRC, and
> there isn't prior discussion on the ML where objections could be
> raised by non-members.

The next meeting usually gets announced by mail (creffett does so, but
I'm not sure if he is around at the moment), as well as is listed on the
QA agenda page as well as is listed in the Gentoo QA topic.

When? Wednesday, April 16, 2014 at 1800 UTC
Where? #gentoo-qa
What? https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Agenda

Objections can be send to us, even after the meeting, if you want to;
consider that when things are said, they're not necessarily final.

> Let's not make this a dictatorship. :-/

Let's not make this a (bike shedding) contest. :-\

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Jeroen Roovers]

On Sun, 06 Apr 2014 18:10:56 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> #gentoo-qa, today:
> 
> 09:16 <@xiaomiao> if you don't ... well ... one dev more or less isn't
> *that* much difference, we can deal with it
> 09:17 <@xiaomiao> blah policy ... it took me months just to get PMS
> fixed with a two-line patch

Patrick has been around for years. :)


Regards,
     jer

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Samuli Suominen]

On 06/04/14 18:31, Jeroen Roovers wrote:
> On Sun, 06 Apr 2014 18:10:56 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>
>> #gentoo-qa, today:
>>
>> 09:16 <@xiaomiao> if you don't ... well ... one dev more or less isn't
>> *that* much difference, we can deal with it
>> 09:17 <@xiaomiao> blah policy ... it took me months just to get PMS
>> fixed with a two-line patch
> Patrick has been around for years. :)

I didn't realize it was Patrick behind that nick.   Seriously, now I'm
even more disappointed than I was.

- Samuli

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ciaran McCreesh]

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

On Sun, 06 Apr 2014 18:30:10 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 06/04/14 18:31, Jeroen Roovers wrote:
> > On Sun, 06 Apr 2014 18:10:56 +0300
> > Samuli Suominen <ssuominen@gentoo.org> wrote:
> >
> >> #gentoo-qa, today:
> >>
> >> 09:16 <@xiaomiao> if you don't ... well ... one dev more or less
> >> isn't *that* much difference, we can deal with it
> >> 09:17 <@xiaomiao> blah policy ... it took me months just to get PMS
> >> fixed with a two-line patch
> > Patrick has been around for years. :)
> 
> I didn't realize it was Patrick behind that nick.   Seriously, now I'm
> even more disappointed than I was.

Why the surprise? It's a pretty safe bet that anyone who goes on
and on about "fixing" PMS or making things "match reality" is a card
carrying member of the troll brigade.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

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

On Sun, 6 Apr 2014 16:44:50 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sun, 06 Apr 2014 18:30:10 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
> > On 06/04/14 18:31, Jeroen Roovers wrote:
> > > On Sun, 06 Apr 2014 18:10:56 +0300
> > > Samuli Suominen <ssuominen@gentoo.org> wrote:
> > >
> > >> #gentoo-qa, today:
> > >>
> > >> 09:16 <@xiaomiao> if you don't ... well ... one dev more or less
> > >> isn't *that* much difference, we can deal with it
> > >> 09:17 <@xiaomiao> blah policy ... it took me months just to get
> > >> PMS fixed with a two-line patch
> > > Patrick has been around for years. :)
> > 
> > I didn't realize it was Patrick behind that nick.   Seriously, now
> > I'm even more disappointed than I was.
> 
> Why the surprise? It's a pretty safe bet that anyone who goes on
> and on about "fixing" PMS or making things "match reality" is a card
> carrying member of the troll brigade.

+1 In the context of this discussion (dynamic deps, revbumps) one needs
to recognize what the state we are in is, what problem has formed in
that state and what the possible solutions are. Then bring those
solutions up for consideration; and not just, "we now do it this way".

Here an example for the context from which this sub thread resides:

=============
= Situation =
=============

PMS says in 8.1 that dependencies must be installed and usable before a
certain point in the merge or a batch of install:

    Build dependencies (DEPEND). These must be installed and usable
    before any of the ebuild src_* phase functions is executed. These
    may not be installed at all if a binary package is being merged.

    Runtime dependencies (RDEPEND). These must be installed and usable
    before the results of an ebuild merging are treated as usable.

    Post dependencies (PDEPEND). These must be installed at some point
    before the package manager finishes the batch of installs.

===========
= Problem =
===========

Developers sometimes need to adjust the dependencies; as they might
have forgotten a runtime dependency, in which case they want to ensure
that dependency is present on the system. As it is specified in the
PMS, there's no way for that to happen in-place.

=============
= Solutions =
=============

1. Revision bump, such that the dependencies get installed.

2. Dynamic dependencies, such that the dependencies from the repository
   are always used and not those from /var/db/pkg/

3. ...

============
= Thoughts =
============

Option (1) respects the PMS, but will cause some unnecessary rebuilds;
whereas option (2), which is the default in Portage, ignores the PMS.

Currently, people are doing both; this causes some more rebuilds on the
users as well as packages breaking on other PMS consumers. Both
solutions have their (dis)advantages; choosing one or the other, if
necessary, will need some consideration.

Besides that, it'll also touch basic questions like whether Gentoo is
still a meta distribution, whether the PMS still matters nowadays,
whether the Portage tree needs to strictly respect the PMS (all
consumers) or needs to respect only one PMS implementation (Portage).

It's a recipe for discourse, bike shedding, (dis)agreements, ...

-- 
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] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Sun, 6 Apr 2014 17:31:52 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Sun, 06 Apr 2014 18:10:56 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
> 
> > #gentoo-qa, today:
> > 
> > 09:16 <@xiaomiao> if you don't ... well ... one dev more or less
> > isn't *that* much difference, we can deal with it
> > 09:17 <@xiaomiao> blah policy ... it took me months just to get PMS
> > fixed with a two-line patch
> 
> Patrick has been around for years. :)

But xiaomiao hasn't, afaik; let us respect the identity. ^^

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Sun, 06 Apr 2014 18:10:56 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> I agree, new developers shouldn't be allowed in the QA team, there
> should be some 5 year limit at least as safe kludge to avoid
> disrespect like this:

That suggests a correlation between age and respect, similar messages
to those that were brought forward can be read from elders; it is more
wise to focus on constructive discourse.

> Publicly stating he doesn't care about policies, I read that as only
> caring about his personal opinion and then, abusing the powers gained
> from the membership.

That is an interpretation; looking at the results, that personal
opinion and or abuse of powers seems hardly recognizable. And if you
do recognize it, the escalation allows you to address such matters.

> I agree. Specially when some of the new developers who gain a QA
> membership think it elevates them into higher platform than others who
> have been involved for years, making them stubborn, in a way they
> don't listen to others.
>
> I didn't want to send this mail, but I felt I had to, because this has
> gone too far.

The same could be said about elders, as well as my mail, in eternity.

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Joshua Kinard]

On 04/06/2014 12:09, Tom Wijsman wrote:
> On Sun, 06 Apr 2014 18:10:56 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
> 
>> I agree, new developers shouldn't be allowed in the QA team, there
>> should be some 5 year limit at least as safe kludge to avoid
>> disrespect like this:
> 
> That suggests a correlation between age and respect, similar messages
> to those that were brought forward can be read from elders; it is more
> wise to focus on constructive discourse.

Speaking as someone whose been in Gentoo since mid-2003, age != respect.
Respect is earned, not given simply because one hangs around long enough.

Sure, I remember/recall a lot of the back-history that underpins some of the
things we have today (I still remember the discussion on the creation of
"herds" in Gentoo), but knowledge is not static.  Times change and so do
processes and methods, and just because I've been around a long time doesn't
mean I fully understand the way things are done today.

Sometimes I wonder if old devs should re-take the ebuild quizzes every few
years to test their knowledge and see if they're keeping up with the times.
 I got a funny feeling I might flunk today's quizzes once or twice.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ciaran McCreesh]

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

On Sun, 06 Apr 2014 17:25:34 -0400
Joshua Kinard <kumba@gentoo.org> wrote:
> On 04/06/2014 12:09, Tom Wijsman wrote:
> > On Sun, 06 Apr 2014 18:10:56 +0300
> > Samuli Suominen <ssuominen@gentoo.org> wrote:
> > 
> >> I agree, new developers shouldn't be allowed in the QA team, there
> >> should be some 5 year limit at least as safe kludge to avoid
> >> disrespect like this:
> > 
> > That suggests a correlation between age and respect, similar
> > messages to those that were brought forward can be read from
> > elders; it is more wise to focus on constructive discourse.
> 
> Speaking as someone whose been in Gentoo since mid-2003, age !=
> respect. Respect is earned, not given simply because one hangs around
> long enough.

This is a policy violation. Respect must be given whether it is earned
or not.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Patrick Lauer]

On Sunday 06 April 2014 22:33:18 Ciaran McCreesh wrote:

> > Speaking as someone whose been in Gentoo since mid-2003, age !=
> > respect. Respect is earned, not given simply because one hangs around
> > long enough.
> 
> This is a policy violation. Respect must be given whether it is earned
> or not.

... no.


Why do you even ... I mean ... sigh.

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ciaran McCreesh]

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

On Mon, 07 Apr 2014 16:00:20 +0800
Patrick Lauer <patrick@gentoo.org> wrote:
> On Sunday 06 April 2014 22:33:18 Ciaran McCreesh wrote:
> > > Speaking as someone whose been in Gentoo since mid-2003, age !=
> > > respect. Respect is earned, not given simply because one hangs
> > > around long enough.
> > 
> > This is a policy violation. Respect must be given whether it is
> > earned or not.
> 
> ... no.
> 
> 
> Why do you even ... I mean ... sigh.

No, seriously, it's policy, and you're violating it:

https://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=2

You are required to be "respectful of everybody", even people who
haven't earned it and don't deserve it.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

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

On Mon, 7 Apr 2014 15:51:24 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Mon, 07 Apr 2014 16:00:20 +0800
> Patrick Lauer <patrick@gentoo.org> wrote:
> > On Sunday 06 April 2014 22:33:18 Ciaran McCreesh wrote:
> > > > Speaking as someone whose been in Gentoo since mid-2003, age !=
> > > > respect. Respect is earned, not given simply because one hangs
> > > > around long enough.
> > > 
> > > This is a policy violation. Respect must be given whether it is
> > > earned or not.
> > 
> > ... no.
> > 
> > Why do you even ... I mean ... sigh.
> 
> No, seriously, it's policy, and you're violating it:
> 
> https://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=2
> 
> You are required to be "respectful of everybody", even people who
> haven't earned it and don't deserve it.

"Though respect is earned, [...]"

https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct

Joshua said nothing about not giving respect; thanks, but no, thanks.

-- 
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] Call for agenda items - Council meeting 2014-04-08

[Joshua Kinard]

On 04/06/2014 17:33, Ciaran McCreesh wrote:
> On Sun, 06 Apr 2014 17:25:34 -0400
> Joshua Kinard <kumba@gentoo.org> wrote:
>> On 04/06/2014 12:09, Tom Wijsman wrote:
>>> On Sun, 06 Apr 2014 18:10:56 +0300
>>> Samuli Suominen <ssuominen@gentoo.org> wrote:
>>>
>>>> I agree, new developers shouldn't be allowed in the QA team, there
>>>> should be some 5 year limit at least as safe kludge to avoid
>>>> disrespect like this:
>>>
>>> That suggests a correlation between age and respect, similar
>>> messages to those that were brought forward can be read from
>>> elders; it is more wise to focus on constructive discourse.
>>
>> Speaking as someone whose been in Gentoo since mid-2003, age !=
>> respect. Respect is earned, not given simply because one hangs around
>> long enough.
> 
> This is a policy violation. Respect must be given whether it is earned
> or not.

Correct, wrong words chosen on my part.  What I meant was, despite however
long I've been around, doesn't give me the rights to go off and do whatever
I think is right.  If I screw something up, I expect someone to point it out
and, if needed, rebuke me.  While policy states that I have to give respect
to others regardless if they've earned it not, I personally feel that I must
earn people's respect by working with other developers as team to resolve
problems.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Rick "Zero_Chaos" Farina]

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

On 04/06/2014 11:10 AM, Samuli Suominen wrote:
> 
> On 06/04/14 15:47, hasufell wrote:
>> Andreas K. Huettel:
>>> 5) The council encourages teams maintaining central parts of Gentoo
>>> to accept new developers as team members and teach them the
>>> required knowledge and intricacies. We consider this important to
>>> ensure long-term continuity and increase the bus factor in critical
>>> areas.
>>
>>
>> Or don't accept them as team members in the first place, which is
>> perfectly fine if you can still contribute as a non-team member.
> 
> I agree, new developers shouldn't be allowed in the QA team, there
> should be some 5 year limit
> at least as safe kludge to avoid disrespect like this:
> 
> #gentoo-qa, yesterday:
> 
> 21:37 <@Zero_Chaos> floppym: honestly there are a few "senior" gentoo
> developers which could be shot in the head for all I care.

I fully stand by my statements.  There are a few senior developers who
feel they can do whatever they like.  They ignore policy, revert things
others have done to improve gentoo, or otherwise make major changes
without consulting anyone.  Since this statement was made in the context
of a similar discussion about "senior" developers I'd like to add that
it's not just one person, nor is it just senior developers who have this
issue.  The big difference is that the newer developers often respond to
a polite "please stop reverting changes" while the "senior" developers
think they are god's immortal gifts to gentoo and above reproach.

To anyone that thinks they can do whatever they like, all the time, no
matter what policy they are breaking, know that will not abide.

Thanks,
Zero_Chaos

PS>  Incidentally, this comment actually wasn't even about you, if you
go back and check the context you can probably plainly see that.  But of
course that is neither here nor there.
> 
> #gentoo-qa, today:
> 
> 09:16 <@xiaomiao> if you don't ... well ... one dev more or less isn't
> *that* much difference, we can deal with it
> 09:17 <@xiaomiao> blah policy ... it took me months just to get PMS
> fixed with a two-line patch
> 
> Publicly stating he doesn't care about policies, I read that as only
> caring about his personal opinion and then,
> abusing the powers gained from the membership.
> 
>> Letting someone in and then starting to teach him seems like the wrong
>> approach to me.
>>
>> We should encourage the opposite order.
> 
> I agree. Specially when some of the new developers who gain a QA
> membership think it elevates them into higher
> platform than others who have been involved for years, making them
> stubborn, in a way they don't listen to others.
> 
> I didn't want to send this mail, but I felt I had to, because this has
> gone too far.
> 
> - Samuli
> 
> 
> 

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

iQIcBAEBAgAGBQJTQY/oAAoJEKXdFCfdEflKG+4P/Re2F/dPl+1/9C4bl1tKk6UX
e4jluXXrPvDfdAdmL68wMZromzjCwlirvIh4/svCIXkFlAWXGhS82MH+zFbbKLVO
ETyfxsGgU/Iu9rLl8Cj883eRq+hMtHdBTMKuc0p00NJqLhdgxP291Cj5tk7xAe/H
6JF06C8j2scW9VTCufIaU2UZas94hIrr6Xem174sVvtcfN3CvQrWeRnabYupuBOW
dLBcKQokzUkZvwLAivFX3CSGR9O2HeFLMcYx8lQEFmx5026IchcSFthlF1R0FxDf
4IarjnjlKK+K9r6OFMiRxT/yWKoVgAmGj4M6Xt1qgF/0z4e/eV8PkuR2jBYnB0pH
Ey40Hru9X18LzFAAH4Sr+fyejwJ/goQ4CLcdihD+X0wD0Ht03JBPxaATMWuQ8hiC
q8BKNdgDRH39iSXR013U8CyS6rAZYNTn6WRVaUfrLeFuT8ndBIzQ4SKCboprJ4Lg
fQAFW3zku5EHYKyuU2GgiDi03nD67rlyZvopC0ddrqKNxX0G4bNwzUhEN40UkUK4
mn6QhGBW47ROLmguNQof4hcNyERWCRT1YIs9TqT8sW1bf8hFw+hdJFojBh6M92YT
t9X0dSHi32QuTg3ch6DTJ0RR3HAtEGkezpfYRcMUFF0NJ3+sXVTpSG9YFpbW87Nv
tejgkL3jJu8ojDp6C1VF
=jvZk
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Samuli Suominen]

On 06/04/14 20:33, Rick "Zero_Chaos" Farina wrote:
> On 04/06/2014 11:10 AM, Samuli Suominen wrote:
>
> > On 06/04/14 15:47, hasufell wrote:
> >> Andreas K. Huettel:
> >>> 5) The council encourages teams maintaining central parts of Gentoo
> >>> to accept new developers as team members and teach them the
> >>> required knowledge and intricacies. We consider this important to
> >>> ensure long-term continuity and increase the bus factor in critical
> >>> areas.
> >>
> >>
> >> Or don't accept them as team members in the first place, which is
> >> perfectly fine if you can still contribute as a non-team member.
>
> > I agree, new developers shouldn't be allowed in the QA team, there
> > should be some 5 year limit
> > at least as safe kludge to avoid disrespect like this:
>
> > #gentoo-qa, yesterday:
>
> > 21:37 <@Zero_Chaos> floppym: honestly there are a few "senior" gentoo
> > developers which could be shot in the head for all I care.
>
> I fully stand by my statements.

Makes me sad. I can't see how you could ever manage to communicate with
some people you have
to communicate as in your role in the in QA team.
It requires some so called "customer service" skills, neutrality,
following estabilished policies instead
of making up your own and trying to enforce those made up ones with
harsh language.
You should reconsider if you are the best fit for the team, if you want
best for Gentoo, and do the right
thing, and resign from the team, and work on other areas where you don't
need to communicate so much with others.

> There are a few senior developers who
> feel they can do whatever they like.

I haven't seen any, could be you be more specific? Yes, I've seen some
older developers, including
myself, keeping their old workflow, but that's hardly "do whatever they
like"

> They ignore policy,

I haven't seen any, could you be more specific what policies have been
violated, and by whom?

> revert things others have done to improve gentoo,

Again, I haven't seen anything like this, yes, there has been some
reverts (including by myself), but
nothing that has "improved gentoo" has been reverted.

> or otherwise make major changes without consulting anyone.

If you are referring to our last issue, re: the new virtuals, I've
already proofed the issue has been
discussed in the past and even documented down in the wiki. It's what
the council voted for when
they allowed use of subslots in gentoo-x86.
If this is not what you meant, again, could you be more specific what
and whom you mean?

- Samuli

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Mon, 07 Apr 2014 08:47:20 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 06/04/14 20:33, Rick "Zero_Chaos" Farina wrote:
> > On 04/06/2014 11:10 AM, Samuli Suominen wrote:
> >
> > > #gentoo-qa, yesterday:
> >
> > > 21:37 <@Zero_Chaos> floppym: honestly there are a few "senior"
> > > gentoo developers which could be shot in the head for all I care.
> >
> > I fully stand by my statements.
> 
> Makes me sad. I can't see how you could ever manage to communicate
> [...]

... instead of revert; and yes, this goes for more than the both of you.

> > There are a few senior developers who
> > feel they can do whatever they like.
> 
> I haven't seen any [...]
>
> > They ignore policy,
> 
> I haven't seen any, [..]

... because the context in which the message was placed is ignored.

> > revert things others have done to improve gentoo,
> 
> Again, I haven't seen anything like this, [...]

... but it is yet to be seen if we continue like this.

> > or otherwise make major changes without consulting anyone.
> 
> If you are referring to our last issue, [...]

... or the other issues by those few senior developers; as can be read
about, in the context of the message from #gentoo-qa that was quoted.

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Patrick Lauer]

On Sunday 06 April 2014 18:10:56 Samuli Suominen wrote:
> On 06/04/14 15:47, hasufell wrote:
> > Andreas K. Huettel:
> > > 5) The council encourages teams maintaining central parts of Gentoo
> > > to accept new developers as team members and teach them the
> > > required knowledge and intricacies. We consider this important to
> > > ensure long-term continuity and increase the bus factor in critical
> > > areas.
> > 
> > Or don't accept them as team members in the first place, which is
> > perfectly fine if you can still contribute as a non-team member.
> 
> I agree, new developers shouldn't be allowed in the QA team, there
> should be some 5 year limit
> at least as safe kludge to avoid disrespect like this:

I wonder if you noticed that I've been a dev since 2004 ...

and disrespect, well, you actively work towards breaking things.

Even when told, multiple times, that you're breaking things,

And that we will revert breakage when detected ...


> 09:16 <@xiaomiao> if you don't ... well ... one dev more or less isn't
> *that* much difference, we can deal with it
> 09:17 <@xiaomiao> blah policy ... it took me months just to get PMS
> fixed with a two-line patch
> 
> Publicly stating he doesn't care about policies, I read that as only
> caring about his personal opinion and then,
> abusing the powers gained from the membership.

Common sense ...

If you need an explicit unambiguous policy spelled out for any action things 
get extremely unpleasant.

So maybe try to reason about the effects on users, and consider strategies that 
are not explicitly written down ... 

And I don't do this "as QA member", I've done this for long enough before. So 
don't play victim now, just don't cause any breakage and I'll not have to 
touch your precious ebuildsssss. Being part of QA is just putting an official 
label on what I've been doing for quite a long time.

... and don't think it's personal, I mask, revert or fix anything that needs to 
be unbroken, without any emotional attachment to the package, the author or 
the day of the week. 

> 
> > Letting someone in and then starting to teach him seems like the wrong
> > approach to me.
> > 
> > We should encourage the opposite order.
> 
> I agree. Specially when some of the new developers who gain a QA
> membership think it elevates them into higher
> platform than others who have been involved for years, making them
> stubborn, in a way they don't listen to others.
> 
> I didn't want to send this mail, but I felt I had to, because this has
> gone too far.
> 
> - Samuli

Yes, it has gone too far.

But only because you actively say that you don't care about breaking things, 
again, after getting massive pushback the last time ... I mean ...

Can't be that hard to think about the response other people will have when you 
waste their time. Especially when you have anecdotal evidence that predicts a 
very boring simple response.

Don't break stuff, and no one will have the desire to yell at you. And if you 
do, well, learn from it, fix the fallout, and don't get in the way of others 
fixing it if you don't feel like doing it.


So thanks for making me state the obvious about eleventeen times in one email, 
I shall now put on my Captain Obvious T-Shirt and watch some Batman (the old 
TV series) to feel better.

Have a ... day, I guess ...


Patrick

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Samuli Suominen]

On 07/04/14 10:49, Patrick Lauer wrote:
> On Sunday 06 April 2014 18:10:56 Samuli Suominen wrote:
>> On 06/04/14 15:47, hasufell wrote:
>>> Andreas K. Huettel:
>>>> 5) The council encourages teams maintaining central parts of Gentoo
>>>> to accept new developers as team members and teach them the
>>>> required knowledge and intricacies. We consider this important to
>>>> ensure long-term continuity and increase the bus factor in critical
>>>> areas.
>>> Or don't accept them as team members in the first place, which is
>>> perfectly fine if you can still contribute as a non-team member.
>> I agree, new developers shouldn't be allowed in the QA team, there
>> should be some 5 year limit
>> at least as safe kludge to avoid disrespect like this:
> I wonder if you noticed that I've been a dev since 2004 ...
>
> and disrespect, well, you actively work towards breaking things.
>
> Even when told, multiple times, that you're breaking things,
>
> And that we will revert breakage when detected ...

What you told was you will impose your personal opinions as policies,
and you will use the
QA team membership as a cover to enforce it upon others.

Instead of actually working towards getting it written down somewhere,
making it official,
so there is something for you to reference, and something for others to
follow.

This is why the last team died, and now you are repeating the mistake.

- Samuli

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Patrick Lauer]

On Monday 07 April 2014 11:02:44 Samuli Suominen wrote:

> >> at least as safe kludge to avoid disrespect like this:
> > I wonder if you noticed that I've been a dev since 2004 ...
> > 
> > and disrespect, well, you actively work towards breaking things.
> > 
> > Even when told, multiple times, that you're breaking things,
> > 
> > And that we will revert breakage when detected ...
> 
> What you told was you will impose your personal opinions as policies,
> and you will use the
> QA team membership as a cover to enforce it upon others.

I don't even know what words I could use to change your mind.

The only way I see right now to avoid you breaking stuff is removing your 
commit rights, because you actively do not show signs of common sense or an 
ability to learn.
 
> Instead of actually working towards getting it written down somewhere,
> making it official,
> so there is something for you to reference, and something for others to
> follow.

Policy suggestion:

"Don't break no shit. If you do, fix it. If you don't someone else will, and 
you don't whine at them because you be not doing a good job."

... do we really need to write that down? Explicitly, in a few ten thousand 
words to reduce ambiguity? 
> 
> This is why the last team died, and now you are repeating the mistake.

No, last team got torn apart by the "Do something ... Noooo! NOT THAT OMG WTF"

That stress made it basically impossible to get anything done, and the ensuing 
frustration soured the interpersonal reason until QA was mostly passive and 
angry.

I just don't care about the whining and continue my anti-breakage crusade. And 
so far there's only been about three people that got upset about masking 
broken stuff. The easiest way to get me to ignore you is to not cause any 
trouble, where trouble means "things not working". 

I'm busy enough with repoman-visible breakage, so don't expect me to be in a 
good mood if you actively cause more breakage: Current average is about 2-3 
new bugs I have to file every single day (mostly because no one else seems to 
have enough motivation)

Again, as stated on IRC: This is not personal. It's just that some of us have 
basic expectations of things working, so it's in your best interest not to 
violate these basic ideas. Make it personal and it will be personal, which I'm 
not really in the mood for ... such a waste of time that could be used for 
much more interesting things. 

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Samuli Suominen]

On 07/04/14 11:26, Patrick Lauer wrote:
> On Monday 07 April 2014 11:02:44 Samuli Suominen wrote:
>
>>>> at least as safe kludge to avoid disrespect like this:
>>> I wonder if you noticed that I've been a dev since 2004 ...
>>>
>>> and disrespect, well, you actively work towards breaking things.
>>>
>>> Even when told, multiple times, that you're breaking things,
>>>
>>> And that we will revert breakage when detected ...
>> What you told was you will impose your personal opinions as policies,
>> and you will use the
>> QA team membership as a cover to enforce it upon others.
> I don't even know what words I could use to change your mind.

You can get me to change mind by writing up a policy that says
dynamic deps can't be relied upon, and getting rest of the QA
team, perhaps council, on board with it.

#gentoo-qa, yesterday:

17:50 < floppym> Hmm... documenting when to revbump in relationship to
RDEPEND is not a bad idea. However, I think the rules would
be a little more subtle than "always". We would also need some way of
dealing with eclasses which generate
RDEPEND, and also with revbumping stable ebuilds.


>
> The only way I see right now to avoid you breaking stuff is removing your 
> commit rights, because you actively do not show signs of common sense or an 
> ability to learn.

Likewise, while dynamic deps are the default, and I, as a binary package
user, are aware of the pitfall, I can't understand
your line of thinking process at all.
Read above, get the policy estabilished, and people, including me, will
follow it.
Meanwhile it's plain rude to bother me with this, since it's nothing
more than your own opinion, and I'm allowed to
disagree with it.
Meanwhile it's plain rude to users of non-binary packages to force
useless rebuilds upon, I'm tempted to leverage
it with an 'DoS', but that would go a bit too far.

>  
>> Instead of actually working towards getting it written down somewhere,
>> making it official,
>> so there is something for you to reference, and something for others to
>> follow.
> Policy suggestion:
>
> "Don't break no shit. If you do, fix it. If you don't someone else will, and 
> you don't whine at them because you be not doing a good job."
>
> ... do we really need to write that down? Explicitly, in a few ten thousand 
> words to reduce ambiguity? 

I read this as flamebait, not worth replying.

>> This is why the last team died, and now you are repeating the mistake.
> No, last team got torn apart by the "Do something ... Noooo! NOT THAT OMG WTF"
>
> That stress made it basically impossible to get anything done, and the ensuing 
> frustration soured the interpersonal reason until QA was mostly passive and 
> angry.

This wasn't the case at all, we had no issues within the team before one
particular disagreement where an QA member tried to force others, including
other QA members, to act upon his personal view on things without an proper
written down policy.
Now that it's written down, and the tools have been updated accordingly,
we have no issues at all. It's what should have happened as a first step.

>
> I just don't care about the whining and continue my anti-breakage crusade. And 
> so far there's only been about three people that got upset about masking 
> broken stuff. The easiest way to get me to ignore you is to not cause any 
> trouble, where trouble means "things not working". 
>
> I'm busy enough with repoman-visible breakage, so don't expect me to be in a 
> good mood if you actively cause more breakage: Current average is about 2-3 
> new bugs I have to file every single day (mostly because no one else seems to 
> have enough motivation)
>
> Again, as stated on IRC: This is not personal. It's just that some of us have 
> basic expectations of things working, so it's in your best interest not to 
> violate these basic ideas. Make it personal and it will be personal, which I'm 
> not really in the mood for ... such a waste of time that could be used for 
> much more interesting things. 
>

This is not personal. This is merely what's the right way to move
forward to avoid
mistakes from the past.
Yes, this is an huge waste of everyones time. Just use the normal ways
of getting things,
like policies, guidelines, changed and we don't have to continue with
this at all.

- Samuli

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman]

On Mon, 07 Apr 2014 14:54:43 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> You can get me to change mind by writing up a policy that says
> dynamic deps can't be relied upon, and getting rest of the QA
> team, perhaps council, on board with it.
 
> #gentoo-qa, yesterday:
> 
> 17:50 < floppym> Hmm... documenting when to revbump in relationship to
> RDEPEND is not a bad idea. However, I think the rules would
> be a little more subtle than "always". We would also need some way of
> dealing with eclasses which generate
> RDEPEND, and also with revbumping stable ebuilds.

Given multiple people request this, this is put on the Meeting Agenda.

https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Agenda
 
> [...]

Indeed, no need to go forth-and-back about this; everyone who wishes to
do so, can send their opinion to qa@gentoo.org for it to be taken into
consideration. State this in the context of the added agenda item and
that you do not wish to receive a reply.

> [...]

Bringing up the previous QA team learns us to do more knowledge
codification; on the other hand, we shouldn't do too much of it either.

-- 
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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ciaran McCreesh]

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

On Mon, 07 Apr 2014 14:54:43 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:
> You can get me to change mind by writing up a policy that says
> dynamic deps can't be relied upon, and getting rest of the QA
> team, perhaps council, on board with it.

They can't be relied upon: they stop working as soon as you remove an
ebuild from the tree when the user still has that version installed.
They also don't work if you make changes to runtime dependencies that
need a reinstall or upgrade, as has happened with various -config
utilities.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Samuli Suominen]

On 07/04/14 17:49, Ciaran McCreesh wrote:
> On Mon, 07 Apr 2014 14:54:43 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>> You can get me to change mind by writing up a policy that says
>> dynamic deps can't be relied upon, and getting rest of the QA
>> team, perhaps council, on board with it.
> They can't be relied upon: they stop working as soon as you remove an
> ebuild from the tree when the user still has that version installed.
> They also don't work if you make changes to runtime dependencies that
> need a reinstall or upgrade, as has happened with various -config
> utilities.
>

Of course if reinstall or upgrade is required, then revision bump is
issued as normal.
If the version isn't anymore in Portage, then user will be upgrading
into one that is anyway, and
the problem becomes moot.

I'm aware it's not perfect, but it's the best we have.

I'm also aware of Paludis having more issues with it, than Portage,
IIRC, which is really irrelevant since
Portage is the official PM.    No, this is not a flamebait, and I feel
like apologizing to you already, but that's just how I see it.

I'm arguing that working around the PM bug(s) by enforcing "a useless"
rebuilds for everyone, is not the solution.

- Samuli

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ciaran McCreesh]

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

On Mon, 07 Apr 2014 17:58:52 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 07/04/14 17:49, Ciaran McCreesh wrote:
> > On Mon, 07 Apr 2014 14:54:43 +0300
> > Samuli Suominen <ssuominen@gentoo.org> wrote:
> >> You can get me to change mind by writing up a policy that says
> >> dynamic deps can't be relied upon, and getting rest of the QA
> >> team, perhaps council, on board with it.
> > They can't be relied upon: they stop working as soon as you remove
> > an ebuild from the tree when the user still has that version
> > installed. They also don't work if you make changes to runtime
> > dependencies that need a reinstall or upgrade, as has happened with
> > various -config utilities.
> >
> 
> Of course if reinstall or upgrade is required, then revision bump is
> issued as normal.

But we've seen this not happen: people have had old versions of a
package installed that needed foo-config installed to do the uninstall
(e.g. pkg_postrm), and then an eclass was changed to use foo2-config
instead, and the uninstall or upgrade wouldn't work because foo-config
had incorrectly been uninstalled.

Dynamic dependencies do *not* mean dynamic pkg_* functions.

> If the version isn't anymore in Portage, then user will be upgrading
> into one that is anyway, and
> the problem becomes moot.

This isn't enforced, though. And see above: it's only moot if you
ignore all the ways it goes wrong.

> I'm aware it's not perfect, but it's the best we have.
> 
> I'm also aware of Paludis having more issues with it, than Portage,
> IIRC, which is really irrelevant since
> Portage is the official PM.    No, this is not a flamebait, and I feel
> like apologizing to you already, but that's just how I see it.
> 
> I'm arguing that working around the PM bug(s) by enforcing "a useless"
> rebuilds for everyone, is not the solution.

The bug is Portage sometimes doing dynamic deps...

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Patrick Lauer]

On Monday 07 April 2014 14:54:43 Samuli Suominen wrote:
> On 07/04/14 11:26, Patrick Lauer wrote:
> > On Monday 07 April 2014 11:02:44 Samuli Suominen wrote:
> >>>> at least as safe kludge to avoid disrespect like this:
> >>> I wonder if you noticed that I've been a dev since 2004 ...
> >>> 
> >>> and disrespect, well, you actively work towards breaking things.
> >>> 
> >>> Even when told, multiple times, that you're breaking things,
> >>> 
> >>> And that we will revert breakage when detected ...
> >> 
> >> What you told was you will impose your personal opinions as policies,
> >> and you will use the
> >> QA team membership as a cover to enforce it upon others.
> > 
> > I don't even know what words I could use to change your mind.
> 
> You can get me to change mind by writing up a policy that says
> dynamic deps can't be relied upon, and getting rest of the QA
> team, perhaps council, on board with it.
> 
> #gentoo-qa, yesterday:
> 
> 17:50 < floppym> Hmm... documenting when to revbump in relationship to
> RDEPEND is not a bad idea. However, I think the rules would
> be a little more subtle than "always". We would also need some way of
> dealing with eclasses which generate
> RDEPEND, and also with revbumping stable ebuilds.
> 

Soo, here's the usecase:

/usr/portage empty except profiles/ (needed for various reasons)

Everything else supplied by binpkgs


... note how there's no way at all ever for your dynamic deps idea to affect 
the visible packages and updates.

So the only way that has a chance of working, wuarrghl, is to run emerge -e 
world on every friggin update always. So about a CPU-day per build env, or 
about two CPU-weeks for more comprehensive binpkg collections. 


I'd suggest not making life more difficult :)

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Samuli Suominen]

On 08/04/14 03:37, Patrick Lauer wrote:
> On Monday 07 April 2014 14:54:43 Samuli Suominen wrote:
>> On 07/04/14 11:26, Patrick Lauer wrote:
>>> On Monday 07 April 2014 11:02:44 Samuli Suominen wrote:
>>>>>> at least as safe kludge to avoid disrespect like this:
>>>>> I wonder if you noticed that I've been a dev since 2004 ...
>>>>>
>>>>> and disrespect, well, you actively work towards breaking things.
>>>>>
>>>>> Even when told, multiple times, that you're breaking things,
>>>>>
>>>>> And that we will revert breakage when detected ...
>>>> What you told was you will impose your personal opinions as policies,
>>>> and you will use the
>>>> QA team membership as a cover to enforce it upon others.
>>> I don't even know what words I could use to change your mind.
>> You can get me to change mind by writing up a policy that says
>> dynamic deps can't be relied upon, and getting rest of the QA
>> team, perhaps council, on board with it.
>>
>> #gentoo-qa, yesterday:
>>
>> 17:50 < floppym> Hmm... documenting when to revbump in relationship to
>> RDEPEND is not a bad idea. However, I think the rules would
>> be a little more subtle than "always". We would also need some way of
>> dealing with eclasses which generate
>> RDEPEND, and also with revbumping stable ebuilds.
>>
> Soo, here's the usecase:
>
> /usr/portage empty except profiles/ (needed for various reasons)
>
> Everything else supplied by binpkgs
>
>
> ... note how there's no way at all ever for your dynamic deps idea to affect 
> the visible packages and updates.
>
> So the only way that has a chance of working, wuarrghl, is to run emerge -e 

Yet, that's exactly why my build host for binpkgs at work is doing. I'm
fine with that.
Far better than making everyone rebuild the packages needlessly.

> world on every friggin update always. So about a CPU-day per build env, or 
> about two CPU-weeks for more comprehensive binpkg collections. 
>
>
> I'd suggest not making life more difficult :)
>

Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Ciaran McCreesh]

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

On Mon, 07 Apr 2014 15:49:55 +0800
Patrick Lauer <patrick@gentoo.org> wrote:
> On Sunday 06 April 2014 18:10:56 Samuli Suominen wrote:
> > On 06/04/14 15:47, hasufell wrote:
> > > Andreas K. Huettel:
> > > > 5) The council encourages teams maintaining central parts of
> > > > Gentoo to accept new developers as team members and teach them
> > > > the required knowledge and intricacies. We consider this
> > > > important to ensure long-term continuity and increase the bus
> > > > factor in critical areas.
> > > 
> > > Or don't accept them as team members in the first place, which is
> > > perfectly fine if you can still contribute as a non-team member.
> > 
> > I agree, new developers shouldn't be allowed in the QA team, there
> > should be some 5 year limit
> > at least as safe kludge to avoid disrespect like this:
> 
> I wonder if you noticed that I've been a dev since 2004 ...
> 
> and disrespect, well, you actively work towards breaking things.

I believe the problem is that your idea of what "broken" means has at
best a coincidental connection with reality.

It would help everyone involved if you could refer to policy documents
such as PMS to justify your decisions.

-- 
Ciaran McCreesh

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