[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Fri, 20 May 2016 19:47:55 +0000 (UTC)
"Johannes Huber" <johu@gentoo.org> wrote:

> commit:     548f4ee19c6b0fe0d5e87e84a5a82c421229e0ce
> Author:     Michael Palimaka <kensington <AT> gentoo <DOT> org>
> AuthorDate: Fri May 20 19:46:11 2016 +0000
> Commit:     Johannes Huber <johu <AT> gentoo <DOT> org>
> CommitDate: Fri May 20 19:47:15 2016 +0000
> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=548f4ee1
> 
> kde5.eclass: install all translations when LINGUAS is undefined
> 
> This mirrors the behaviour of the gettext autotools macros.
> 
> Gentoo-bug: 581382
> 
> Signed-off-by: Johannes Huber <johu <AT> gentoo.org>
> 
>  eclass/kde5.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/kde5.eclass b/eclass/kde5.eclass
> index 377d2c5..eaffb9e 100644
> --- a/eclass/kde5.eclass
> +++ b/eclass/kde5.eclass
> @@ -397,7 +397,7 @@ kde5_src_prepare() {
>  
>  	# enable only the requested translations
>  	# when required
> -	if [[ -d po ]] ; then
> +	if [[ -d po && -v LINGUAS ]] ; then
>  		pushd po > /dev/null || die
>  		for lang in *; do
>  			if [[ -d ${lang} ]] && ! has ${lang} ${LINGUAS} ; then

This doesn't really make any difference since per EAPI 6 all USE_EXPAND
variables (incl. LINGUAS) are always defined. The only reason it seems
to work for you is due to a Portage bug.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Alfredo Tupone]

On 23:45 Thu 05 Sep     , Mike Gilbert wrote:
> On Thu, Sep 5, 2019 at 6:47 PM Thomas Deutschmann <whissi@gentoo.org> wrote:
> >
> > On 2019-09-05 22:16, Michał Górny wrote:
> > >> But as per the way the dev manual is written, he arguably *is*
> > >> following policy.
> > >>
> > >> Stop taking the line of assuming he's trying to be belligerent.
> > >
> > > He says explicitly that he is against fixing devmanual because he likes
> > > the way he can abuse it right now.
> >
> > You are the only one adding _abuse_ here. Stop that, thanks. When I
> > replied to your mail I was just asking... nothing more. I don't
> > understand why you are reading so much into it.
> 
> The devmanual o clearly indicates that an email to gentoo-dev is
> strongly preferred. I don't see any reason why tupone could not have
> done this.
> 
> You seem to be trying to take this opportunity to prove some loosely
> related point.
> 
> > But yes, I like the current exception for "per-package" eclasses like I
> > am concerned that a review requirement would cause a significant delay:
> >
> > Back to my example, imagine we would move pkg_config to new mysql
> > eclass. If we would bump mysql/percona-server/mariadb package and will
> > receive bug reports later because upstream changed something causing
> > pkg_config to fail we would now have to propose a patch, wait 48
> > hours... i.e. package would be broken for ~72 hours just because of a
> > policy I don't reject in general (yes, I like reviews) but where I think
> > exceptions must be possible.
> 
> This argument is stupid. If you need to push a critical bug fix, then
> do it. Nobody will fault you for it.
> 
> This clearly does not apply to ada.eclass.
> 
I am going just to explain the reason why I did not ask ml about review the first time.
1) ada.eclass is copied from python-single-r1 eclass with s/PYTHON/ADA/ and removing pieces that I don't need
2) The eclass is only for packages that I mantains exclusively and they are not such a great number

The eclass is an effort to avoid in the future the same problems raised from qa-check
All comes from a suggestion to use USE_EXPAND for gnat_2016 gnat_2017 ...

My opinion is that the ml review should be mandatory only for new eclasses that are meant to be used by all the tree or by a great number of packages (>= 100 ?)

However, as stated in the email I reverted my changes and add the eclass to the ml.

Then, what a review means, when it is approved or denied, I will try to learn

Alfredo

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Fri, 2019-09-06 at 00:47 +0200, Thomas Deutschmann wrote:
> On 2019-09-05 22:16, Michał Górny wrote:
> > > But as per the way the dev manual is written, he arguably *is*
> > > following policy.
> > > 
> > > Stop taking the line of assuming he's trying to be belligerent. 
> > 
> > He says explicitly that he is against fixing devmanual because he likes
> > the way he can abuse it right now.
> 
> You are the only one adding _abuse_ here. Stop that, thanks. When I
> replied to your mail I was just asking... nothing more. I don't
> understand why you are reading so much into it.
> 
> But yes, I like the current exception for "per-package" eclasses like I
> am concerned that a review requirement would cause a significant delay:
> 
> Back to my example, imagine we would move pkg_config to new mysql
> eclass. If we would bump mysql/percona-server/mariadb package and will
> receive bug reports later because upstream changed something causing
> pkg_config to fail we would now have to propose a patch, wait 48
> hours... i.e. package would be broken for ~72 hours just because of a
> policy I don't reject in general (yes, I like reviews) but where I think
> exceptions must be possible.

Are you really saying that if you push buggy eclass (without review?),
then you need to push yet another eclass to fix it?  If so, then it
looks like something is really wrong with your workflow.

> So for my understanding this is not about 'fixing' devmanual. It's about
> *changing* devmanual which I *just* pointed out. But whoever will
> propose changing devmanual should support such a change because he/she
> will probably have to argue for that change. Something I cannot do when
> I like status quo like I do currently or have concerns.

So you don't believe in civil duty over your private interest.  Okay,
understood.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Mike Gilbert]

On Wed, Sep 4, 2019 at 7:26 PM Thomas Deutschmann <whissi@gentoo.org> wrote:
> If you want to make it clear, change "should" to "must" and maybe
> clarify per-package exception and limit to update case if you believe
> that really *all* *new* eclasses must be send to mailing list.

As a native English speaker/writer, I find this "should" versus "must"
argument very tedious.

If a technical document says I "should" do something, and I don't do
it, I probably have very good reason for not doing it and should be
able to easily explain that reason. There's nothing wrong with that,
and calling it out on a mailing list is entirely appropriate.

If a technical document says I "must" do something, I take that
somewhat more seriously, and I expect bad things will happen if I go
against it. In the case of Gentoo, I would expect a revert with no
questions asked if the procedure is not followed.

In either case, it's clear that the advice given in the document is
something I should pay attention to.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Mike Gilbert]

On Thu, Sep 5, 2019 at 6:47 PM Thomas Deutschmann <whissi@gentoo.org> wrote:
>
> On 2019-09-05 22:16, Michał Górny wrote:
> >> But as per the way the dev manual is written, he arguably *is*
> >> following policy.
> >>
> >> Stop taking the line of assuming he's trying to be belligerent.
> >
> > He says explicitly that he is against fixing devmanual because he likes
> > the way he can abuse it right now.
>
> You are the only one adding _abuse_ here. Stop that, thanks. When I
> replied to your mail I was just asking... nothing more. I don't
> understand why you are reading so much into it.

The devmanual o clearly indicates that an email to gentoo-dev is
strongly preferred. I don't see any reason why tupone could not have
done this.

You seem to be trying to take this opportunity to prove some loosely
related point.

> But yes, I like the current exception for "per-package" eclasses like I
> am concerned that a review requirement would cause a significant delay:
>
> Back to my example, imagine we would move pkg_config to new mysql
> eclass. If we would bump mysql/percona-server/mariadb package and will
> receive bug reports later because upstream changed something causing
> pkg_config to fail we would now have to propose a patch, wait 48
> hours... i.e. package would be broken for ~72 hours just because of a
> policy I don't reject in general (yes, I like reviews) but where I think
> exceptions must be possible.

This argument is stupid. If you need to push a critical bug fix, then
do it. Nobody will fault you for it.

This clearly does not apply to ada.eclass.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1569 bytes --]

On 2019-09-05 22:16, Michał Górny wrote:
>> But as per the way the dev manual is written, he arguably *is*
>> following policy.
>>
>> Stop taking the line of assuming he's trying to be belligerent. 
>
> He says explicitly that he is against fixing devmanual because he likes
> the way he can abuse it right now.

You are the only one adding _abuse_ here. Stop that, thanks. When I
replied to your mail I was just asking... nothing more. I don't
understand why you are reading so much into it.

But yes, I like the current exception for "per-package" eclasses like I
am concerned that a review requirement would cause a significant delay:

Back to my example, imagine we would move pkg_config to new mysql
eclass. If we would bump mysql/percona-server/mariadb package and will
receive bug reports later because upstream changed something causing
pkg_config to fail we would now have to propose a patch, wait 48
hours... i.e. package would be broken for ~72 hours just because of a
policy I don't reject in general (yes, I like reviews) but where I think
exceptions must be possible.

So for my understanding this is not about 'fixing' devmanual. It's about
*changing* devmanual which I *just* pointed out. But whoever will
propose changing devmanual should support such a change because he/she
will probably have to argue for that change. Something I cannot do when
I like status quo like I do currently or have concerns.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Fri, 2019-09-06 at 08:08 +1200, Kent Fredric wrote:
> On Thu, 05 Sep 2019 21:47:11 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > So to summarize, instead of working together in order to follow a well-
> > established policy,
> 
> You're reading it wrong. If its "established policy", dev manual must
> reflect that.
> 
> If the dev-manual writes "should" in one place, and implies "must" in
> another for a same thing, then either:
> 
> - The dev manual needs to be fixed
> - The policy is not as you suggest it is.
> 
> If the dev-manual is written correctly for the policy, then I expect he
> is saying he'll follow it.

We've already established that the wording in devmanual is unfortunate,
and I've asked him to submit a patch.  It would be really nice if more
than three developers cared to actually work on devmanual which is
probably the most important document for devs.

> But as per the way the dev manual is written, he arguably *is*
> following policy.
> 
> Stop taking the line of assuming he's trying to be belligerent. 

He says explicitly that he is against fixing devmanual because he likes
the way he can abuse it right now.


-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Kent Fredric]

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

On Thu, 05 Sep 2019 21:47:11 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> So to summarize, instead of working together in order to follow a well-
> established policy,

You're reading it wrong. If its "established policy", dev manual must
reflect that.

If the dev-manual writes "should" in one place, and implies "must" in
another for a same thing, then either:

- The dev manual needs to be fixed
- The policy is not as you suggest it is.

If the dev-manual is written correctly for the policy, then I expect he
is saying he'll follow it.

But as per the way the dev manual is written, he arguably *is*
following policy.

Stop taking the line of assuming he's trying to be belligerent. 

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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michael Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 2478 bytes --]

On 05/09/19 20:47, Michał Górny wrote:
> On Thu, 2019-09-05 at 15:14 +0200, Thomas Deutschmann wrote:
>> On 2019-09-05 06:02, Michał Górny wrote:
>>>> In my case I am working on a new mysql eclass to outsource pkg_config
>>>> function which is shared at least between dev-db/mysql and
>>>> dev-db/percona-server (and maybe dev-db/mariadb).
>>>>
>>>> For this new eclass I would say it's a "per-package" eclass and would
>>>> probably have skipped mailing list review, too.
>>> Everyone can skip as many paragraphs as they want, and then apply what's
>>> said later to something said way earlier.
>> Could you please stop adding any bad interpretation?
>>
>> That was a serious question. For you, it's pretty clear. I am showing
>> you, that for me, it isn't pretty clear. When you believe I skipped
>> important lines in my quote please outline what I have missed and I will
>> take the blame.
>>
>>
>>>> If you want to make it clear, change "should" to "must" and maybe
>>>> clarify per-package exception and limit to update case if you believe
>>>> that really *all* *new* eclasses must be send to mailing list.
>>> Submit a part.  This is a community effort.  Nitpicking and complaining
>>> doesn't make things better.  Fixing them does.
>> Sure, but at the moment *you* are the one who are saying it's a MUST. I
>> don't understand it that way and I am fine with my understanding that
>> per-package eclasses *should* but *must not* get reviewed through
>> mailing list. In other words I am asking you to show us where it's
>> written that *all* *new* eclasses *must* get reviewed through mailing
>> list. I cannot find something like that in current devmanual (the link
>> you showed).
>>
>> Maybe I am still missing something after reading
>> https://devmanual.gentoo.org/eclass-writing/ 3 times...
>>
>> In case I am not missing anything I suggested to improve devmanual in
>> case you believe this should be a hard requirement. Because at the
>> moment I don't believe it should be a hard requirement, *I* will not
>> propose any changes.
>>
> So to summarize, instead of working together in order to follow a well-
> established policy, you prefer to do whatever you find convenient
> at the moment, as long as you justify it by finding some document whose
> wording does not perfectly prevent you from bending the policy?  Yes,
> that sounds like a very good attitude for a Council member.
>
Pot meet Kettle ..




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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Thu, 2019-09-05 at 15:14 +0200, Thomas Deutschmann wrote:
> On 2019-09-05 06:02, Michał Górny wrote:
> > > In my case I am working on a new mysql eclass to outsource pkg_config
> > > function which is shared at least between dev-db/mysql and
> > > dev-db/percona-server (and maybe dev-db/mariadb).
> > > 
> > > For this new eclass I would say it's a "per-package" eclass and would
> > > probably have skipped mailing list review, too.
> > 
> > Everyone can skip as many paragraphs as they want, and then apply what's
> > said later to something said way earlier.
> 
> Could you please stop adding any bad interpretation?
> 
> That was a serious question. For you, it's pretty clear. I am showing
> you, that for me, it isn't pretty clear. When you believe I skipped
> important lines in my quote please outline what I have missed and I will
> take the blame.
> 
> 
> > > If you want to make it clear, change "should" to "must" and maybe
> > > clarify per-package exception and limit to update case if you believe
> > > that really *all* *new* eclasses must be send to mailing list.
> > 
> > Submit a part.  This is a community effort.  Nitpicking and complaining
> > doesn't make things better.  Fixing them does.
> 
> Sure, but at the moment *you* are the one who are saying it's a MUST. I
> don't understand it that way and I am fine with my understanding that
> per-package eclasses *should* but *must not* get reviewed through
> mailing list. In other words I am asking you to show us where it's
> written that *all* *new* eclasses *must* get reviewed through mailing
> list. I cannot find something like that in current devmanual (the link
> you showed).
> 
> Maybe I am still missing something after reading
> https://devmanual.gentoo.org/eclass-writing/ 3 times...
> 
> In case I am not missing anything I suggested to improve devmanual in
> case you believe this should be a hard requirement. Because at the
> moment I don't believe it should be a hard requirement, *I* will not
> propose any changes.
> 

So to summarize, instead of working together in order to follow a well-
established policy, you prefer to do whatever you find convenient
at the moment, as long as you justify it by finding some document whose
wording does not perfectly prevent you from bending the policy?  Yes,
that sounds like a very good attitude for a Council member.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[James Le Cuirot]

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

On Fri, 6 Sep 2019 07:26:42 +1200
Kent Fredric <kentnl@gentoo.org> wrote:

> On Thu, 5 Sep 2019 09:04:23 -0500
> Gordon Pettey <petteyg359@gmail.com> wrote:
> 
> > You'll note the bit you quoted in defense of skipping review says
> > "changes", and the bit about new eclasses says "do not skip this step".  
> 
> Emphasis added:
> 
> -----
> BEFORE committing a NEW eclass to the tree, it SHOULD be emailed to the
> gentoo-dev mailing list with a justification and a proposed
> implementation. DO NOT SKIP this step — sometimes a better
> implementation or an alternative which does not require a new eclass
> will be suggested. 
> -----
> 
> 
> If its mandatory, it must say "MUST" not "SHOULD", SHOULD is a
> suggestion, following a suggestion with an imperative just adds
> predictable confusion.
> 
> Either fix the "should", or drop the "DO NOT SKIP".
> 
> Otherwise you're just giving mixed messages.

+1

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Kent Fredric]

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

On Thu, 5 Sep 2019 09:04:23 -0500
Gordon Pettey <petteyg359@gmail.com> wrote:

> You'll note the bit you quoted in defense of skipping review says
> "changes", and the bit about new eclasses says "do not skip this step".

Emphasis added:

-----
BEFORE committing a NEW eclass to the tree, it SHOULD be emailed to the
gentoo-dev mailing list with a justification and a proposed
implementation. DO NOT SKIP this step — sometimes a better
implementation or an alternative which does not require a new eclass
will be suggested. 
-----


If its mandatory, it must say "MUST" not "SHOULD", SHOULD is a
suggestion, following a suggestion with an imperative just adds
predictable confusion.

Either fix the "should", or drop the "DO NOT SKIP".

Otherwise you're just giving mixed messages.

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Gordon Pettey]

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

On Thu, Sep 5, 2019 at 8:15 AM Thomas Deutschmann <whissi@gentoo.org> wrote:

> On 2019-09-05 06:02, Michał Górny wrote:
> >> In my case I am working on a new mysql eclass to outsource pkg_config
> >> function which is shared at least between dev-db/mysql and
> >> dev-db/percona-server (and maybe dev-db/mariadb).
> >>
> >> For this new eclass I would say it's a "per-package" eclass and would
> >> probably have skipped mailing list review, too.
> >
> > Everyone can skip as many paragraphs as they want, and then apply what's
> > said later to something said way earlier.
>
> Could you please stop adding any bad interpretation?
>
> That was a serious question. For you, it's pretty clear. I am showing
> you, that for me, it isn't pretty clear. When you believe I skipped
> important lines in my quote please outline what I have missed and I will
> take the blame.
>

You'll note the bit you quoted in defense of skipping review says
"changes", and the bit about new eclasses says "do not skip this step".

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 2020 bytes --]

On 2019-09-05 06:02, Michał Górny wrote:
>> In my case I am working on a new mysql eclass to outsource pkg_config
>> function which is shared at least between dev-db/mysql and
>> dev-db/percona-server (and maybe dev-db/mariadb).
>>
>> For this new eclass I would say it's a "per-package" eclass and would
>> probably have skipped mailing list review, too.
> 
> Everyone can skip as many paragraphs as they want, and then apply what's
> said later to something said way earlier.

Could you please stop adding any bad interpretation?

That was a serious question. For you, it's pretty clear. I am showing
you, that for me, it isn't pretty clear. When you believe I skipped
important lines in my quote please outline what I have missed and I will
take the blame.


>> If you want to make it clear, change "should" to "must" and maybe
>> clarify per-package exception and limit to update case if you believe
>> that really *all* *new* eclasses must be send to mailing list.
> 
> Submit a part.  This is a community effort.  Nitpicking and complaining
> doesn't make things better.  Fixing them does.

Sure, but at the moment *you* are the one who are saying it's a MUST. I
don't understand it that way and I am fine with my understanding that
per-package eclasses *should* but *must not* get reviewed through
mailing list. In other words I am asking you to show us where it's
written that *all* *new* eclasses *must* get reviewed through mailing
list. I cannot find something like that in current devmanual (the link
you showed).

Maybe I am still missing something after reading
https://devmanual.gentoo.org/eclass-writing/ 3 times...

In case I am not missing anything I suggested to improve devmanual in
case you believe this should be a hard requirement. Because at the
moment I don't believe it should be a hard requirement, *I* will not
propose any changes.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Thu, 2019-09-05 at 01:26 +0200, Thomas Deutschmann wrote:
> Hi,
> 
> On 2019-09-04 20:59, Michał Górny wrote:
> > Devmanual is pretty clear on the fact that *all* new eclasses require ml
> >                                       ^^^^^^^^^^^^^^^^^^^^^^^
> > review *before* committing:
> 
> I am also working on a new eclass so I looked up details regarding
> what's needed to add a new eclass recently.
> 
> I must say that I disagree that it's *pretty* clear.
> 
> > Adding and Updating Eclasses
> > 
> > Before committing a new eclass to the tree, it should be emailed
> >                                                ^^^^^^
> > to the gentoo-dev mailing list with a justification and a
> > proposed implementation. Do not skip this step — sometimes a
> > better implementation or an alternative which does not require a
> > new eclass will be suggested.
> > 
> > Before updating [...]
> > 
> > The exceptions to this rule are per-package eclasses. For
> >                                 ^^^^^^^^^^^^^^^^^^^^
> > example, the apache-2 eclass is only used by the www-servers/apache
> > package, and thus does not typically require changes to be emailed
> > for review.
> 
> In my case I am working on a new mysql eclass to outsource pkg_config
> function which is shared at least between dev-db/mysql and
> dev-db/percona-server (and maybe dev-db/mariadb).
> 
> For this new eclass I would say it's a "per-package" eclass and would
> probably have skipped mailing list review, too.

Everyone can skip as many paragraphs as they want, and then apply what's
said later to something said way earlier.

> 
> If you want to make it clear, change "should" to "must" and maybe
> clarify per-package exception and limit to update case if you believe
> that really *all* *new* eclasses must be send to mailing list.

Submit a part.  This is a community effort.  Nitpicking and complaining
doesn't make things better.  Fixing them does.

> 
> 

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1715 bytes --]

Hi,

On 2019-09-04 20:59, Michał Górny wrote:
> Devmanual is pretty clear on the fact that *all* new eclasses require ml
>                                       ^^^^^^^^^^^^^^^^^^^^^^^
> review *before* committing:

I am also working on a new eclass so I looked up details regarding
what's needed to add a new eclass recently.

I must say that I disagree that it's *pretty* clear.

> Adding and Updating Eclasses
>
> Before committing a new eclass to the tree, it should be emailed
>                                                ^^^^^^
> to the gentoo-dev mailing list with a justification and a
> proposed implementation. Do not skip this step — sometimes a
> better implementation or an alternative which does not require a
> new eclass will be suggested.
>
> Before updating [...]
>
> The exceptions to this rule are per-package eclasses. For
>                                 ^^^^^^^^^^^^^^^^^^^^
> example, the apache-2 eclass is only used by the www-servers/apache
> package, and thus does not typically require changes to be emailed
> for review.

In my case I am working on a new mysql eclass to outsource pkg_config
function which is shared at least between dev-db/mysql and
dev-db/percona-server (and maybe dev-db/mariadb).

For this new eclass I would say it's a "per-package" eclass and would
probably have skipped mailing list review, too.

If you want to make it clear, change "should" to "must" and maybe
clarify per-package exception and limit to update case if you believe
that really *all* *new* eclasses must be send to mailing list.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[David Seifert]

On Wed, 2019-09-04 at 20:59 +0200, Michał Górny wrote:
> On Wed, 2019-09-04 at 18:00 +0000, Alfredo Tupone wrote:
> > commit:     63486fef43c2e0dee3b4128db18fd1a6b4bf9381
> > Author:     Tupone Alfredo <tupone <AT> gentoo <DOT> org>
> > AuthorDate: Wed Sep  4 17:58:49 2019 +0000
> > Commit:     Alfredo Tupone <tupone <AT> gentoo <DOT> org>
> > CommitDate: Wed Sep  4 17:58:49 2019 +0000
> > URL:        
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=63486fef
> > 
> > ada.eclass: New eclass for dev-ada packages
> > 
> > Signed-off-by: Alfredo Tupone <tupone <AT> gentoo.org>
> > 
> >  eclass/ada.eclass | 431
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 431 insertions(+)
> > 
> 
> Devmanual is pretty clear on the fact that *all* new eclasses require
> ml
> review *before* committing:
> 
> https://devmanual.gentoo.org/eclass-writing/index.html
> 

Please revert.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Wed, 2019-09-04 at 18:00 +0000, Alfredo Tupone wrote:
> commit:     63486fef43c2e0dee3b4128db18fd1a6b4bf9381
> Author:     Tupone Alfredo <tupone <AT> gentoo <DOT> org>
> AuthorDate: Wed Sep  4 17:58:49 2019 +0000
> Commit:     Alfredo Tupone <tupone <AT> gentoo <DOT> org>
> CommitDate: Wed Sep  4 17:58:49 2019 +0000
> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=63486fef
> 
> ada.eclass: New eclass for dev-ada packages
> 
> Signed-off-by: Alfredo Tupone <tupone <AT> gentoo.org>
> 
>  eclass/ada.eclass | 431 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 431 insertions(+)
> 

Devmanual is pretty clear on the fact that *all* new eclasses require ml
review *before* committing:

https://devmanual.gentoo.org/eclass-writing/index.html

-- 
Best regards,
Michał Górny


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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Matt Turner]

On Mon, Jul 29, 2019 at 10:20 PM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Tue, 2019-07-30 at 01:49 +0000, Matt Turner wrote:
> > commit:     6f680e4fe73925ae130343e02adb416cb799ce7d
> > Author:     Chris Mayo <aklhfex <AT> gmail <DOT> com>
> > AuthorDate: Fri Jul 26 18:48:13 2019 +0000
> > Commit:     Matt Turner <mattst88 <AT> gentoo <DOT> org>
> > CommitDate: Tue Jul 30 01:49:41 2019 +0000
> > URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f680e4f
> >
> > virtualx.eclass: Fix no display for an emerge following a failure
> >
> > If using GNOME GDM, X is started on DISPLAY :0 but a lock file
> > /tmp/.X1024-lock is created instead of /tmp/.X0-lock.
> > virtx() will initially set XDISPLAY to 0 and attempt to start Xvfb on
> > DISPLAY :0 which fails but DISPLAY :1 (and greater) is not attempted if
> > a previous emerge left /tmp/.X1-lock behind.
> >
> > Closes: https://bugs.gentoo.org/690778
> > Signed-off-by: Chris Mayo <aklhfex <AT> gmail.com>
> > Signed-off-by: Matt Turner <mattst88 <AT> gentoo.org>
> >
> >  eclass/virtualx.eclass | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
> > index fb6a867a35c..40eeea5463b 100644
> > --- a/eclass/virtualx.eclass
> > +++ b/eclass/virtualx.eclass
> > @@ -1,4 +1,4 @@
> > -# Copyright 1999-2018 Gentoo Foundation
> > +# Copyright 1999-2019 Gentoo Authors
> >  # Distributed under the terms of the GNU General Public License v2
> >
> >  # @ECLASS: virtualx.eclass
> > @@ -178,7 +178,10 @@ virtx() {
> >       # Xvfb is started, else bump the display number
> >       #
> >       # Azarah - 5 May 2002
> > -     XDISPLAY=$(i=0; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; echo ${i})
> > +     # GNOME GDM may have started X on DISPLAY :0 with a
> > +     # lock file /tmp/.X1024-lock, therefore start the search at 1.
> > +     # Else a leftover /tmp/.X1-lock will prevent finding an available display.
> > +     XDISPLAY=$(i=1; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; echo ${i})
> >       debug-print "${FUNCNAME}: XDISPLAY=${XDISPLAY}"
> >
> >       # We really do not want SANDBOX enabled here
>
> Isn't this a cheap hack that doesn't fix the underlying issue but shifts
> the problem into hopefully-won't-happen-this-time?

Yes, but given that the prior code was a cheap hack as well (from
2002, no less!) and has worked out well enough for 17 years that no
one has reported problems with it until now, I don't think it's
critical to make it bullet-proof.

Of course I'm happy to accept patches.

> Also, why are you skipping mailing list review for eclass changes?

Ah, you are right. My apologies.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Tue, 2019-07-30 at 01:49 +0000, Matt Turner wrote:
> commit:     6f680e4fe73925ae130343e02adb416cb799ce7d
> Author:     Chris Mayo <aklhfex <AT> gmail <DOT> com>
> AuthorDate: Fri Jul 26 18:48:13 2019 +0000
> Commit:     Matt Turner <mattst88 <AT> gentoo <DOT> org>
> CommitDate: Tue Jul 30 01:49:41 2019 +0000
> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f680e4f
> 
> virtualx.eclass: Fix no display for an emerge following a failure
> 
> If using GNOME GDM, X is started on DISPLAY :0 but a lock file
> /tmp/.X1024-lock is created instead of /tmp/.X0-lock.
> virtx() will initially set XDISPLAY to 0 and attempt to start Xvfb on
> DISPLAY :0 which fails but DISPLAY :1 (and greater) is not attempted if
> a previous emerge left /tmp/.X1-lock behind.
> 
> Closes: https://bugs.gentoo.org/690778
> Signed-off-by: Chris Mayo <aklhfex <AT> gmail.com>
> Signed-off-by: Matt Turner <mattst88 <AT> gentoo.org>
> 
>  eclass/virtualx.eclass | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
> index fb6a867a35c..40eeea5463b 100644
> --- a/eclass/virtualx.eclass
> +++ b/eclass/virtualx.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2018 Gentoo Foundation
> +# Copyright 1999-2019 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: virtualx.eclass
> @@ -178,7 +178,10 @@ virtx() {
>  	# Xvfb is started, else bump the display number
>  	#
>  	# Azarah - 5 May 2002
> -	XDISPLAY=$(i=0; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; echo ${i})
> +	# GNOME GDM may have started X on DISPLAY :0 with a
> +	# lock file /tmp/.X1024-lock, therefore start the search at 1.
> +	# Else a leftover /tmp/.X1-lock will prevent finding an available display.
> +	XDISPLAY=$(i=1; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; echo ${i})
>  	debug-print "${FUNCNAME}: XDISPLAY=${XDISPLAY}"
>  
>  	# We really do not want SANDBOX enabled here

Isn't this a cheap hack that doesn't fix the underlying issue but shifts
the problem into hopefully-won't-happen-this-time?

Also, why are you skipping mailing list review for eclass changes?

-- 
Best regards,
Michał Górny


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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

W dniu pią, 18.05.2018 o godzinie 20∶36 +0000, użytkownik Andreas
Sturmlechner napisał:
> commit:     d780c05e4459175eb314c82de9f3b998e2b4fc6e
> Author:     Andreas Sturmlechner <asturm <AT> gentoo <DOT> org>
> AuthorDate: Thu May 10 20:42:15 2018 +0000
> Commit:     Andreas Sturmlechner <asturm <AT> gentoo <DOT> org>
> CommitDate: Fri May 18 20:36:12 2018 +0000
> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d780c05e
> 
> cmake-utils.eclass: Switch to eapi7-ver
> 
>  eclass/cmake-utils.eclass | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index 3302f27608b..cbce280625e 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -109,11 +109,11 @@ case ${EAPI} in
>  	*) die "EAPI=${EAPI:-0} is not supported" ;;
>  esac
>  
> -inherit toolchain-funcs ninja-utils flag-o-matic multiprocessing versionator xdg-utils
> +inherit toolchain-funcs ninja-utils flag-o-matic multiprocessing xdg-utils
>  
>  case ${EAPI} in
>  	7) ;;
> -	*) inherit eutils multilib ;;
> +	*) inherit eapi7-ver eutils multilib ;;
>  esac
>  
>  EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install
> @@ -512,7 +512,7 @@ cmake-utils_src_configure() {
>  	# we need to add "<INCLUDES>"
>  	local includes=
>  	if [[ ${PN} == cmake ]] ; then
> -		if $(version_is_at_least 3.4.0 $(get_version_component_range 1-3 ${PV})) ; then
> +		if $(version_is_at_least 3.4.0 $(ver_cut 1-3 ${PV})) ; then

One of the reasons we do mailing list reviews of widely used eclasses is
to let people tell you that you've left 'version_is_at_least' here.

>  			includes="<INCLUDES>"
>  		fi
>  	elif ROOT=/ has_version \>=dev-util/cmake-3.4.0_rc1 ; then
> 

-- 
Best regards,
Michał Górny

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

W dniu pią, 05.01.2018 o godzinie 13∶13 +0000, użytkownik Lars Wendler
napisał:
> commit:     1e09cba657ccb2b8e6fbcbeb28c5c593da2127eb
> Author:     Gary Macindoe <gary <AT> garymacindoe <DOT> co <DOT> uk>
> AuthorDate: Thu Sep 28 21:32:34 2017 +0000
> Commit:     Lars Wendler <polynomial-c <AT> gentoo <DOT> org>
> CommitDate: Fri Jan  5 13:13:40 2018 +0000
> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1e09cba6
> 
> Fix handling of multiple CDs
> 
> Closes: https://github.com/gentoo/gentoo/pull/5818
> 
>  eclass/cdrom.eclass | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
> index 47e2c6342e0..7b0eb9c6c3b 100644
> --- a/eclass/cdrom.eclass
> +++ b/eclass/cdrom.eclass
> @@ -71,7 +71,12 @@ fi
>  # eclass, see that function's description.
>  cdrom_get_cds() {
>  	unset CDROM_SET
> -	export CDROM_CURRENT_CD=0 CDROM_CHECKS=( "${@}" )
> +	export CDROM_CURRENT_CD=0
> +    export CDROM_NUM_CDS="${#}"
> +    local i
> +    for i in $(seq ${#}); do
> +        export CDROM_CHECK_${i}="${!i}"
> +    done

Please fix the indentation.

>  
>  	# If the user has set CD_ROOT or CD_ROOT_1, don't bother informing
>  	# them about which discs are needed as they presumably already know.
> @@ -190,7 +195,8 @@ cdrom_load_next_cd() {
>  		local i cdset
>  		: CD_ROOT_${CDROM_CURRENT_CD}
>  		export CDROM_ROOT=${CD_ROOT:-${!_}}
> -		IFS=: read -r -a cdset -d "" <<< "${CDROM_CHECKS[$((${CDROM_CURRENT_CD} - 1))]}"
> +		local var="CDROM_CHECK_${CDROM_CURRENT_CD}"
> +		IFS=: read -r -a cdset -d "" <<< "${!var}"
>  
>  		for i in $(seq ${CDROM_SET:-0} ${CDROM_SET:-$((${#cdset[@]} - 1))}); do
>  			local f=${cdset[${i}]} point= node= fs= opts=
> @@ -222,7 +228,7 @@ cdrom_load_next_cd() {
>  		fi
>  
>  		if [[ ${showedmsg} -eq 0 ]] ; then
> -			if [[ ${#CDROM_CHECKS[@]} -eq 1 ]] ; then
> +			if [[ ${CDROM_NUM_CDS} -eq 1 ]] ; then
>  				einfo "Please insert+mount the ${CDROM_NAME:-CD for ${PN}} now !"
>  			else
>  				local var="CDROM_NAME_${CDROM_CURRENT_CD}"
> 

This looks like a major change which also pretty much reverts
the direction the previous (ml-reviewed) patches took. As such,
it would be really desirable to post it for review instead of stealthily
committing to an eclass which -- as far as metadata says -- you aren't
even maintainer of.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Luis Ressel]

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

On Sun, 21 May 2017 10:46:25 -0700
Raymond Jennings <shentino@gmail.com> wrote:

> Just out of curiosity, and for the curious:
> 
> 1.  How often do cache updates happen?
> 2.  How long do they take?
> 3.  Is there any downside to only having one such update running at a
> time and just skipping them if there's already an update pending?

I'm generating metadata locally. There are changes to some of the more
important eclasses roughly every other week; and after such a change,
the regen takes 10-25 minutes on my hardware.

I don't understand your question (3).

Regards,
Luis Ressel

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 184 bytes --]

On 21/05/17 20:32, Kent Fredric wrote:
> But I'd also like a pony.
>
I'm hoping for a unicorn still ...

[apologies, resending as hit the wrong button in the Compose button..]


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

[-- Attachment #1: PGP/MIME version identification --]
[-- Type: application/pgp-encrypted, Size: 11 bytes --]

[-- Attachment #2: OpenPGP encrypted message --]
[-- Type: application/octet-stream, Size: 2462 bytes --]

-----BEGIN PGP MESSAGE-----

hQIMA+SFlLe9WJ5DAQ//eAfIsZXFSI1pptkTgEkxUZIvCNLIxtLjCRel9xHSlg2v
BMXoggVDhHPXf6kq6GSwTH7O59bacRAaEWQBuNYvg/XE/e8UvPVTQ9rXSWltqo88
rLEOZvtapWNzAoHchDVky5aUg7dJVNEodEd+doBqo2GQpwjAtzYr4al9CEMphtWJ
HhKnfRbsG3Wx0TNRnX+rZST4slFik3He5cB+EJmHdub7yu/jSavdWjhQ3QHZhjRa
7OR09TcPeOpgvWG+u7+ta+H58dK3cVTES8Mmlp9UTfN2unoKTXXadHV6X6fy0uVR
/d5UpZ9WgCXFrXbVHhDWRul8aQyDpJHeuKh+qFpVM4s/WYJb2Vs0eRMWnRotiP1Z
ajnw0FGKspCSoAzpOF0qsBH+j0rCgHETHkChjaSWHGLhQUnSU0MTZZzAfyvkMoG5
WinMu/L3Ef9e2q7gBgn5inEKFCHCis/sSCMYQYoGtmvmcto7TZcOc2NaeYuYi4i6
/2DWNXtBz2KTU7udzaoeHOvoY+evZ5jfKd4pNNjeIc+Ctju3KMiaW32iLK91w4Ui
hwe98+nzaxyCwi267mI2mz0WtwEsTLP4/yX7vwKGBgKuo4owwmirneLyfdm8YOxU
7nS+BSpiJEXOQPa1ocpShMBnyNNGNvD1y1CZHYzdv88Z9AfgkQJnspP+Rwt+dEGF
AgwDNYPyd/z2VyQBD/9RLRIUEpj0gi6VLYOaEyIUjyODhoWGJTAiSgtxZ80WXd8y
QLeb2/97YEIaPVo/s2pxJry6vri9be360fSMgjXZEraeK2GjqRpsEiJfp8PNft1g
VGpwEaE8MifNz3hrNdz5Wm/fnc6V9EyeDqdmYPwi99Lgj9XYo9qFwUs0ivGU1sHU
JyPQOxiKMdKR1B2gGFBw/NI1bGgRnd99I3Fg+Ba/YPJr6EQYpGzrm8/lMd4Onn98
JqsNQtb/mowrfFewd2dpGkFMS/vwLvE3CeZO6tFVjumozwbW1nrviZiRdyMAOlqS
outFmmOINHyIoEGdzVes7r54LM/a6aAIsgaMnknLxMf9YqB/phqzrBrBUj3lJrwj
/kdgPFvfMgjnCnG3gUKkCzo0bWpB3s+RVFmW4oCpZJH96sQy3J7jfiquYUl5N2L+
BsV/nGV4ZDmeNf70BVDiibY1hry7sZmBQfOV5FOtmIifTVZTyYWyBRMCDiE/P/jI
nBqFH47H1XSU0wpaZDCIp8RmYEqSg8BkT6r5QC3ljAtwgNdrnyaprFIWGOYsYTUK
s89kSIqURgIlldJa/1CJL8+QTOWgOmPQKmZ7AMJFkuEvbP0HbFjuk6dDZsKBKoag
AgyrUitSKjJZWl85WH+0GqICoNtIUoQsrgChBwqLQDmk6yqnrLaYlQGvoKcjD9Lp
AVamaQSiyFdqSw3gMEX8yvhEPKYSYJYUCkNfoya3ERWA8v3S83uhCQg5/S/0yhLt
lklOjHNIpNpE52wxv6WGKb5tzYOfRX2TdyAKuiMCf+FCBHYB6gGpV0Azwh03KoDf
/g+/n44muhSOIZQiuWeUBgAwEQLhe46afvjC9iHueG1fIdyoUWP6QI3CoWk1PR+E
XSAydaZE3AMkeix4zted/Atd1bg7/3SYYeyLwiIh8ANvbVqRxubuX1CcaGigyHss
4Gi3IjPhI3wF+94Bgv2pZCn4/+kFae4/yYsALDxBAEY3okG05rnLhfEw8mu1jncD
0aiMhkg9O8djlIlRrk3O9j13U9DRHLwYGYWhceixu4Z0zUuGbHJQ8he5VNTLhzaY
jfYm7x2HsOuvnOovYr4RWRi378YorY6DMvT71w4e67NQt1HXAPioAYfmygXFNkWk
1BDUBi/lf+aZRh/o37b5mY8mDVQJOdLy8fyyvXpkaQayPpFXxFavdrSAn5Nm4rJj
zNFihvjY3QGwm8L1FWTGSp2qo7Y5eRptnE4FaPhnI2wjZfQAqM6yDXVCDDcLn+P0
1AaiesfHo+5QrU7yr5swhbai+CJRGbmrhNDsHYCXfGuTNUQ88Iit+r0xMmJiYDsj
rzLNKR8hzVSNJye4fyOcq4ocsI9tdVtv7ofmv1HqYD7AC2T3sXw/WK68JBR/08l4
Ww1LZDSqeG/PNyppkSnaAKUBlgocYP+yFif9RRECLBG5smxbqF4BPDYB24rLCiqw
cfrnXsAOKTh4vVG4tROb3iG9bi30h0IxSqj7/btiiVetNpY2gB4PIFWVuTXd3Cq/
8vVJN1SgsKl7S9tQ972Lt+iTl84yU9zm9Fg3bw65/UdenPWru0/la66IZRv9YoH2
k7N4XFUNtUDMqfIaNZdIay3+FVQtXPHKUWQWwf/1vjX9LYJaor26LaG9kKoi
=AOlz
-----END PGP MESSAGE-----

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Kent Fredric]

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

On Sun, 21 May 2017 19:34:26 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Like, by not using eclasses and instead inlining all the stuff?

I'd personally suggest we endeavour towards making systems in place so
that the performance overheads of metadata generation is much lower, to
the point it can be done efficiently without needing cache
provisioning.

But I'd also like a pony.

( I have ideas using daemons, inotify, and persistent databases as the
primary metadata layer instead of millions of files, but they're all
too complicated and hard )

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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Martin Vaeth]

Michał Górny <mgorny@gentoo.org> wrote:
>> If this is such a big problem, maybe we should be discussing how to
>> redesign things to improve it?
>
> Like, by not using eclasses and instead inlining all the stuff?

There are other ways.

One way to mitigate the problem might be to require that
eclasses contain some

# @VERSION: major.minor-revision

line and that the metadata cache of an ebuild contains that version
number (or at least the major component of it) instead of an md5 sum.
Then the commiter of the eclass has full control whether a metadata
regeneration will happen or not:

For trivial changes (see below), the committer simply does not
increase that version number (or increase only minor-revision),
and one could agree that a rebuild of the metadata only happens
if the major version number of an eclass changes.

By "trivial changes" I mean in this connection not only changes
in comments but also minor changes in functionality or even in
the API: The only strict requirement is that the major version
has to increase if the eclass change can induce a change in the
metadata of some ebuild using it (e.g. if a value printed by
some function changes which might involve IUSE, REQUIRED_USE,
DEPEND, ...)

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Raymond Jennings]

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

On Tue, May 16, 2017 at 12:20 PM, Michał Górny <mgorny@gentoo.org> wrote:

> Mike,
>
> I would really appreciate if you cared to follow procedures for eclass
> changes. Most notably, if you at least bothered to either ping us *or*
> sent the patch to the mailing list beforehand.
>
> This eclass is used by almost 6700 ebuilds. I am trying *hard* to commit
> changes in large patchsets to reduce cache updates. Of course it is all
> pointless if a random Mike Frysinger, developer on special rights, goes
> ahead and commits whatever he wants to whatever eclasses he wants to
> commit to, whatever time he pleases.
>
> Normally, I would revert it but I don't feel like causing third huge
> cache update today.
>

Just out of curiosity, and for the curious:

1.  How often do cache updates happen?
2.  How long do they take?
3.  Is there any downside to only having one such update running at a time
and just skipping them if there's already an update pending?

>
> --
> Best regards,
> Michał Górny
>

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On nie, 2017-05-21 at 11:29 -0500, William Hubbs wrote:
> On Sun, May 21, 2017 at 02:46:54PM +0000, Martin Vaeth wrote:
> > Kent Fredric <kentnl@gentoo.org> wrote:
> > > Fabian Groffen <grobian@gentoo.org> wrote:
> > > 
> > > >  Hardware or more deltas to
> > > > download by users?  Just wondering.
> > > 
> > > Both.
> > > 
> > > - End users using git end up having to do massive metadata-updates.
> > > - Infra needs to have massive hits to metadata regeneration
> > > - End users using rsync have to fetch large deltas
> > 
> >   - Users using git repositories with pre-generated metadata have to
> >     download/store much more history data
> 
> If this is such a big problem, maybe we should be discussing how to
> redesign things to improve it?
> 

Like, by not using eclasses and instead inlining all the stuff?


-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[William Hubbs]

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

On Sun, May 21, 2017 at 02:46:54PM +0000, Martin Vaeth wrote:
> Kent Fredric <kentnl@gentoo.org> wrote:
> > Fabian Groffen <grobian@gentoo.org> wrote:
> >
> >>  Hardware or more deltas to
> >> download by users?  Just wondering.
> >
> > Both.
> >
> > - End users using git end up having to do massive metadata-updates.
> > - Infra needs to have massive hits to metadata regeneration
> > - End users using rsync have to fetch large deltas
> 
>   - Users using git repositories with pre-generated metadata have to
>     download/store much more history data

If this is such a big problem, maybe we should be discussing how to
redesign things to improve it?

William

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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Martin Vaeth]

Kent Fredric <kentnl@gentoo.org> wrote:
> Fabian Groffen <grobian@gentoo.org> wrote:
>
>>  Hardware or more deltas to
>> download by users?  Just wondering.
>
> Both.
>
> - End users using git end up having to do massive metadata-updates.
> - Infra needs to have massive hits to metadata regeneration
> - End users using rsync have to fetch large deltas

  - Users using git repositories with pre-generated metadata have to
    download/store much more history data

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Kent Fredric]

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

On Tue, 16 May 2017 21:36:15 +0200
Fabian Groffen <grobian@gentoo.org> wrote:

>  Hardware or more deltas to
> download by users?  Just wondering.

Both.

- End users using git end up having to do massive metadata-updates.
- Infra needs to have massive hits to metadata regeneration
- End users using rsync have to fetch large deltas

So its all-round sadness :(

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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Fabian Groffen]

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

On 16-05-2017 21:20:01 +0200, Michał Górny wrote:
> This eclass is used by almost 6700 ebuilds. I am trying *hard* to commit
> changes in large patchsets to reduce cache updates.
[snip]
> Normally, I would revert it but I don't feel like causing third huge
> cache update today.

What is the actual problem with that?  Hardware or more deltas to
download by users?  Just wondering.

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level

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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

Mike,

On wto, 2017-05-16 at 19:10 +0000, Mike Frysinger wrote:
> commit:     d1b05bcf81e5058c20615179fb83a90c45daa487
> Author:     Mike Frysinger <vapier <AT> chromium <DOT> org>
> AuthorDate: Tue May  9 02:34:53 2017 +0000
> Commit:     Mike Frysinger <vapier <AT> gentoo <DOT> org>
> CommitDate: Tue May 16 19:10:31 2017 +0000
> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d1b05bcf
> 
> python-utils-r1.eclass: add more info to stub python wrappers
> 
> The short terse error messages here are not easy to track down.  Add
> a few more details so people can figure out what's going wrong faster.
> 
>  eclass/python-utils-r1.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index c1349ff277b..0bf7e7ec1a3 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -1041,7 +1041,7 @@ python_wrapper_setup() {
>  		for x in "${nonsupp[@]}"; do
>  			cat >"${workdir}"/bin/${x} <<-_EOF_ || die
>  				#!/bin/sh
> -				echo "${x} is not supported by ${EPYTHON}" >&2
> +				echo "${ECLASS}: ${FUNCNAME}: ${x} is not supported by ${EPYTHON} (PYTHON_COMPAT)" >&2
>  				exit 127
>  			_EOF_
>  			chmod +x "${workdir}"/bin/${x} || die

I would really appreciate if you cared to follow procedures for eclass
changes. Most notably, if you at least bothered to either ping us *or*
sent the patch to the mailing list beforehand.

This eclass is used by almost 6700 ebuilds. I am trying *hard* to commit
changes in large patchsets to reduce cache updates. Of course it is all
pointless if a random Mike Frysinger, developer on special rights, goes
ahead and commits whatever he wants to whatever eclasses he wants to
commit to, whatever time he pleases.

Normally, I would revert it but I don't feel like causing third huge
cache update today.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andreas K. Huettel]

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

Am Montag, 16. Mai 2016, 18:21:27 schrieb Andrew Savchenko:
>
> Everyone can and will make mistakes, this is normal. Only those who
> do nothing make no mistakes. I see no reason why developer should
> be discouraged from contributing for a single blunder. Of course,
> if blunder rate is too high, comrel should take an action; but this
> is not the case here.
> 

Just for the record, this is where qa should step in, not comrel. 

- -- 

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXOfYWXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkx8UP/RyUttstbaWVUMiAQ1gZBYeh
Ry93bojoZ+nV/H/vjVOGb6f2X2TtbyOx4c8krm/QekA/pMZCppn1oIpNRRaZdoPN
TB165er/86NzXmoez9Hq5HFVFNbT56SFSyiTTT8uzbn2/phOsWy1FkwRD1Fjs4OA
x9TZgrlFrnfwMlUHhtjbVQTuz0Cn+SYo1HSZ61hV5Y1YLm8MwSWZoS1mRDp65rD/
G5umBuhTHQplBY/ZBdvuR2R8/6/hQQfqI7E7wEj5MvUp98nReJjtYSP3c8WWQYhg
3OeGzyO+USIBGciSXu01ZUGQE4r7XnJ7uiq84wbp1PTVWXYCd8G6tmF7dMzgK8EO
GfCfQuDNIAFgJSzIT0u0D1VltX47kdaWVzpet8qsjP+Ucr4cMvYyaDkrTP7cg0cY
8viaMpG3skVsiDRxRBy/E0mBbl0NxzSehZVxGV9x7f/lfsN8WIIlxID4RfisAWPf
haXtclEKppbK9BdHXrBCYKFOBd0botAjYQhGylhwtnM/22N7v5SaHRezV7qaWYhw
VsQiPht9NCZxkG9yVe/sz1J34YtQ8pB/qG2FJ+A7GQd8fjsay3M75UBQ2AJDLLhf
CUOuyLCfZySMbdCPzPw4XevpMEsADnOMd6bal5uyUxQ2SvFDR0ub04mDf52p81Cd
Qme479L9QJk3gKHzoGBw
=uk3n
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andrew Savchenko]

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

On Mon, 16 May 2016 10:05:33 +0100 Ciaran McCreesh wrote:
> On Mon, 16 May 2016 15:56:01 +0800
> Ian Delaney <idella4@gentoo.org> wrote:
> > As long as this persists and is not intervened to polish and tidy up,
> > g-devs will persist in making innocent, naive or incompetent blunders
> > and run the gauntlet of being publicly scolded over errata. I can only
> > express my view that this style of personal demeaning potentially
> > results in embarrassment, public humiliation and drives community
> > members away from participation. The ultimate negative influence. I
> > would never entertain taking on eclass writing with the incumbent qa
> > member delivering assessments under the title of 'code review' in the
> > style he does.
> 
> If you're writing the kind of code that results in you being subjected
> to scathing criticism for breaking metadata generation for the entire
> tree, then discouraging you from contributing can only be good for the
> distribution...
 
Everyone can and will make mistakes, this is normal. Only those who
do nothing make no mistakes. I see no reason why developer should
be discouraged from contributing for a single blunder. Of course,
if blunder rate is too high, comrel should take an action; but this
is not the case here.



Best regards,
Andrew Savchenko

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ciaran McCreesh]

On Mon, 16 May 2016 15:56:01 +0800
Ian Delaney <idella4@gentoo.org> wrote:
> As long as this persists and is not intervened to polish and tidy up,
> g-devs will persist in making innocent, naive or incompetent blunders
> and run the gauntlet of being publicly scolded over errata. I can only
> express my view that this style of personal demeaning potentially
> results in embarrassment, public humiliation and drives community
> members away from participation. The ultimate negative influence. I
> would never entertain taking on eclass writing with the incumbent qa
> member delivering assessments under the title of 'code review' in the
> style he does.

If you're writing the kind of code that results in you being subjected
to scathing criticism for breaking metadata generation for the entire
tree, then discouraging you from contributing can only be good for the
distribution...

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Aaron Bauman]

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

On Monday, May 16, 2016 3:56:01 PM JST Ian Delaney wrote:
> On Sat, 14 May 2016 21:04:17 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> 
> I hope I won't regret this
> 
> > On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman <bman@gentoo.org> wrote:
> > > On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:
> >  [...]
> >  [...]
> >  [...]
> >  
> > > Applying that same rationale, it would be unfair to say that an
> > > undescribed level of professionalism in communication is required
> > > as well.  Nothing here violates the CoC.
> 
> No but it violates elements simply lot listed in the CoC. DO we need a
> better CoC?
> 

Apparently we do, because people will continue to find ways to complain about 
words and feelings.

> This undescribed level of professionalism is presumed assumed
> knowledge, or 'understood', however the evidence suggests it is FAR
> from 'understood'.
> 

No, everyone just has a different tolerance for words that hurt or don't hurt.  
Perceived intentions or the tone of a person behind a computer really doesn't 
matter to most. 

> Here is a point worth highlighting.  While I find the language used to
> deliver the message an affront to my social senses, b-man does not and
> deems it apt to the situation. Herein therefore lies the dilemma.
> Being a communication instance, there are no clear rights or wrongs,
> but pure shades of grey. There are forms that most find fine and other

Next on bookshelves we will have "50 shades of Gentoo"... who is ready?!

> most find a violation of social etiquette. The result is that this
> style of submissions and responses re issues over QA are tacitly
> accepted as valid and therefore endorsed. There is at least one other
> dev in high authority who has all but ticked the message as justified
> in the circumstances, while in other instances has placed a cross to
> the same dev's reply in a separate thread.
> 
> This is predominantly why I refrain from sticking my neck out over
> this type of issue. Inevitably, by weight of numbers in the community,
> there will be someone who will vehemently reject and counter the point
> posed and attempt to shout it down as tripe. The point will be lost, or
> at least diluted to a meaningless mush.
> 

I appluad your efforts to ensure that the social aspect of Gentoo is a 
pleasant one.  The bottom line is that nothing wrong was said in this 
instance.

> > If you're only able to behave in a professional manner if the
> > standards of professionalism are explicitly spelled out, I think
> > you're missing the point.
> > 

Again, people come from various backgrounds and ideals so maybe it should be 
spelled out?  That is completely unfeasible though hence the new book...

> > Ultimately it is an attitude.  When you point out a mistake make it
> > either about:
> > 1.  Helping the person who made the mistake to improve because you
> > want to see them make better contributions (which they aren't going to
> > do if you drive them off).
> > 2.  If you feel that somebody simply isn't going to cut it, then by
> > all means report them so that their commit access can be revoked.
> 

I would prefer a simple "seriously...." email vice a report to QA and the 
revocation of my commit access.

> rich0 here has hit the target a bullseye. The underlying attitude in
> the initial post displays a belief of justification and entitlement to
> 'shout down' the colleague and treat him with disdain over the blunder.
> This is NOT a bootcamp with paid drill sargeants.
> 
> As long as this persists and is not intervened to polish and tidy up,
> g-devs will persist in making innocent, naive or incompetent blunders

blunder: "a stupid or careless mistake."  Are you redefining the word here or 
just calling the original violation stupid?  Because that would seriously hurt 
some feelings.  Semantics... what a condundrum.

> and run the gauntlet of being publicly scolded over errata. I can only
> express my view that this style of personal demeaning potentially
> results in embarrassment, public humiliation and drives community
> members away from participation. The ultimate negative influence. I
> would never entertain taking on eclass writing with the incumbent qa
> member delivering assessments under the title of 'code review' in the
> style he does.
> 

Thankfully someone is doing it.  If you choose not to contribute, out of fear 
of an individual behind a computer, you should reevaluate why you are doing 
this.

> It is clear he has learned that he is not only entitled but expected to
> shout at folk for misdemeanours. hasufell also believed this, and
> scoffed when I suggested to him directly one never needs to shout, but
> rather speak in tempered moderate terms.
> 
> Try it some time mgorny. The sky will not cave in.
> 

Entitlement and privilege.  The true essence of this whole problem.  No one 
here wants to feel as though someone else is better or superior to them.  I 
can only imagine though, that people believe individuals are sitting behind 
their computers just waiting for a bad piece of code to be committed so they 
can shout at someone.  If either of those cases apply to anyone here you 
should find a new hobby.

> > Either of these has the potential to make Gentoo better.  Simply
> > posting flames isn't likely to change the behavior of people who need
> > #2, and it is likely to discourage people who need #1.  Either is
> > against all of our interests in making the distro we benefit from
> > better.
> 
> ditto

I agree as well.  However, the bottom line here is that nothing wrong was 
said, and a valid point was made to ensure the committer understood the 
severity of the mistake.  Move on.

-- 
Cheers,
Aaron Bauman
Gentoo Linux Developer
GnuPG FP: 1536 F4B3 72EB 9C54 11F5  5C43 246D 23A2 10FB 0F3E

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Consus]

On 15:56 Mon 16 May, Ian Delaney wrote:
> On Sat, 14 May 2016 21:04:17 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> 
> I hope I won't regret this
> 
> > On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman <bman@gentoo.org> wrote:
> > > On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:  
> >  [...]  
> >  [...]  
> >  [...]  
> > >
> > > Applying that same rationale, it would be unfair to say that an
> > > undescribed level of professionalism in communication is required
> > > as well.  Nothing here violates the CoC.
> > >  
> > 
> 
> No but it violates elements simply lot listed in the CoC. DO we need a
> better CoC?

You need a better pair of balls; there is a chance that you will stop
getting offended by random emails.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ian Delaney]

On Sat, 14 May 2016 21:04:17 -0400
Rich Freeman <rich0@gentoo.org> wrote:

I hope I won't regret this

> On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman <bman@gentoo.org> wrote:
> > On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:  
>  [...]  
>  [...]  
>  [...]  
> >
> > Applying that same rationale, it would be unfair to say that an
> > undescribed level of professionalism in communication is required
> > as well.  Nothing here violates the CoC.
> >  
> 

No but it violates elements simply lot listed in the CoC. DO we need a
better CoC?

This undescribed level of professionalism is presumed assumed
knowledge, or 'understood', however the evidence suggests it is FAR
from 'understood'.

Here is a point worth highlighting.  While I find the language used to
deliver the message an affront to my social senses, b-man does not and
deems it apt to the situation. Herein therefore lies the dilemma.
Being a communication instance, there are no clear rights or wrongs,
but pure shades of grey. There are forms that most find fine and other
most find a violation of social etiquette. The result is that this
style of submissions and responses re issues over QA are tacitly
accepted as valid and therefore endorsed. There is at least one other
dev in high authority who has all but ticked the message as justified
in the circumstances, while in other instances has placed a cross to
the same dev's reply in a separate thread.

This is predominantly why I refrain from sticking my neck out over
this type of issue. Inevitably, by weight of numbers in the community,
there will be someone who will vehemently reject and counter the point
posed and attempt to shout it down as tripe. The point will be lost, or
at least diluted to a meaningless mush.

> If you're only able to behave in a professional manner if the
> standards of professionalism are explicitly spelled out, I think
> you're missing the point.
> 
> Ultimately it is an attitude.  When you point out a mistake make it
> either about:
> 1.  Helping the person who made the mistake to improve because you
> want to see them make better contributions (which they aren't going to
> do if you drive them off).
> 2.  If you feel that somebody simply isn't going to cut it, then by
> all means report them so that their commit access can be revoked.
> 

rich0 here has hit the target a bullseye. The underlying attitude in
the initial post displays a belief of justification and entitlement to
'shout down' the colleague and treat him with disdain over the blunder.
This is NOT a bootcamp with paid drill sargeants.

As long as this persists and is not intervened to polish and tidy up,
g-devs will persist in making innocent, naive or incompetent blunders
and run the gauntlet of being publicly scolded over errata. I can only
express my view that this style of personal demeaning potentially
results in embarrassment, public humiliation and drives community
members away from participation. The ultimate negative influence. I
would never entertain taking on eclass writing with the incumbent qa
member delivering assessments under the title of 'code review' in the
style he does.

It is clear he has learned that he is not only entitled but expected to
shout at folk for misdemeanours. hasufell also believed this, and
scoffed when I suggested to him directly one never needs to shout, but
rather speak in tempered moderate terms.

Try it some time mgorny. The sky will not cave in.

> Either of these has the potential to make Gentoo better.  Simply
> posting flames isn't likely to change the behavior of people who need
> #2, and it is likely to discourage people who need #1.  Either is
> against all of our interests in making the distro we benefit from
> better.
> 

ditto

-- 
kind regards

Ian Delaney

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

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

On 15/05/16 23:55, Duncan wrote:
> Daniel Campbell posted on Sun, 15 May 2016 04:04:57 -0700 as excerpted:
>
>> If the dev in question hasn't done that before, then it's entirely
>> possible they *thought* they tested, or tested it *before* making some
>> other edit and absent-mindedly committed.
> Again, legacy CVS thought pattern.  In git, commit != push, and it's the 
> push that's critical.
>
> Commit all you want without testing.  Just test (and fix if necessary) 
> before you push those commits up to the gentoo master repo. =:^)
>
> (Of course, rebasing to fold the broken commit and its fix into one 
> before pushing doesn't hurt, either.)
>
Surely it should be possible to fire some QA scripts on pre-commit on
the central gentoo repos (ie. at the push target end)?!
Or am I being a bit optimistic ..


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sun, May 15, 2016 at 6:46 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>
> Committing without testing, as long as you don't push, is fine, even
> meritorious.  It's the push that uploads those commits to the gentoo
> reference repo, however, and testing should *definitely* be done before
> pushing, with more commits /before/ the push to fix what the tests found
> to be broken, should they be necessary.
>

Of course.  In fact, this is often the type of workflow you'd tend to
employ in a CI setup.  I believe that pull requests submitted on
github get automatically tinderboxed, though I have no idea whether
that provides any benefits to something like an eclass (if the CI
script just tests the ebuilds being modified it obviously would not).
Maybe in a perfect world we'd actually have a CI testing package
category with dummy packages that do nothing but run tests to cover
this sort of thing.

Even so, I would imagine that in most organizations CI is intended
more as a sanity check than a substitute for testing your own work.
Certainly where I work the expectation is that somebody would have at
least compiled and run something before putting it into some kind of
QA workflow, even with CI.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 1054 bytes --]

On 05/15/2016 03:55 PM, Duncan wrote:
> Daniel Campbell posted on Sun, 15 May 2016 04:04:57 -0700 as excerpted:
> 
>> If the dev in question hasn't done that before, then it's entirely
>> possible they *thought* they tested, or tested it *before* making some
>> other edit and absent-mindedly committed.
> 
> Again, legacy CVS thought pattern.  In git, commit != push, and it's the 
> push that's critical.
> 
> Commit all you want without testing.  Just test (and fix if necessary) 
> before you push those commits up to the gentoo master repo. =:^)
> 
> (Of course, rebasing to fold the broken commit and its fix into one 
> before pushing doesn't hurt, either.)
> 
Sorry. I've actually been using git for years, but since I got started
with Gentoo on CVS and I try to be careful with my commits to the gentoo
repo, I conflated them. You're right, the push is what matters the most.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Duncan]

Daniel Campbell posted on Sun, 15 May 2016 04:04:57 -0700 as excerpted:

> If the dev in question hasn't done that before, then it's entirely
> possible they *thought* they tested, or tested it *before* making some
> other edit and absent-mindedly committed.

Again, legacy CVS thought pattern.  In git, commit != push, and it's the 
push that's critical.

Commit all you want without testing.  Just test (and fix if necessary) 
before you push those commits up to the gentoo master repo. =:^)

(Of course, rebasing to fold the broken commit and its fix into one 
before pushing doesn't hurt, either.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Duncan]

Daniel Campbell posted on Sun, 15 May 2016 04:16:30 -0700 as excerpted:

> On 05/15/2016 03:29 AM, Michał Górny wrote:

>> However, is it that much of
>> an effort to test eclass changes using ebuilds *before* committing it?
>> It wasn't that hard even in times of CVS (esp. that we're talking about
>> separate directories), and it is even easier in times of git.
>> 
> One can't coddle someone who's breaking the tree, especially
> when we expect people to test before committing.

Orthogonal to the general discussion, but could be critical for some...

Both the above comments reflect legacy CVS thought patterns in regard to 
commits.  In git, commit != push , and here it's the push, not the 
commit, that's critical and that testing needs done before.

Committing without testing, as long as you don't push, is fine, even 
meritorious.  It's the push that uploads those commits to the gentoo 
reference repo, however, and testing should *definitely* be done before 
pushing, with more commits /before/ the push to fix what the tests found 
to be broken, should they be necessary.

(Tho in keeping with the principle of ultimately atomic commits that 
don't break bisections, if a commit is found to be broken and is then 
fixed by another commit, a rebase to combine the two into one should be 
considered, thus avoiding breakage of bisections ending up with a commit 
between the break and its fix.  Not that bisection is particularly 
practical in the gentoo repo context anyway, but that's a separate 
discussion, and good habits here will carry over to repos where bisection 
is actually practical and critically important.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andreas K. Huettel]

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

Am Sonntag, 15. Mai 2016, 11:53:27 schrieb Ryan Hill:
> 
> I thought his response was pretty tame actually.  If you break the tree
> because you couldn't be bothered to do the barest minimum of testing you
> absolutely deserve to be called out on it.
> 

+1

- -- 

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXOMNKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnk+j8P/0EpX59Qy0s6K9kuSvZTkzki
w/P3jDKqfcFSkyZQFBHRXGKkyME/9uvCDxjvUzNlSGaw5Ukvl1CWzFN5Z1sxzLVU
wcu5nMaumt26egFmTliGwIWLXT7dbaqIyprCUPCF2HMbvsSBWKJ0Us+36Saz0NA3
G69ZBuO7Ig8t+yS5pcXkUUy6yqbDL2zaStIDxM5V5N0joVwetKt6CIXWiBMprRGP
L64VPi3FkVuuf4a04HMLzBl27kNRPiCvNMPZlf8Sp5b0ve4C6MapUvJ5BHSX64Hy
CtXEMPHrLtfFPE7fAW7EQlXKSRbpgkw3SIRI+TgpeMbwLaYkPkqf3NH5J3z1Gph+
CIhceVFq5gXexsbo4O3+deRXXSYraEZhZfYJKrXpiwEVVBTEpdtPrugOQoPMRo4H
pAlG8dQA456IqXGS4nur4sRljQg8rhfPnx5/vD6AnD+9gCM0qF9V/GinIBDvXOZd
QPzcaJn14MBS7xvN/jcy3Lf/ZJvjUMqb4MGKvCxvhNUFDIXHWRvqv5br3eMw6JSB
78wmN4kTcfFeQ9ywCChSKZDRZTziLVWifAORSJduGuyP/NthzPFMT3OrYS1Mze8v
JIHB+9HsmCG5RwXuP/DMAb0t0dg6Lbg8qKBtRvsO72/bsVfU50AtDDFXGowaK386
A24gQh9cIvtqRo8lU+nY
=vysH
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Brian Dolbec]

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

On Sun, 15 May 2016 04:18:39 -0700
Daniel Campbell <zlg@gentoo.org> wrote:

> On 05/15/2016 02:15 AM, Brian Dolbec wrote:
> > On Sun, 15 May 2016 11:05:21 +0200
> > Jeroen Roovers <jer@gentoo.org> wrote:
> >   
> >> On Sat, 7 May 2016 23:25:58 +0200
> >> Michał Górny <mgorny@gentoo.org> wrote:
> >>  
> >>> Do you seriously expect this code to work? How about testing? Or
> >>> reading diffs before committing?    
> >>
> >>
> >> Somebody could have a go at implementing this:
> >>
> >> https://bugs.gentoo.org/show_bug.cgi?id=390651
> >>
> >> It's been brewing for half a decade. Maybe it's time. :)
> >>
> >>
> >> Regards,
> >>      jer
> >>  
> > 
> > With the new repoman code structure, yes, it would be a lot easier
> > to implement.
> > 
> > Also with the gen-b0rk test repo, that will be a good testing ground
> > for eclass changes too.  It just needs more devs to make test
> > ebuilds to get it fully populated ;)
> >   
> What sort of test ebuilds are you looking for? There are a few
> packages I'd like to see get into Gentoo but I don't want to break
> anything. :P
> 

Have a look at the gen-b0rk repo, See how the ebuilds are done, follow
those examples.  There are lots more errors that repoman looks for that
are not yet covered by test ebuilds.

There are a few more in other areas of code, but here is the biggest
list of errors/warnings that repoman can test for.

https://gitweb.gentoo.org/proj/portage.git/tree/repoman/pym/repoman/qa_data.py?h=repoman

-- 
Brian Dolbec <dolsen>


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 1115 bytes --]

On 05/15/2016 02:15 AM, Brian Dolbec wrote:
> On Sun, 15 May 2016 11:05:21 +0200
> Jeroen Roovers <jer@gentoo.org> wrote:
> 
>> On Sat, 7 May 2016 23:25:58 +0200
>> Michał Górny <mgorny@gentoo.org> wrote:
>>
>>> Do you seriously expect this code to work? How about testing? Or
>>> reading diffs before committing?  
>>
>>
>> Somebody could have a go at implementing this:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=390651
>>
>> It's been brewing for half a decade. Maybe it's time. :)
>>
>>
>> Regards,
>>      jer
>>
> 
> With the new repoman code structure, yes, it would be a lot easier to
> implement.
> 
> Also with the gen-b0rk test repo, that will be a good testing ground
> for eclass changes too.  It just needs more devs to make test ebuilds
> to get it fully populated ;)
> 
What sort of test ebuilds are you looking for? There are a few packages
I'd like to see get into Gentoo but I don't want to break anything. :P

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 4549 bytes --]

On 05/15/2016 03:29 AM, Michał Górny wrote:
> On Sun, 15 May 2016 08:40:39 +0900
> Aaron Bauman <bman@gentoo.org> wrote:
> 
>> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
>>> On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman <bman@gentoo.org> wrote:  
>>>> On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:  
>>>>> On Sat, 7 May 2016 23:25:58 +0200
>>>>>
>>>>> Michał Górny <mgorny@gentoo.org> wrote:  
>>>>>> Do you seriously expect this code to work? How about testing? Or
>>>>>> reading diffs before committing?  
>>>>
>>>> Absolutely nothing wrong was said here.  Obviously the code was not tested
>>>> and Michal pointed that out very plainly.  
>>>
>>> It is actually possible to communicate both plainly and politely at
>>> the same time.  This does not require sacrificing any commitment to
>>> quality at all.  Really the only downside is having more of an
>>> appearance of professionalism.  
>>
>> Please enlighten me as to what was impolite here?  The strong language of 
>> "seriously" or definitively stating that the individual did not perform the 
>> necessary QA actions before committing?  Both of which are completely called 
>> for and appropriate.  No vulgarity, insults, or demeaning words were used.  
>> How would you have responded professionally?
> 
> Since the anti-productivity of this thread is getting impressively high
> even for Gentoo standards, I'd like to point out a few things.
> 
> It was impolite. It was supposed to be. Not offensive but impolite. It
> ain't cool to get responses like this but it ain't cool to break stuff
> like this either.
> 
> For those who don't have a broader view, it wasn't a single commit but
> a followup to a commit adding EAPI=6 support to the eclass -- clearly
> untested. I didn't bother complaining about the first one since issues
> would clearly pop up if someone actually tried to use the eclass
> in EAPI=6. However, the second commit actually introduced a syntax
> error that broke all the ebuilds, including stable and caused metadata
> generation failure. This is real bad.
> 
> Of course, it could have been worse. It looks like no ebuilds with
> EAPI=6 'support' were committed following the eclass. Which is a good
> sign that some testing eventually occurred. However, is it that much of
> an effort to test eclass changes using ebuilds *before* committing it?
> It wasn't that hard even in times of CVS (esp. that we're talking about
> separate directories), and it is even easier in times of git.
> 
> I don't really see the benefit of whole of this discussion. He
> committed a bad thing, I shouted at him, end of story. If you want to
> take it to comrel, just do it. However, discussing whether it was right
> or wrong is really unproductive here.
> 
I felt it was a bit strong, but you make a good case. There certainly is
a balance. One can't coddle someone who's breaking the tree, especially
when we expect people to test before committing. Since it was an eclass,
wasn't that supposed to be discussed on here first, too? Still, we're
going to make mistakes and dressing someone down won't fix it.

When I was adding multilib support to media-sound/apulse I recall you
strongly telling me that I screwed up and it shouldn't have been done
the way I originally committed. There wasn't a nudge in the right
direction, though. I imagine it was clear that I hadn't done multilib
scripts before. If I had been more sensitive or less willing to fix it,
what would have happened? You or someone else may have reverted it
and/or reported to QA and started a ruckus.

I mean, I don't hold a grudge or anything. I'm glad you told me it
wasn't right, because if I'm contributing to Gentoo I want it to be done
well. I learned something from it. But a dev being told that they're
screwing up without also being specific (or at least a hint) about a way
to fix it or *why* it's wrong doesn't help them fix their screw up and
ensure it doesn't happen again.

That sort of criticism, which may be warranted in terms of "they screwed
the tree up due to something stupid!", isn't productive if the dev
doesn't know how to fix it.

This particular screw-up is different since it was simpler, but less
trivial screw ups do happen and without _constructive_ criticism, devs
(and Gentoo, by extension) won't get better.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 2409 bytes --]

On 05/15/2016 02:53 AM, Ryan Hill wrote:
> On Sun, 15 May 2016 08:40:39 +0900
> Aaron Bauman <bman@gentoo.org> wrote:
> 
>> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
>>> On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman <bman@gentoo.org> wrote:  
>>>> On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:  
>>>>> On Sat, 7 May 2016 23:25:58 +0200
>>>>>
>>>>> Michał Górny <mgorny@gentoo.org> wrote:  
>>>>>> Do you seriously expect this code to work? How about testing? Or
>>>>>> reading diffs before committing?  
>>>>
>>>> Absolutely nothing wrong was said here.  Obviously the code was not tested
>>>> and Michal pointed that out very plainly.  
>>>
>>> It is actually possible to communicate both plainly and politely at
>>> the same time.  This does not require sacrificing any commitment to
>>> quality at all.  Really the only downside is having more of an
>>> appearance of professionalism.  
>>
>> Please enlighten me as to what was impolite here?  The strong language of 
>> "seriously" or definitively stating that the individual did not perform the 
>> necessary QA actions before committing?  Both of which are completely called 
>> for and appropriate.  No vulgarity, insults, or demeaning words were used.  
>> How would you have responded professionally?
> 
> I thought his response was pretty tame actually.  If you break the tree
> because you couldn't be bothered to do the barest minimum of testing you
> absolutely deserve to be called out on it.
> 
> But if you guys just want to hug it out that's cool too.
> 
I think that depends on history. If the dev in question hasn't done that
before, then it's entirely possible they *thought* they tested, or
tested it *before* making some other edit and absent-mindedly committed.
That's a screw-up, and devs should be notified. Ideally, they should be
told *what* they screwed up and *how* to ensure it doesn't happen again.

Admonishing them as if they were a child is not going to engender
motivation to continue participation. We're all devs because we want to
make Gentoo better (I hope, anyway), and part of that means we'll have
to help each other out sometimes.

There's more to it than coddling vs tearing someone down.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 2371 bytes --]

On 05/14/2016 01:23 PM, Rich Freeman wrote:
> On Sat, May 14, 2016 at 3:21 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
>> On 14/05/16 18:52, Rich Freeman wrote:
>>> On Sat, May 14, 2016 at 1:07 PM, landis blackwell
>>> <blackwelllandis@gmail.com> wrote:
>>>> No fun allowed
>>>>
>>> Are you saying that you don't want people to have fun developing
>>> Gentoo?  Or are you trying to say that it is impossible to have fun
>>> developing Gentoo without insulting strangers?  I don't think anybody
>>> minds two friends teasing each other.
>>>
>> I think my gut feeling would go "there's a time and a place..." .. and
>> err on the g-dev ML probably not being it .. unless everyone else is in
>> on the 'joke' ..
>>
> 
> Sure, and just to be clear I don't think we should be bothered by
> informality and joking around.  If you have a good relationship with
> somebody and poking at each other is just how you relate, you can get
> away with it.  We shouldn't have to walk on eggshells, but it just
> seems like we get a lot of flames in general going around and IMO at
> least it seems like it makes the distro a bit less fun.
> 
> Of course we shouldn't lower our standards for quality, and I suspect
> that most of the people who do commit mistakes to the tree would
> probably agree, at least when they're sober.  :)
> 

I agree. Some of us have reputations for being hard to work with or
being misunderstood, and it would go a long way for us to try to be
honest and -- for lack of a better word -- nicer. I've not personally
experienced much of that, but I can understand why someone wouldn't want
to work with (on a volunteer basis, of course) someone calling them
stupid or incompetent.

Mistakes happen and I gladly fix anything I've screwed up. I could have
taken some of the criticism personally due to the tone, however, if I
hadn't been 'seasoned' by the Internet to expect the worst.

That said, I like that those of us who are close can joke. We're all
volunteers, so why not have fun *while* we build what we think is the
ideal distro? I don't think quality and fun are mutually exclusive.

"at least when they're sober" -- I had a hearty laugh at that one. :)

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Sun, 15 May 2016 08:40:39 +0900
Aaron Bauman <bman@gentoo.org> wrote:

> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
> > On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman <bman@gentoo.org> wrote:  
> > > On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:  
> > >> On Sat, 7 May 2016 23:25:58 +0200
> > >> 
> > >> Michał Górny <mgorny@gentoo.org> wrote:  
> > >> > Do you seriously expect this code to work? How about testing? Or
> > >> > reading diffs before committing?  
> > > 
> > > Absolutely nothing wrong was said here.  Obviously the code was not tested
> > > and Michal pointed that out very plainly.  
> > 
> > It is actually possible to communicate both plainly and politely at
> > the same time.  This does not require sacrificing any commitment to
> > quality at all.  Really the only downside is having more of an
> > appearance of professionalism.  
> 
> Please enlighten me as to what was impolite here?  The strong language of 
> "seriously" or definitively stating that the individual did not perform the 
> necessary QA actions before committing?  Both of which are completely called 
> for and appropriate.  No vulgarity, insults, or demeaning words were used.  
> How would you have responded professionally?

Since the anti-productivity of this thread is getting impressively high
even for Gentoo standards, I'd like to point out a few things.

It was impolite. It was supposed to be. Not offensive but impolite. It
ain't cool to get responses like this but it ain't cool to break stuff
like this either.

For those who don't have a broader view, it wasn't a single commit but
a followup to a commit adding EAPI=6 support to the eclass -- clearly
untested. I didn't bother complaining about the first one since issues
would clearly pop up if someone actually tried to use the eclass
in EAPI=6. However, the second commit actually introduced a syntax
error that broke all the ebuilds, including stable and caused metadata
generation failure. This is real bad.

Of course, it could have been worse. It looks like no ebuilds with
EAPI=6 'support' were committed following the eclass. Which is a good
sign that some testing eventually occurred. However, is it that much of
an effort to test eclass changes using ebuilds *before* committing it?
It wasn't that hard even in times of CVS (esp. that we're talking about
separate directories), and it is even easier in times of git.

I don't really see the benefit of whole of this discussion. He
committed a bad thing, I shouted at him, end of story. If you want to
take it to comrel, just do it. However, discussing whether it was right
or wrong is really unproductive here.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ryan Hill]

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

On Sun, 15 May 2016 08:40:39 +0900
Aaron Bauman <bman@gentoo.org> wrote:

> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
> > On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman <bman@gentoo.org> wrote:  
> > > On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:  
> > >> On Sat, 7 May 2016 23:25:58 +0200
> > >> 
> > >> Michał Górny <mgorny@gentoo.org> wrote:  
> > >> > Do you seriously expect this code to work? How about testing? Or
> > >> > reading diffs before committing?  
> > > 
> > > Absolutely nothing wrong was said here.  Obviously the code was not tested
> > > and Michal pointed that out very plainly.  
> > 
> > It is actually possible to communicate both plainly and politely at
> > the same time.  This does not require sacrificing any commitment to
> > quality at all.  Really the only downside is having more of an
> > appearance of professionalism.  
> 
> Please enlighten me as to what was impolite here?  The strong language of 
> "seriously" or definitively stating that the individual did not perform the 
> necessary QA actions before committing?  Both of which are completely called 
> for and appropriate.  No vulgarity, insults, or demeaning words were used.  
> How would you have responded professionally?

I thought his response was pretty tame actually.  If you break the tree
because you couldn't be bothered to do the barest minimum of testing you
absolutely deserve to be called out on it.

But if you guys just want to hug it out that's cool too.

-- 

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Brian Dolbec]

On Sun, 15 May 2016 11:05:21 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Sat, 7 May 2016 23:25:58 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > Do you seriously expect this code to work? How about testing? Or
> > reading diffs before committing?  
> 
> 
> Somebody could have a go at implementing this:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=390651
> 
> It's been brewing for half a decade. Maybe it's time. :)
> 
> 
> Regards,
>      jer
> 

With the new repoman code structure, yes, it would be a lot easier to
implement.

Also with the gen-b0rk test repo, that will be a good testing ground
for eclass changes too.  It just needs more devs to make test ebuilds
to get it fully populated ;)

-- 
Brian Dolbec <dolsen>

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Jeroen Roovers]

On Sat, 7 May 2016 23:25:58 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?


Somebody could have a go at implementing this:

https://bugs.gentoo.org/show_bug.cgi?id=390651

It's been brewing for half a decade. Maybe it's time. :)


Regards,
     jer

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

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

On 15/05/16 02:04, Rich Freeman wrote:
> On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman <bman@gentoo.org> wrote:
>> On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:
>>> On Sun, 15 May 2016 08:40:39 +0900
>>>
>>> Aaron Bauman <bman@gentoo.org> wrote:
>>>> Please enlighten me as to what was impolite here?  The strong
>>>> language of "seriously" or definitively stating that the individual
>>>> did not perform the necessary QA actions before committing?  Both of
>>>> which are completely called for and appropriate.  No vulgarity,
>>>> insults, or demeaning words were used. How would you have responded
>>>> professionally?
>>> It's important to remember that Gentoo is run by volunteers. Expecting
>>> a professional standard when it comes to the quality of commit
>>> criticism is unfair.
>> Applying that same rationale, it would be unfair to say that an undescribed
>> level of professionalism in communication is required as well.  Nothing here
>> violates the CoC.
>>
> If you're only able to behave in a professional manner if the
> standards of professionalism are explicitly spelled out, I think
> you're missing the point.
>
> Ultimately it is an attitude.  When you point out a mistake make it
> either about:
> 1.  Helping the person who made the mistake to improve because you
> want to see them make better contributions (which they aren't going to
> do if you drive them off).
> 2.  If you feel that somebody simply isn't going to cut it, then by
> all means report them so that their commit access can be revoked.
>
> Either of these has the potential to make Gentoo better.  Simply
> posting flames isn't likely to change the behavior of people who need
> #2, and it is likely to discourage people who need #1.  Either is
> against all of our interests in making the distro we benefit from
> better.
>
+1


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

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

On 15/05/16 01:59, Rich Freeman wrote:
> On Sat, May 14, 2016 at 7:40 PM, Aaron Bauman <bman@gentoo.org> wrote:
>> Please enlighten me as to what was impolite here?  The strong language of
>> "seriously" or definitively stating that the individual did not perform the
>> necessary QA actions before committing?
> He actually didn't "state" anything at all - he posted a set of
> rhetorical questions.  And the use of "seriously" was inflammatory.
> In fact, if you're trying to avoid injecting passion into a discussion
> it is worth thinking carefully about just about any word ending in
> "ly" that you put into a sentence.  Nine times out of ten the word
> isn't necessary and can cause more harm than good.
>
>> Both of which are completely called
>> for and appropriate.  No vulgarity, insults, or demeaning words were used.
> I disagree.  The tone was uncivil and demeaning.
>
>> How would you have responded professionally?
>>
> How about this:
>
> You inserted this code snippet into the middle of a command line, so
> it is certain to break in either case.  This should have been detected
> during testing; please be sure to test changes to ebuilds/eclasses
> before committing them.  Additionally eclass changes should be
> submitted to the lists for review in any case prior to being
> committed.
>
> Or by all means refer the issue to QA/Comrel if you want to escalate it.
>
> I'm in no way suggesting that we should accept bad commits.  IMO when
> we see bad commits we should:
>
> 1.  Just point them out politely if it is a one-off.  ANYBODY can make
> a mistake.
> 2.  If they're a trend or show signs of bad practices like not testing
> changes then escalate to QA/Comrel.
> 3.  Let QA/Comrel do their job and block commit access or refer the
> dev for more mentoring/etc as appropriate.  Then we actually fix the
> problem instead of just yelling at each other.
>
+1


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman <bman@gentoo.org> wrote:
> On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:
>> On Sun, 15 May 2016 08:40:39 +0900
>>
>> Aaron Bauman <bman@gentoo.org> wrote:
>> > Please enlighten me as to what was impolite here?  The strong
>> > language of "seriously" or definitively stating that the individual
>> > did not perform the necessary QA actions before committing?  Both of
>> > which are completely called for and appropriate.  No vulgarity,
>> > insults, or demeaning words were used. How would you have responded
>> > professionally?
>>
>> It's important to remember that Gentoo is run by volunteers. Expecting
>> a professional standard when it comes to the quality of commit
>> criticism is unfair.
>
> Applying that same rationale, it would be unfair to say that an undescribed
> level of professionalism in communication is required as well.  Nothing here
> violates the CoC.
>

If you're only able to behave in a professional manner if the
standards of professionalism are explicitly spelled out, I think
you're missing the point.

Ultimately it is an attitude.  When you point out a mistake make it
either about:
1.  Helping the person who made the mistake to improve because you
want to see them make better contributions (which they aren't going to
do if you drive them off).
2.  If you feel that somebody simply isn't going to cut it, then by
all means report them so that their commit access can be revoked.

Either of these has the potential to make Gentoo better.  Simply
posting flames isn't likely to change the behavior of people who need
#2, and it is likely to discourage people who need #1.  Either is
against all of our interests in making the distro we benefit from
better.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 7:40 PM, Aaron Bauman <bman@gentoo.org> wrote:
>
> Please enlighten me as to what was impolite here?  The strong language of
> "seriously" or definitively stating that the individual did not perform the
> necessary QA actions before committing?

He actually didn't "state" anything at all - he posted a set of
rhetorical questions.  And the use of "seriously" was inflammatory.
In fact, if you're trying to avoid injecting passion into a discussion
it is worth thinking carefully about just about any word ending in
"ly" that you put into a sentence.  Nine times out of ten the word
isn't necessary and can cause more harm than good.

> Both of which are completely called
> for and appropriate.  No vulgarity, insults, or demeaning words were used.

I disagree.  The tone was uncivil and demeaning.

> How would you have responded professionally?
>

How about this:

You inserted this code snippet into the middle of a command line, so
it is certain to break in either case.  This should have been detected
during testing; please be sure to test changes to ebuilds/eclasses
before committing them.  Additionally eclass changes should be
submitted to the lists for review in any case prior to being
committed.

Or by all means refer the issue to QA/Comrel if you want to escalate it.

I'm in no way suggesting that we should accept bad commits.  IMO when
we see bad commits we should:

1.  Just point them out politely if it is a one-off.  ANYBODY can make
a mistake.
2.  If they're a trend or show signs of bad practices like not testing
changes then escalate to QA/Comrel.
3.  Let QA/Comrel do their job and block commit access or refer the
dev for more mentoring/etc as appropriate.  Then we actually fix the
problem instead of just yelling at each other.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Aaron Bauman]

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

On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:
> On Sun, 15 May 2016 08:40:39 +0900
> 
> Aaron Bauman <bman@gentoo.org> wrote:
> > Please enlighten me as to what was impolite here?  The strong
> > language of "seriously" or definitively stating that the individual
> > did not perform the necessary QA actions before committing?  Both of
> > which are completely called for and appropriate.  No vulgarity,
> > insults, or demeaning words were used. How would you have responded
> > professionally?
> 
> It's important to remember that Gentoo is run by volunteers. Expecting
> a professional standard when it comes to the quality of commit
> criticism is unfair.

Applying that same rationale, it would be unfair to say that an undescribed 
level of professionalism in communication is required as well.  Nothing here 
violates the CoC.

-- 
Cheers,
Aaron Bauman
Gentoo Linux Developer
GnuPG FP: 1536 F4B3 72EB 9C54 11F5  5C43 246D 23A2 10FB 0F3E

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ciaran McCreesh]

On Sun, 15 May 2016 08:40:39 +0900
Aaron Bauman <bman@gentoo.org> wrote:
> Please enlighten me as to what was impolite here?  The strong
> language of "seriously" or definitively stating that the individual
> did not perform the necessary QA actions before committing?  Both of
> which are completely called for and appropriate.  No vulgarity,
> insults, or demeaning words were used. How would you have responded
> professionally?

It's important to remember that Gentoo is run by volunteers. Expecting
a professional standard when it comes to the quality of commit
criticism is unfair.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Aaron Bauman]

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

On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
> On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman <bman@gentoo.org> wrote:
> > On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:
> >> On Sat, 7 May 2016 23:25:58 +0200
> >> 
> >> Michał Górny <mgorny@gentoo.org> wrote:
> >> > Do you seriously expect this code to work? How about testing? Or
> >> > reading diffs before committing?
> > 
> > Absolutely nothing wrong was said here.  Obviously the code was not tested
> > and Michal pointed that out very plainly.
> 
> It is actually possible to communicate both plainly and politely at
> the same time.  This does not require sacrificing any commitment to
> quality at all.  Really the only downside is having more of an
> appearance of professionalism.

Please enlighten me as to what was impolite here?  The strong language of 
"seriously" or definitively stating that the individual did not perform the 
necessary QA actions before committing?  Both of which are completely called 
for and appropriate.  No vulgarity, insults, or demeaning words were used.  
How would you have responded professionally?

-- 
Cheers,
Aaron Bauman
Gentoo Linux Developer
GnuPG FP: 1536 F4B3 72EB 9C54 11F5  5C43 246D 23A2 10FB 0F3E

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 3:21 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
> On 14/05/16 18:52, Rich Freeman wrote:
>> On Sat, May 14, 2016 at 1:07 PM, landis blackwell
>> <blackwelllandis@gmail.com> wrote:
>>> No fun allowed
>>>
>> Are you saying that you don't want people to have fun developing
>> Gentoo?  Or are you trying to say that it is impossible to have fun
>> developing Gentoo without insulting strangers?  I don't think anybody
>> minds two friends teasing each other.
>>
> I think my gut feeling would go "there's a time and a place..." .. and
> err on the g-dev ML probably not being it .. unless everyone else is in
> on the 'joke' ..
>

Sure, and just to be clear I don't think we should be bothered by
informality and joking around.  If you have a good relationship with
somebody and poking at each other is just how you relate, you can get
away with it.  We shouldn't have to walk on eggshells, but it just
seems like we get a lot of flames in general going around and IMO at
least it seems like it makes the distro a bit less fun.

Of course we shouldn't lower our standards for quality, and I suspect
that most of the people who do commit mistakes to the tree would
probably agree, at least when they're sober.  :)

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andreas K. Huettel]

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

Am Samstag, 14. Mai 2016, 18:59:02 schrieb M. J. Everitt:
> 
> I think the time is coming, given the diversity of members of this list,
> to add <sarcasm></sarcasm> tags when we are not describing something
> literally. 

wouldnt a <ciaranm></ciaranm> tag be sufficient?

- -- 

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXN4VVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkXskQAJJ6LWQ1b0Ap27SAFGnTIqJb
oYhGf8r3VoOxjVbqOKRVZnOZkudQ5KiURxUv+vAZbbomw4SMiV/gn1T/8V8xafbv
KCL7UJOaW4AXgCZ+dFaV2jjTbVrFSMtvkeKwl3klpqPgylk9Q0Vudm1a058iBPRQ
9VPNX14Ooj3cKyimCYesznwH8cGv7cCUZA/MmjnqCQyKy+N5kxDyKyVdEECQ2bEY
D/YDFoTtizixC8HS/OmOzRfCGRe3aPzHyzOMWL7FgCr9fnOE4METSa2kf9GQgViv
9g3RMfpQ4gudCQ/WcqEVDWUt8XlHxFvwdmleywP+Rh81MbUnkaLCA3dnk2Ev86su
s2g5ltS2ozOlCkeryzenbZ1Ezk66kE6o+lBtC1MGWL5MDZVRZvIM1zCaYEqAwabC
jDikqnGxWT3Lvyi7Jmus1p+vjty2LV00yA0JczED7tXSILUqW9ym2Trm/fAd1O+x
NBMMnrrzWW28lyLFUZ+akRFvR35shE1KiISW7GVoorVKtmL8er6LkxYVkvjYi2Vn
Ze+/mlxHNpJh1KjfQ3MC1MOqJQO3ZeOF0AFMPjxMvHFP+5J52PUdtTQeo68080kr
UpFzlwE4nJj5CxMMYgqn7XVjgoaI/jZKqWdUN2h6cj2OwZIe58rIvKroWnUYaVOD
4IsP85PN+scg0Evuj4wa
=jNhK
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

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

On 14/05/16 18:52, Rich Freeman wrote:
> On Sat, May 14, 2016 at 1:07 PM, landis blackwell
> <blackwelllandis@gmail.com> wrote:
>> No fun allowed
>>
> Are you saying that you don't want people to have fun developing
> Gentoo?  Or are you trying to say that it is impossible to have fun
> developing Gentoo without insulting strangers?  I don't think anybody
> minds two friends teasing each other.
>
I think my gut feeling would go "there's a time and a place..." .. and
err on the g-dev ML probably not being it .. unless everyone else is in
on the 'joke' ..


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 1:07 PM, landis blackwell
<blackwelllandis@gmail.com> wrote:
> No fun allowed
>

Are you saying that you don't want people to have fun developing
Gentoo?  Or are you trying to say that it is impossible to have fun
developing Gentoo without insulting strangers?  I don't think anybody
minds two friends teasing each other.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 14/05/16 18:06, Rich Freeman wrote:
>
> While this is certainly sensible, the irony here is that this whole
> discussion was started by somebody making a sarcastic remark when
> simply pointing out a mistake would have been just as functional.
>
> Nobody thinks it is ok to commit broken code.  What it seems like
> we'll be debating until there is only one of us left is how
> unprofessional we should be when pointing that out.
>
+1 .. is it time to add <irony> tags too?! :]

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[landis blackwell]

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

No fun allowed
On May 14, 2016 12:06 PM, "Rich Freeman" <rich0@gentoo.org> wrote:

> On Sat, May 14, 2016 at 12:59 PM, M. J. Everitt <m.j.everitt@iee.org>
> wrote:
> > On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote:
> >> Gordon Pettey schrieb:
> >>
> >>> So, it's perfectly okay to make direct commits of obviously broken
> >>> code that
> >>> has no chance of working, because community something mumble...
> >>
> >> You may have missed some sarcasm in the post which you replied to.
> >> Plus, I don't think anybody said or implied that committing broken
> >> things is ok.
> >>
> >>
> >> Best regards,
> >> Chí-Thanh Christopher Nguyễn
> >>
> > I think the time is coming, given the diversity of members of this list,
> > to add <sarcasm></sarcasm> tags when we are not describing something
> > literally. It becomes very difficult to follow the thread of
> > conversation when people are (not) communicating their true thoughts!!
> >
>
> While this is certainly sensible, the irony here is that this whole
> discussion was started by somebody making a sarcastic remark when
> simply pointing out a mistake would have been just as functional.
>
> Nobody thinks it is ok to commit broken code.  What it seems like
> we'll be debating until there is only one of us left is how
> unprofessional we should be when pointing that out.
>
> --
> Rich
>
>

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 12:59 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
> On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote:
>> Gordon Pettey schrieb:
>>
>>> So, it's perfectly okay to make direct commits of obviously broken
>>> code that
>>> has no chance of working, because community something mumble...
>>
>> You may have missed some sarcasm in the post which you replied to.
>> Plus, I don't think anybody said or implied that committing broken
>> things is ok.
>>
>>
>> Best regards,
>> Chí-Thanh Christopher Nguyễn
>>
> I think the time is coming, given the diversity of members of this list,
> to add <sarcasm></sarcasm> tags when we are not describing something
> literally. It becomes very difficult to follow the thread of
> conversation when people are (not) communicating their true thoughts!!
>

While this is certainly sensible, the irony here is that this whole
discussion was started by somebody making a sarcastic remark when
simply pointing out a mistake would have been just as functional.

Nobody thinks it is ok to commit broken code.  What it seems like
we'll be debating until there is only one of us left is how
unprofessional we should be when pointing that out.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

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

On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote:
> Gordon Pettey schrieb:
>
>> So, it's perfectly okay to make direct commits of obviously broken
>> code that
>> has no chance of working, because community something mumble...
>
> You may have missed some sarcasm in the post which you replied to.
> Plus, I don't think anybody said or implied that committing broken
> things is ok.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
I think the time is coming, given the diversity of members of this list,
to add <sarcasm></sarcasm> tags when we are not describing something
literally. It becomes very difficult to follow the thread of
conversation when people are (not) communicating their true thoughts!!


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Chí-Thanh Christopher Nguyễn]

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

Gordon Pettey schrieb:

> So, it's perfectly okay to make direct commits of obviously broken code that
> has no chance of working, because community something mumble...

You may have missed some sarcasm in the post which you replied to.
Plus, I don't think anybody said or implied that committing broken things is ok.


Best regards,
Chí-Thanh Christopher Nguyễn


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Gordon Pettey]

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

On Sat, May 14, 2016 at 6:35 AM, Ciaran McCreesh <
ciaran.mccreesh@googlemail.com> wrote:

> Why? Gentoo is about the community. Requiring a basic standard of commit
> quality a) reduces the number of community members who are able to
> contribute, 2) leads to fewer forums posts discussing how to fix
> problems, iii) hurts Gentoo's DistroWatch statistics by reducing the
> volume of commits, and fourthly, discriminates unfairly against
> competency-challenged developers by imposing subjective interpretations
> of the value of source code from a position of unearned authority. This
> is against the code of conduct, and is bad for the community!
>
> So, it's perfectly okay to make direct commits of obviously broken code
that has no chance of working, because community something mumble...

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman <bman@gentoo.org> wrote:
> On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:
>> On Sat, 7 May 2016 23:25:58 +0200
>> Michał Górny <mgorny@gentoo.org> wrote:
>> >
>> > Do you seriously expect this code to work? How about testing? Or
>> > reading diffs before committing?
>> >
>
> Absolutely nothing wrong was said here.  Obviously the code was not tested and
> Michal pointed that out very plainly.
>

It is actually possible to communicate both plainly and politely at
the same time.  This does not require sacrificing any commitment to
quality at all.  Really the only downside is having more of an
appearance of professionalism.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Aaron Bauman]

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

On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:
> On Sat, 7 May 2016 23:25:58 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> >
> > Do you seriously expect this code to work? How about testing? Or
> > reading diffs before committing?
> >

Absolutely nothing wrong was said here.  Obviously the code was not tested and 
Michal pointed that out very plainly.

> >
> 
> 
> Do you seriously expect us to sit and absorb this form of pious
> put down? From one who knows far better who is entitled to speak down
> to colleagues as is completely lacking a cerebral cortex? Those times

In one sentence you question him about putting someone down then in the next 
sentence you say he is lacking a cerebral cortex... hypocritical.

> are drawing to an end. Did anyone ever teach you to treat folk in such
> manner and expect them to respect it? I don't think so
> Not over my dead cvs perhaps

Not even really sure what that means?  dead cvs?

> 

> --
> kind regards
> 
> Ian Delaney


-- 
Cheers,
Aaron Bauman
Gentoo Linux Developer
GnuPG FP: 1536 F4B3 72EB 9C54 11F5  5C43 246D 23A2 10FB 0F3E

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

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

On 14/05/16 12:35, Ciaran McCreesh wrote:
> On Sat, 14 May 2016 11:55:42 +0200
>> Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney:
>>> On Sat, 7 May 2016 23:25:58 +0200  
>>>> Do you seriously expect this code to work? How about testing? Or
>>>> reading diffs before committing?  
>>> Do you seriously expect us to sit and absorb this form of pious
>>> put down? From one who knows far better who is entitled to speak
>>> down to colleagues as is completely lacking a cerebral cortex?
>>> Those times are drawing to an end. Did anyone ever teach you to
>>> treat folk in such manner and expect them to respect it? I don't
>>> think so Not over my dead cvs perhaps  
>> Well, we still do need some commit quality, you know...
> Why? Gentoo is about the community. Requiring a basic standard of commit
> quality a) reduces the number of community members who are able to
> contribute, 2) leads to fewer forums posts discussing how to fix
> problems, iii) hurts Gentoo's DistroWatch statistics by reducing the
> volume of commits, and fourthly, discriminates unfairly against
> competency-challenged developers by imposing subjective interpretations
> of the value of source code from a position of unearned authority. This
> is against the code of conduct, and is bad for the community!
>
In defense of Gentoo at large .. the entry-level to contribute is really
quite low .. and all the documentation for gentoo 'standards' is widely
documented in both the Devmanual (under revision currently) and the
Package Manager Spec. Not only this, but there are active projects
within gentoo to welcome, nurture and develop devs and contributors
alike so that there is a sustainable level of man-power available to
keep up with the demands of users and pace of code development. Ok, it
can be off-putting to those looking in from the outside, but really I
think it benefits more than it costs.

I agree broadly with the ethos of the QA team, gentoo tends to focus on
quality over quantity where commits are concerned. It's better to retain
a stable, reliable set of packages, with additional untested/unstable
packages available via overlays, rather than a massive, unwieldy number
of packages in a broadly unknown state. As it is, there is a deficit of
active people maintaining the less-widely used packages, and also people
able to add new packages to the tree, and this means that resources are
inevitably spread more thinly.

As always there will be a balance, but this thread did start out with
some tit-for-tat between devs, totally unnecessary either in private or
public. So, ditch that bike-shed, and get on with fixing bugs, closing
issues, adding, updating and deprecating packages, folks :]. Thank you.


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ciaran McCreesh]

On Sat, 14 May 2016 11:55:42 +0200
> Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney:
> > On Sat, 7 May 2016 23:25:58 +0200  
> > > Do you seriously expect this code to work? How about testing? Or
> > > reading diffs before committing?  
> > 
> > Do you seriously expect us to sit and absorb this form of pious
> > put down? From one who knows far better who is entitled to speak
> > down to colleagues as is completely lacking a cerebral cortex?
> > Those times are drawing to an end. Did anyone ever teach you to
> > treat folk in such manner and expect them to respect it? I don't
> > think so Not over my dead cvs perhaps  
> 
> Well, we still do need some commit quality, you know...

Why? Gentoo is about the community. Requiring a basic standard of commit
quality a) reduces the number of community members who are able to
contribute, 2) leads to fewer forums posts discussing how to fix
problems, iii) hurts Gentoo's DistroWatch statistics by reducing the
volume of commits, and fourthly, discriminates unfairly against
competency-challenged developers by imposing subjective interpretations
of the value of source code from a position of unearned authority. This
is against the code of conduct, and is bad for the community!

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andreas K. Huettel]

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

Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney:
> On Sat, 7 May 2016 23:25:58 +0200

> > 
> > Do you seriously expect this code to work? How about testing? Or
> > reading diffs before committing?
> 
> Do you seriously expect us to sit and absorb this form of pious
> put down? From one who knows far better who is entitled to speak down
> to colleagues as is completely lacking a cerebral cortex? Those times
> are drawing to an end. Did anyone ever teach you to treat folk in such
> manner and expect them to respect it? I don't think so
> Not over my dead cvs perhaps

Well, we still do need some commit quality, you know...

- -- 

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXNvYeXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkXA4P/jDuTHnBkZfkzwjIbk6ZTi8J
/sb/ypGT3h+tXUoYei2978drsF091WnDU6H+RCj3Lk4LKtPR6pMzL9OEXdihQqJh
+OSZgh1T3pZJAjRWAVeXjgGmSlW9Pmxfnb1G9D9Zv+58cRohQhbZZG3baXih3QBY
2umIqYKgfbq+whtr49YYPVU6mVovQ8esWCAZWw5+vYqw2/9MDIUl4wWJVlDXgo7l
Bmb2t5XudJ5lApfDGhOSaxi2lacPK2WggAlN2XmG5MkjPuQAauEQly8MhxlSUQxX
Q8ZAyqzokPENXq0C+PwrF9TGBaFAQjMAnCLP7F4eo8jDqfsPhTxcthNQRhYXFpx6
/5aXEBb4DZwTOust9hdBUvUM5pUo7P9IyoBVGQdejo87YrLxy1MI0/J2E+GrRQfM
HNRdAwRrhUpQrF6sCyD5mH7uVWdVwdhIY70Lau4d8HIP/J5TRN2FwP7F2zqjjQmz
lUj20/meBvgHlGUgjsi2sb15HLwx2E2OkMrxhYcuE9JuBiaomBnz+OpSlzp2wGwR
X1rXBVz/nvn2nVTH75QybLcjvTO9FfdfGFEGOrjQ/f68sTHpcat+Co9wJjYgD/LA
EtUomNUkIFGcMJAyOBgdgZDiYREFXnlW1FlB94VS4SgcPpkcvxKBruM+DcJDgZ+h
/F5kkAuRtmOsXBN2e1MT
=5e68
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ian Delaney]

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

On Sat, 7 May 2016 23:25:58 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sat,  7 May 2016 21:19:31 +0000 (UTC)
> "Joerg Bornkessel" <hd_brummy@gentoo.org> wrote:
> 
> > commit:     66afcab271f65b97330e610040ad3acc1b812a03
> > Author:     Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org>
> > AuthorDate: Sat May  7 21:18:48 2016 +0000
> > Commit:     Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org>
> > CommitDate: Sat May  7 21:18:48 2016 +0000
> > URL:
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2
> > 
> > fixed einstall vs. emake install for eapi=6
> > 
> >  eclass/vdr-plugin-2.eclass | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass
> > index ae09a34..65f1409 100644
> > --- a/eclass/vdr-plugin-2.eclass
> > +++ b/eclass/vdr-plugin-2.eclass
> > @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() {
> >  	local SOFILE_STRING=$(grep SOFILE Makefile)
> >  	if [[ -n ${SOFILE_STRING} ]]; then
> >  		BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install }}
> > -		einstall ${BUILD_PARAMS} \
> > +		if [[ ${EAPI} == 6 ]]; then
> > +			emake install ${BUILD_PARAMS} \
> > +		else
> > +			einstall ${BUILD_PARAMS} \
> > +		fi
> >  			${BUILD_TARGETS} \
> >  			TMPDIR="${T}" \
> >  			DESTDIR="${D}" \
> >   
> 
> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?
> 

Do you seriously expect us to sit and absorb this form of pious
put down? From one who knows far better who is entitled to speak down
to colleagues as is completely lacking a cerebral cortex? Those times
are drawing to an end. Did anyone ever teach you to treat folk in such
manner and expect them to respect it? I don't think so
Not over my dead cvs perhaps

- -- 
kind regards

Ian Delaney
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXNZW5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCRUI4RjAxNzRGRTVDMjI4RjcxNkRFNzIw
QzQzN0NCNDcxRTlEMzNBAAoJEAxDfLRx6dM6mzcP/1BmrZw/EiuPlJh6MuufJ1/U
Zlg26d99Vvvji0VVHcz9lrDhk6ubYB3WrcrG3E2M1pVwXDTuy+z5ez7RXvuUMSSY
XiP4uWVWmlQoBlkAzAAvzKKVNsQvfOCif1x/b59Qjm9qAKQOwawTzCjOCHIrB08V
EXFuuo5gpHfkq5vtU7jK22/6Zo56w+A7xfgSKl96byepA4F++3vDH4kX3XTBVmtE
vlPn230CQqgP/YMZ/TBcQ4AE3r0fxPmGnAniZn/o5v2Zpzo1SZjrRlYJXDq3PnIa
Rjs6fWEvfA7xu8wDt05Xz+8bzVXmS//1ga0VB1dmcNlVelUY7Pwi1kR+nUF174Vo
/xLlTvK/EboliAMbviRwX9extWycWCB+iyBH/RkazaQQmSiW5tHlVPx8Wu7LiRay
O8eFks7LgenetNBymMaiPBNZJMo/I+Fnebk43qx0XfUyuANLsg3JnsY4WG+Evcjc
3XqkTePuDyFLQEgQlU417JSFRkyZ0odMqpVShqOxgv4EA/HAiCpWCHkE1ZuiLi1V
7bKQodOclD3jTmy6eJgLpoEhqphXCaX9bl5QcFyu3+La8r3YXOqErCbOECoJy0Np
lXwOCKZ9kvcv8iLygxKqP/0rxuAP0kzs5NSWd2zhHLRBihNvP+xkc2Pi4ztRT2LN
Hju+wa0/WdLLTEPCAe78
=4iJI
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 1492 bytes --]

On 5/7/16 4:25 PM, Michał Górny wrote:
> On Sat,  7 May 2016 21:19:31 +0000 (UTC)
> "Joerg Bornkessel" <hd_brummy@gentoo.org> wrote:
> 
>> commit:     66afcab271f65b97330e610040ad3acc1b812a03
>> Author:     Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org>
>> AuthorDate: Sat May  7 21:18:48 2016 +0000
>> Commit:     Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org>
>> CommitDate: Sat May  7 21:18:48 2016 +0000
>> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2
>>
>> fixed einstall vs. emake install for eapi=6
>>
>>  eclass/vdr-plugin-2.eclass | 6 +++++-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass
>> index ae09a34..65f1409 100644
>> --- a/eclass/vdr-plugin-2.eclass
>> +++ b/eclass/vdr-plugin-2.eclass
>> @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() {
>>  	local SOFILE_STRING=$(grep SOFILE Makefile)
>>  	if [[ -n ${SOFILE_STRING} ]]; then
>>  		BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install }}
>> -		einstall ${BUILD_PARAMS} \
>> +		if [[ ${EAPI} == 6 ]]; then
>> +			emake install ${BUILD_PARAMS} \
>> +		else
>> +			einstall ${BUILD_PARAMS} \
>> +		fi
>>  			${BUILD_TARGETS} \
>>  			TMPDIR="${T}" \
>>  			DESTDIR="${D}" \
>>
> 
> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?
> 

Michal,

How about trying a different tone?

-- 
Doug Goldstein


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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ryan Hill]

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

On Sat, 7 May 2016 23:25:58 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sat,  7 May 2016 21:19:31 +0000 (UTC)
> "Joerg Bornkessel" <hd_brummy@gentoo.org> wrote:
> 
> > commit:     66afcab271f65b97330e610040ad3acc1b812a03
> > Author:     Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org>
> > AuthorDate: Sat May  7 21:18:48 2016 +0000
> > Commit:     Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org>
> > CommitDate: Sat May  7 21:18:48 2016 +0000
> > URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2
> > 
> > fixed einstall vs. emake install for eapi=6
> > 
> >  eclass/vdr-plugin-2.eclass | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass
> > index ae09a34..65f1409 100644
> > --- a/eclass/vdr-plugin-2.eclass
> > +++ b/eclass/vdr-plugin-2.eclass
> > @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() {
> >  	local SOFILE_STRING=$(grep SOFILE Makefile)
> >  	if [[ -n ${SOFILE_STRING} ]]; then
> >  		BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install }}
> > -		einstall ${BUILD_PARAMS} \
> > +		if [[ ${EAPI} == 6 ]]; then
> > +			emake install ${BUILD_PARAMS} \
> > +		else
> > +			einstall ${BUILD_PARAMS} \
> > +		fi
> >  			${BUILD_TARGETS} \
> >  			TMPDIR="${T}" \
> >  			DESTDIR="${D}" \
> >   
> 
> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?

I reverted this commit since it broke sourcing any ebuild inheriting the eclass.

I'm going to assume this commit was made by accident, since any dev that would
commit code to an eclass without testing that it works, or even that it's
_valid bash_, would not continue to have unsupervised commit rights for very
long.


-- 

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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Sat,  7 May 2016 21:19:31 +0000 (UTC)
"Joerg Bornkessel" <hd_brummy@gentoo.org> wrote:

> commit:     66afcab271f65b97330e610040ad3acc1b812a03
> Author:     Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org>
> AuthorDate: Sat May  7 21:18:48 2016 +0000
> Commit:     Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org>
> CommitDate: Sat May  7 21:18:48 2016 +0000
> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2
> 
> fixed einstall vs. emake install for eapi=6
> 
>  eclass/vdr-plugin-2.eclass | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass
> index ae09a34..65f1409 100644
> --- a/eclass/vdr-plugin-2.eclass
> +++ b/eclass/vdr-plugin-2.eclass
> @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() {
>  	local SOFILE_STRING=$(grep SOFILE Makefile)
>  	if [[ -n ${SOFILE_STRING} ]]; then
>  		BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install }}
> -		einstall ${BUILD_PARAMS} \
> +		if [[ ${EAPI} == 6 ]]; then
> +			emake install ${BUILD_PARAMS} \
> +		else
> +			einstall ${BUILD_PARAMS} \
> +		fi
>  			${BUILD_TARGETS} \
>  			TMPDIR="${T}" \
>  			DESTDIR="${D}" \
> 

Do you seriously expect this code to work? How about testing? Or
reading diffs before committing?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Luca Barbato]

On 18/04/16 00:50, Anthony G. Basile wrote:

> Does base-system object if I bump it to EAPI=5 before I commit the
> ssl-cert patch?  I'll start stabilization too obviously.
> 

Please do.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/17/16 4:28 AM, Anthony G. Basile wrote:
> On 4/17/16 4:15 AM, Fabian Groffen wrote:
>> On 16-04-2016 21:05:56 +0200, Michał Górny wrote:
>>> Congratulations! You've just committed an invalid dependency that is
>>> going to cause true mayhem on every package using the eclass.
>>
>> I assume you've taken proper actions to mitigate this.
>>
>>> But why would anyone send patches for review, or even start wondering
>>> that we might be using USE=libressl all around for some reason...
>>
>> While I believe your point is right (patches for review), I think this
>> style of communication is unnecessary.
> 
> In case you haven't been following the other communications regarding
> the matter, the USE flag is not necessary here because ssl-cert.eclass
> does not involve any linking against openssl/libressl.  So I'll be
> recommitting the original patch without the slot operator.
> 
> The original patch is at
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/ssl-cert.eclass?id=7a4d6bd5fcb25d8381bc08e20ad6a5c1c80ad78f
> 
> plus s/:0=/:0/
> 
>>
>> Thanks,
>> Fabian
>>
> 
> 

mgorny suggested that i look for any EAPI=0 ebuild inheriting
ssl-cert.eclass.  I hacked up the following:

import portage

portdb = portage.db["/"]["porttree"].dbapi
gentoo_repo_location = portdb.repositories["gentoo"].location

for cp in portdb.cp_all(trees=[gentoo_repo_location]):
    for cpv in portdb.cp_list(cp, mytree=gentoo_repo_location):
        eapi, inherited = portdb.aux_get(cpv, ["EAPI", "INHERITED"],
myrepo="gentoo")
        if eapi == '0' and 'ssl-cert' in inherited.split():
            print(cpv)

and found net-ftp/netkit-ftpd-0.17-r8.  Its pretty ancient and belongs
to base system.

Does base-system object if I bump it to EAPI=5 before I commit the
ssl-cert patch?  I'll start stabilization too obviously.

-- 
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-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/17/16 4:15 AM, Fabian Groffen wrote:
> On 16-04-2016 21:05:56 +0200, Michał Górny wrote:
>> Congratulations! You've just committed an invalid dependency that is
>> going to cause true mayhem on every package using the eclass.
> 
> I assume you've taken proper actions to mitigate this.
> 
>> But why would anyone send patches for review, or even start wondering
>> that we might be using USE=libressl all around for some reason...
> 
> While I believe your point is right (patches for review), I think this
> style of communication is unnecessary.

In case you haven't been following the other communications regarding
the matter, the USE flag is not necessary here because ssl-cert.eclass
does not involve any linking against openssl/libressl.  So I'll be
recommitting the original patch without the slot operator.

The original patch is at

https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/ssl-cert.eclass?id=7a4d6bd5fcb25d8381bc08e20ad6a5c1c80ad78f

plus s/:0=/:0/

> 
> Thanks,
> Fabian
> 


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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Fabian Groffen]

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

On 16-04-2016 21:05:56 +0200, Michał Górny wrote:
> Congratulations! You've just committed an invalid dependency that is
> going to cause true mayhem on every package using the eclass.

I assume you've taken proper actions to mitigate this.

> But why would anyone send patches for review, or even start wondering
> that we might be using USE=libressl all around for some reason...

While I believe your point is right (patches for review), I think this
style of communication is unnecessary.

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/16/16 6:46 PM, Mike Gilbert wrote:
> On Sat, Apr 16, 2016 at 6:36 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> On Sat, Apr 16, 2016 at 6:24 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>>>
>>> And I don't really see the point in the libressl USE flag in this
>>> case; I think that was only needed so the slot-operator would resolve
>>> correctly.
>>>
>>
>> Somebody else may be better informed, but I thought that there was a
>> concern with having both libressl and openssl linked into two
>> libraries that are in turn linked to by something else (causing a
>> symbol collision), and the USE flag was necessary to switch between
>> the two implementations since they aren't virtualized.
>>
>> If we've solved that problem in some other way then by all means say
>> so.  However, I thought this was the main tradeoff in letting it use
>> the same soname.
> 
> This eclass doesn't build/link anything. It just calls /usr/bin/openssl.
> 

You still need to be able to tell the difference between
dev-libs/{open,libre}ssl;

# openssl version
LibreSSL 2.2.6


# openssl version
OpenSSL 1.0.2g  1 Mar 2016

-- 
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-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/16/16 6:36 PM, Rich Freeman wrote:
> On Sat, Apr 16, 2016 at 6:24 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>>
>> And I don't really see the point in the libressl USE flag in this
>> case; I think that was only needed so the slot-operator would resolve
>> correctly.
>>
> 
> Somebody else may be better informed, but I thought that there was a
> concern with having both libressl and openssl linked into two
> libraries that are in turn linked to by something else (causing a
> symbol collision), and the USE flag was necessary to switch between
> the two implementations since they aren't virtualized.
> 
> If we've solved that problem in some other way then by all means say
> so.  However, I thought this was the main tradeoff in letting it use
> the same soname.
> 

I was reasoning along the lines of Mike when I first committed this.
The eclass simply provides a series of functions for generating certs.
It is sufficient that the `openssl` utility be present whether its
provided by dev-libs/openssl or dev-libs/libressl.  You're not linking
against it so the ABI issue is a non-issue.  As far as being able to
tell the difference between the two, you can use `openssl version`.

The slot operator was more subtle.  I'm aware that := only means
something in RDEPENDs but people do RDEPEND="${DEPEND} ..." often and so
as a precaution, I included it.  However, the scope of DEPEND does not
cross the eclass-ebuild boundary and since there is no RDEPEND in that
eclass, its wrong to have :0= there.  :0 is sufficient.  inherit() in
ebuild.sh scrubs the value of DEPEND, so its not as simple as just "source".

-- 
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-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Mike Gilbert]

On Sat, Apr 16, 2016 at 6:36 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Sat, Apr 16, 2016 at 6:24 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>>
>> And I don't really see the point in the libressl USE flag in this
>> case; I think that was only needed so the slot-operator would resolve
>> correctly.
>>
>
> Somebody else may be better informed, but I thought that there was a
> concern with having both libressl and openssl linked into two
> libraries that are in turn linked to by something else (causing a
> symbol collision), and the USE flag was necessary to switch between
> the two implementations since they aren't virtualized.
>
> If we've solved that problem in some other way then by all means say
> so.  However, I thought this was the main tradeoff in letting it use
> the same soname.

This eclass doesn't build/link anything. It just calls /usr/bin/openssl.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, Apr 16, 2016 at 6:24 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>
> And I don't really see the point in the libressl USE flag in this
> case; I think that was only needed so the slot-operator would resolve
> correctly.
>

Somebody else may be better informed, but I thought that there was a
concern with having both libressl and openssl linked into two
libraries that are in turn linked to by something else (causing a
symbol collision), and the USE flag was necessary to switch between
the two implementations since they aren't virtualized.

If we've solved that problem in some other way then by all means say
so.  However, I thought this was the main tradeoff in letting it use
the same soname.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Mike Gilbert]

On Sat, Apr 16, 2016 at 3:31 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> On 4/16/16 3:27 PM, Anthony G. Basile wrote:
>> On 4/16/16 3:05 PM, Michał Górny wrote:
>>> On Sat, 16 Apr 2016 19:01:02 +0000 (UTC)
>>> "Anthony G. Basile" <blueness@gentoo.org> wrote:
>>
>> Okay for review.  Sorry for the wrap.
>>
>> diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
>> index 002de76..fc2debd 100644
>> --- a/eclass/ssl-cert.eclass
>> +++ b/eclass/ssl-cert.eclass
>> @@ -30,10 +30,10 @@
>>
>>  if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then
>>         if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then
>> -               DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )"
>> +               DEPEND="${SSL_CERT_USE}? ( !libressl? (
>> dev-libs/openssl:0= ) libressl? ( dev-libs/librssl:0= ) )"
>>                 IUSE="${SSL_CERT_USE}"
>>         else
>> -               DEPEND="dev-libs/openssl:0="
>> +               DEPEND="!libressl? ( dev-libs/openssl:0= ) libressl? (
>> dev-libs/librssl:0= )"
>>         fi
>>  fi
>>
>>
>>
>
> Actually the eclass also needs IUSE="${IUSE} libressl"

As discussed in IRC, the slot-operator is unneeded, and has been removed.

And I don't really see the point in the libressl USE flag in this
case; I think that was only needed so the slot-operator would resolve
correctly.

My suggestion would be this:

DEPEND="${SSL_CERT_USE}? ( || ( dev-libs/openssl:0 dev-libs/libressl:0 ) )"

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/16/16 3:18 PM, Anthony G. Basile wrote:
> On 4/16/16 3:16 PM, Rich Freeman wrote:
>> On Sat, Apr 16, 2016 at 3:05 PM, Michał Górny <mgorny@gentoo.org> wrote:
>>>
>>> Congratulations! ... But why would anyone...
>>
>> Not really picking on you in particular, but this is not the first
>> snarky comment on a commit we've seen today.
>>
>> If somebody makes a mistake, just point it out.  I think we can all
>> appreciate that glibc shouldn't break even in ~arch, and that libressl
>> needs a USE flag due to the whole ABI situation.
>>
>> I can't remember the last time I just factually pointed out a mistake
>> to somebody that they didn't just fix it.  When there are real
>> controversies then there are ways to escalate.  We don't need to
>> manufacture them out of accidents.
>>
> 
> I know it will cause rebuild but we are moving towards openssl:0=
> dependency.  Please look at the discussion on bug #569112.
> 

Sorry I originally thought mgorny was referring to the added slot
operators, but he meant the USE flags.

-- 
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-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/16/16 3:27 PM, Anthony G. Basile wrote:
> On 4/16/16 3:05 PM, Michał Górny wrote:
>> On Sat, 16 Apr 2016 19:01:02 +0000 (UTC)
>> "Anthony G. Basile" <blueness@gentoo.org> wrote:
> 
> Okay for review.  Sorry for the wrap.
> 
> diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
> index 002de76..fc2debd 100644
> --- a/eclass/ssl-cert.eclass
> +++ b/eclass/ssl-cert.eclass
> @@ -30,10 +30,10 @@
> 
>  if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then
>         if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then
> -               DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )"
> +               DEPEND="${SSL_CERT_USE}? ( !libressl? (
> dev-libs/openssl:0= ) libressl? ( dev-libs/librssl:0= ) )"
>                 IUSE="${SSL_CERT_USE}"
>         else
> -               DEPEND="dev-libs/openssl:0="
> +               DEPEND="!libressl? ( dev-libs/openssl:0= ) libressl? (
> dev-libs/librssl:0= )"
>         fi
>  fi
> 
> 
> 

Actually the eclass also needs IUSE="${IUSE} libressl"

-- 
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-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/16/16 3:05 PM, Michał Górny wrote:
> On Sat, 16 Apr 2016 19:01:02 +0000 (UTC)
> "Anthony G. Basile" <blueness@gentoo.org> wrote:

Okay for review.  Sorry for the wrap.

diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
index 002de76..fc2debd 100644
--- a/eclass/ssl-cert.eclass
+++ b/eclass/ssl-cert.eclass
@@ -30,10 +30,10 @@

 if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then
        if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then
-               DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )"
+               DEPEND="${SSL_CERT_USE}? ( !libressl? (
dev-libs/openssl:0= ) libressl? ( dev-libs/librssl:0= ) )"
                IUSE="${SSL_CERT_USE}"
        else
-               DEPEND="dev-libs/openssl:0="
+               DEPEND="!libressl? ( dev-libs/openssl:0= ) libressl? (
dev-libs/librssl:0= )"
        fi
 fi



-- 
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-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/16/16 3:16 PM, Rich Freeman wrote:
> On Sat, Apr 16, 2016 at 3:05 PM, Michał Górny <mgorny@gentoo.org> wrote:
>>
>> Congratulations! ... But why would anyone...
> 
> Not really picking on you in particular, but this is not the first
> snarky comment on a commit we've seen today.
> 
> If somebody makes a mistake, just point it out.  I think we can all
> appreciate that glibc shouldn't break even in ~arch, and that libressl
> needs a USE flag due to the whole ABI situation.
> 
> I can't remember the last time I just factually pointed out a mistake
> to somebody that they didn't just fix it.  When there are real
> controversies then there are ways to escalate.  We don't need to
> manufacture them out of accidents.
> 

I know it will cause rebuild but we are moving towards openssl:0=
dependency.  Please look at the discussion on bug #569112.

-- 
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-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, Apr 16, 2016 at 3:05 PM, Michał Górny <mgorny@gentoo.org> wrote:
>
> Congratulations! ... But why would anyone...

Not really picking on you in particular, but this is not the first
snarky comment on a commit we've seen today.

If somebody makes a mistake, just point it out.  I think we can all
appreciate that glibc shouldn't break even in ~arch, and that libressl
needs a USE flag due to the whole ABI situation.

I can't remember the last time I just factually pointed out a mistake
to somebody that they didn't just fix it.  When there are real
controversies then there are ways to escalate.  We don't need to
manufacture them out of accidents.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/16/16 3:05 PM, Michał Górny wrote:
> On Sat, 16 Apr 2016 19:01:02 +0000 (UTC)
> "Anthony G. Basile" <blueness@gentoo.org> wrote:
> 
>> commit:     ad0c2ab2bdbd34f4550e49c56cfd5974d6a2c07a
>> Author:     Anthony G. Basile <blueness <AT> gentoo <DOT> org>
>> AuthorDate: Sat Apr 16 19:08:23 2016 +0000
>> Commit:     Anthony G. Basile <blueness <AT> gentoo <DOT> org>
>> CommitDate: Sat Apr 16 19:08:23 2016 +0000
>> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad0c2ab2
>>
>> ssl-cert.eclass: add libressl support
>>
>>  eclass/ssl-cert.eclass | 12 ++++++++----
>>  1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
>> index 002de76..2538f4d 100644
>> --- a/eclass/ssl-cert.eclass
>> +++ b/eclass/ssl-cert.eclass
>> @@ -30,10 +30,10 @@
>>  
>>  if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then
>>  	if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then
>> -		DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )"
>> +		DEPEND="${SSL_CERT_USE}? ( || ( dev-libs/openssl:0= dev-libs/libressl:0= ) )"
>>  		IUSE="${SSL_CERT_USE}"
>>  	else
>> -		DEPEND="dev-libs/openssl:0="
>> +		DEPEND="|| ( dev-libs/openssl:0= dev-libs/libressl:0= )"
>>  	fi
>>  fi
>>  
> 
> Congratulations! You've just committed an invalid dependency that is
> going to cause true mayhem on every package using the eclass.
> 
> But why would anyone send patches for review, or even start wondering
> that we might be using USE=libressl all around for some reason...
> 

It was discussed on the bug report and I asked robbat2.  Revert then.

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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Sat, 16 Apr 2016 19:01:02 +0000 (UTC)
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> commit:     ad0c2ab2bdbd34f4550e49c56cfd5974d6a2c07a
> Author:     Anthony G. Basile <blueness <AT> gentoo <DOT> org>
> AuthorDate: Sat Apr 16 19:08:23 2016 +0000
> Commit:     Anthony G. Basile <blueness <AT> gentoo <DOT> org>
> CommitDate: Sat Apr 16 19:08:23 2016 +0000
> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad0c2ab2
> 
> ssl-cert.eclass: add libressl support
> 
>  eclass/ssl-cert.eclass | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
> index 002de76..2538f4d 100644
> --- a/eclass/ssl-cert.eclass
> +++ b/eclass/ssl-cert.eclass
> @@ -30,10 +30,10 @@
>  
>  if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then
>  	if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then
> -		DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )"
> +		DEPEND="${SSL_CERT_USE}? ( || ( dev-libs/openssl:0= dev-libs/libressl:0= ) )"
>  		IUSE="${SSL_CERT_USE}"
>  	else
> -		DEPEND="dev-libs/openssl:0="
> +		DEPEND="|| ( dev-libs/openssl:0= dev-libs/libressl:0= )"
>  	fi
>  fi
>  

Congratulations! You've just committed an invalid dependency that is
going to cause true mayhem on every package using the eclass.

But why would anyone send patches for review, or even start wondering
that we might be using USE=libressl all around for some reason...

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Sun, 22 Nov 2015 08:27:47 +0000 (UTC)
"Michael Sterrett" <mr_bones_@gentoo.org> wrote:

> commit:     a144d7480f781f21323943d87e6a56136add3830
> Author:     Michael Sterrett <mr_bones_ <AT> gentoo <DOT> org>
> AuthorDate: Sun Nov 22 08:26:57 2015 +0000
> Commit:     Michael Sterrett <mr_bones_ <AT> gentoo <DOT> org>
> CommitDate: Sun Nov 22 08:27:35 2015 +0000
> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a144d748
> 
> Stop inheriting base.eclass (bug #494208)
> 
>  eclass/games.eclass | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/eclass/games.eclass b/eclass/games.eclass
> index 7d231e1..aebf679 100644
> --- a/eclass/games.eclass
> +++ b/eclass/games.eclass
> @@ -24,11 +24,11 @@
>  if [[ -z ${_GAMES_ECLASS} ]]; then
>  _GAMES_ECLASS=1
>  
> -inherit base multilib toolchain-funcs eutils user
> +inherit multilib toolchain-funcs eutils user

This changes API in all existing eclasses. In paricular, src_unpack()
and src_prepare() stop being implicitly exported which can cause them
to being implicitly replaced by another eclass. Which is especially
relevant since you specifically required people to inherit games.eclass
last and force its overrides.

>  case ${EAPI:-0} in
>  	0|1) EXPORT_FUNCTIONS pkg_setup src_compile pkg_preinst pkg_postinst ;;
> -	2|3|4|5) EXPORT_FUNCTIONS pkg_setup src_configure src_compile pkg_preinst pkg_postinst ;;
> +	2|3|4|5|6) EXPORT_FUNCTIONS pkg_setup src_configure src_compile pkg_preinst pkg_postinst ;;

This is irrelevant change and belongs in a separate commit.
Furthermore, I don't think it is appropriate to enable new EAPI support
until you perform the eclass changes requested by the Council.

>  	*) die "no support for EAPI=${EAPI} yet" ;;
>  esac
>  
> @@ -302,12 +302,14 @@ games_src_configure() {
>  
>  # @FUNCTION: games_src_compile
>  # @DESCRIPTION:
> -# Runs base_src_make(). This function is exported as src_compile().
> +# This function is exported as src_compile().
>  games_src_compile() {
>  	case ${EAPI:-0} in
>  		0|1) games_src_configure ;;
>  	esac
> -	base_src_make
> +	if [[ -f Makefile || -f GNUmakefile || -f makefile ]]; then
> +		emake "$@" || die
> +	fi
>  }
>  
>  # @FUNCTION: games_pkg_preinst
> 

I'm going to revert this commit on behalf of QA to avoid breakage.
The relevant bug specifically mentioned making the change conditional
to EAPI 6. Please either do that (and don't enable EAPI 6 until you
have performed all requested changes), or confirm that none of
the packages will be broken by removing it retroactively.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Tue, Nov 17, 2015 at 3:37 PM, Raymond Jennings <shentino@gmail.com> wrote:
> As a possibly relevant side note, I've observed how api changes are handled
> in the linux kernel:
>
> You can change whatever you want if it's a good idea, but as part of proving
> it, you have to be willing to take over the warranty for anything you break.
>
> So basically you change what you please ONLY if you also take the burden of
> fixing everything that depended on what you screwed with.
>
> Is this how things are handled by gentoo as well?
>

For the most part, yes, though sometimes changes are posted well in
advance with the goal of getting everybody to pitch in.

This is why a change like this was implemented with an EAPI change.
There is no retroactive impact of the change, so nothing in the tree
is affected.  Developers just have to fix their ebuilds before they
move to the new EAPI.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Mike Pagano]

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

On Tuesday, November 17, 2015 08:19:29 AM Michał Górny wrote:
> On Mon, 16 Nov 2015 23:38:08 +0000 (UTC)
> 
> "Mike Pagano" <mpagano@gentoo.org> wrote:
> > commit:     aac24917ebe254a23990f0d7fff9f6f570b99d15
> > Author:     Mike Pagano <mpagano <AT> gentoo <DOT> org>

<snip>

Thanks for the review and feedback. Applied your suggestion.

Mike



-- 
Mike Pagano
Gentoo Developer - Kernel Project
Team Lead - Gentoo Sources
E-Mail     : mpagano@gentoo.org
GnuPG FP   : 52CC A0B0 F631 0B17 0142  F83F 92A6 DBEC 81F2 B137
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0x81F2B137&op=index

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Raymond Jennings]

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

As a possibly relevant side note, I've observed how api changes are handled
in the linux kernel:

You can change whatever you want if it's a good idea, but as part of
proving it, you have to be willing to take over the warranty for anything
you break.

So basically you change what you please ONLY if you also take the burden of
fixing everything that depended on what you screwed with.

Is this how things are handled by gentoo as well?

On Mon, Nov 16, 2015 at 11:19 PM, Michał Górny <mgorny@gentoo.org> wrote:

> On Mon, 16 Nov 2015 23:38:08 +0000 (UTC)
> "Mike Pagano" <mpagano@gentoo.org> wrote:
>
> > commit:     aac24917ebe254a23990f0d7fff9f6f570b99d15
> > Author:     Mike Pagano <mpagano <AT> gentoo <DOT> org>
> > AuthorDate: Mon Nov 16 23:37:55 2015 +0000
> > Commit:     Mike Pagano <mpagano <AT> gentoo <DOT> org>
> > CommitDate: Mon Nov 16 23:37:55 2015 +0000
> > URL:
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aac24917
> >
> > kernel-2.eclass: Fix for git-sources 4.4_rcX
> >
> >  eclass/kernel-2.eclass | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> > index 0f47b8c..5a9ea9f 100644
> > --- a/eclass/kernel-2.eclass
> > +++ b/eclass/kernel-2.eclass
> > @@ -1079,9 +1079,9 @@ unipatch() {
> >                       # https://bugs.gentoo.org/show_bug.cgi?id=507656
>                  #
> >
>  ####################################################################
> >                       if [[ ${PN} == "git-sources" ]] ; then
> > -                             if [[ ${KV_MAJOR}${KV_PATCH} -ge 315 &&
> ${RELEASETYPE} == -rc ]] ; then
> > +                             if [[ ${KV_MAJOR}.${KV_PATCH} > 3.15 &&
> ${RELEASETYPE} == -rc ]] ; then
>
> Don't do string comparison on numbers. It can fail randomly,
> and teaches others who read it bad practices. For example, it would
> fail when kernel reaches version 10 ;-P.
>
> Instead:
>
> [[ ${KV_MAJOR} -gt 3 || ( ${KV_MAJOR} -eq 3 && ${KV_PATCH} -gt 15 ) ]]
>
> >                                       ebegin "Applying ${i/*\//} (-p1)"
> > -                                     if [ $(patch -p1
> --no-backup-if-mismatch -f < ${i} >> ${STDERR_T}) "$?" -eq 0 ]; then
> > +                                     if [ $(patch -p1
> --no-backup-if-mismatch -f < ${i} >> ${STDERR_T}) "$?" -le 2 ]; then
> >                                               eend 0
> >                                               rm ${STDERR_T}
> >                                               break
> >
>
>
>
> --
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>
>

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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Mon, 16 Nov 2015 23:38:08 +0000 (UTC)
"Mike Pagano" <mpagano@gentoo.org> wrote:

> commit:     aac24917ebe254a23990f0d7fff9f6f570b99d15
> Author:     Mike Pagano <mpagano <AT> gentoo <DOT> org>
> AuthorDate: Mon Nov 16 23:37:55 2015 +0000
> Commit:     Mike Pagano <mpagano <AT> gentoo <DOT> org>
> CommitDate: Mon Nov 16 23:37:55 2015 +0000
> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aac24917
> 
> kernel-2.eclass: Fix for git-sources 4.4_rcX
> 
>  eclass/kernel-2.eclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index 0f47b8c..5a9ea9f 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -1079,9 +1079,9 @@ unipatch() {
>  			# https://bugs.gentoo.org/show_bug.cgi?id=507656                   #
>  			####################################################################
>  			if [[ ${PN} == "git-sources" ]] ; then
> -				if [[ ${KV_MAJOR}${KV_PATCH} -ge 315 && ${RELEASETYPE} == -rc ]] ; then
> +				if [[ ${KV_MAJOR}.${KV_PATCH} > 3.15 && ${RELEASETYPE} == -rc ]] ; then

Don't do string comparison on numbers. It can fail randomly,
and teaches others who read it bad practices. For example, it would
fail when kernel reaches version 10 ;-P.

Instead:

[[ ${KV_MAJOR} -gt 3 || ( ${KV_MAJOR} -eq 3 && ${KV_PATCH} -gt 15 ) ]]

>  					ebegin "Applying ${i/*\//} (-p1)"
> -					if [ $(patch -p1 --no-backup-if-mismatch -f < ${i} >> ${STDERR_T}) "$?" -eq 0 ]; then
> +					if [ $(patch -p1 --no-backup-if-mismatch -f < ${i} >> ${STDERR_T}) "$?" -le 2 ]; then
>  						eend 0
>  						rm ${STDERR_T}
>  						break
> 



-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Mon, Nov 16, 2015 at 4:52 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Mon, 16 Nov 2015 10:29:43 +0100
> "Justin Lecher (jlec)" <jlec@gentoo.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> On 16/11/15 10:14, Alexis Ballier wrote:
>> > Probably those that want to ban it should fix the(ir) tree so that
>> > developers have no pain in bumping to eapi6?
>>
>> Versioned APIs are made to have incompatible changes. What do you like
>> to see?
>
> deprecation warnings for some time or..
>

Well, it sounds like you've received and understood your deprecation
warning.  :)  EAPI5 won't be going away for a long time, and you can
move to EAPI6 whenever you're ready.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Alexis Ballier]

On Mon, 16 Nov 2015 10:29:43 +0100
"Justin Lecher (jlec)" <jlec@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 16/11/15 10:14, Alexis Ballier wrote:
> > Probably those that want to ban it should fix the(ir) tree so that 
> > developers have no pain in bumping to eapi6?  
> 
> Versioned APIs are made to have incompatible changes. What do you like
> to see?

deprecation warnings for some time or..

> Someone dropping all usages of that eclass from all ebuilds
> which are using it so that the maintainer can bump without thinking?

this would be preferred :)

[...]
> > While I agree we should move away from those eclasses, the "I
> > decided to throw the crap at other developers with eapi6 without
> > deprecation period" is a bit hard to grasp. Esp. when these
> > eclasses were advertised as the way to go not so long ago...
> >   
> 
> I don't really understand what deprecation you like to see?


RepoMan scours the neighborhood...
  inherit.deprecated            1
   x11-wm/xmonad-contrib/xmonad-contrib-0.11.2.ebuild: please migrate
   from 'base' (no replacement) on line: 10


these warnings have been there for ages and for several eclasses

> We cannot
> use EAPI=6 right now and when it starts to exist, nothing will be
> broken. So you have some to time to adopt your thinking until you
> write your first ebuild in EAPI=6.
> 
> At which particular point do you seen problems coming up? What do you
> think will make maintainers struggle with that change?

Right. With our always decreasing, soon to be negative, number of
open bugs, all those shiny areas where fellow developers spend more time
looking for something to do rather than doing it, we should be thankful
to have at least some ebuild rewrite to do ! :)

More seriously, the problem is not in the technical way it is done
(changing eclass API with EAPI is a nice proper way), but in adding
useless burden.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Justin Lecher (jlec)]

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

On 16/11/15 10:14, Alexis Ballier wrote:
> Probably those that want to ban it should fix the(ir) tree so that 
> developers have no pain in bumping to eapi6?

Versioned APIs are made to have incompatible changes. What do you like
to see? Someone dropping all usages of that eclass from all ebuilds
which are using it so that the maintainer can bump without thinking? I
agree with you later statement that the eclasses have been announced
to be a great solution when using autotools based packages, and
dropping it now means going back to the old. But the changes needed
are just straight forward, drop the eclass and use the default
functions of EAPI=6. Plus the autotools.eclass when you need to run
autoreconf and friends.

> While I agree we should move away from those eclasses, the "I
> decided to throw the crap at other developers with eapi6 without
> deprecation period" is a bit hard to grasp. Esp. when these
> eclasses were advertised as the way to go not so long ago...
> 

I don't really understand what deprecation you like to see? We cannot
use EAPI=6 right now and when it starts to exist, nothing will be
broken. So you have some to time to adopt your thinking until you
write your first ebuild in EAPI=6.

At which particular point do you seen problems coming up? What do you
think will make maintainers struggle with that change?

Justin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0

iQJ8BAEBCgBmBQJWSaIHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiQqgQAJPqJhNCzec5w/wBNhMAI/AO
gu086aIIwHoc1mRCPtkgrfY/UhT6unO3U+V+/MBnyRJB5tJc+6AgM//ovt8ctsyb
Aylog8w77mT/v9GULq1PPPRIy0p+Eh3XvhxNWdFZgu4BAVde/4b3rQEklIPiwAiC
FQy23LQEZh4wG8CldoR6ULBR0CUO8Ff6xNFVqXvgjhnH+I7BehRP47OE5SiiobCK
/4bKb9UjKZqnrttagPlaf6DrzidJd4XgHPrhQSoTA6uLubB0uR7EdrwlgYlR3FES
LWbT4kO9RG9GZo1y4mrNxGTugiF3OFwJX5UHJT55lwNPDHcUsNhl3Yyjb9Vc9f9W
Ro/6x7gY5dchDARy1LU3419tRzPGvxeyKkc6Z21Ie374LQYuhhKQiPzjW6oSc+j2
MFDzjBphdqXuiSYeC608Q3KGoYruV2fSGhqQDdAsSADkBBXktBApOZpjyrYXv6W1
xwN/FYHE21lZHjCTUJQEz2+5fdZ0VxRtQPQKautkB8+rhfobrexafMVYt8hjB6fG
JvCTOb5Yo8VpWs7i/Zls5jB87y6uYrSFGlbbCrMu6vO7m/KrhZZjQ9dpHpeQ78qj
grhcoxi2xtvfa72j/eVxgDYHhXjoJLmJ/60dsUt75IwAcVhtwEg6OWVowXxAGmgD
DNG/UIoC9yKzVxkAaEm/
=zJp2
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Alexis Ballier]

On Mon, 16 Nov 2015 10:06:17 +0100
"Justin Lecher (jlec)" <jlec@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 16/11/15 10:01, Alexis Ballier wrote:
> > On Fri, 13 Nov 2015 23:53:05 +0000 (UTC) "Michał Górny"
> > <mgorny@gentoo.org> wrote:
> >   
> >> commit:     ad4c142684afb096e8fff2937ae5c5c3385dd22e Author:
> >> Michał Górny <mgorny <AT> gentoo <DOT> org> AuthorDate: Fri Nov
> >> 13 18:46:33 2015 +0000 Commit:     Michał Górny <mgorny <AT>
> >> gentoo <DOT> org> CommitDate: Fri Nov 13 23:52:53 2015 +0000 
> >> URL: 
> >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad4c1426
> >> 
> >> autotools-{utils,multilib}.eclass: Ban for EAPI=6
> >> 
> >> Ban autotools-utils.eclass and dependant
> >> autotools-multilib.eclass for EAPI=6 to avoid them being
> >> accidentally enabled. The former eclass should be replaced with
> >> inline code, the latter with multilib-minimal.eclass.  
> > 
> > 
> > Not that I particularly like those eclasses, but I seem to have
> > missed the deprecation warnings for these. I hope you're planning
> > in submitting patches "fixing" consumers...  
> 
> Probably the developers should fix their ebuilds when they bump to
> EAPI=6. While I haven't looked at the change exactly, Michał announced
> it as a EAPI >= 6 Ban. So no backwards breakages expected.

Probably those that want to ban it should fix the(ir) tree so that
developers have no pain in bumping to eapi6?

While I agree we should move away from those eclasses, the "I decided
to throw the crap at other developers with eapi6 without deprecation
period" is a bit hard to grasp. Esp. when these eclasses were advertised
as the way to go not so long ago...

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Justin Lecher (jlec)]

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

On 16/11/15 10:01, Alexis Ballier wrote:
> On Fri, 13 Nov 2015 23:53:05 +0000 (UTC) "Michał Górny"
> <mgorny@gentoo.org> wrote:
> 
>> commit:     ad4c142684afb096e8fff2937ae5c5c3385dd22e Author:
>> Michał Górny <mgorny <AT> gentoo <DOT> org> AuthorDate: Fri Nov
>> 13 18:46:33 2015 +0000 Commit:     Michał Górny <mgorny <AT>
>> gentoo <DOT> org> CommitDate: Fri Nov 13 23:52:53 2015 +0000 
>> URL: 
>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad4c1426
>> 
>> autotools-{utils,multilib}.eclass: Ban for EAPI=6
>> 
>> Ban autotools-utils.eclass and dependant
>> autotools-multilib.eclass for EAPI=6 to avoid them being
>> accidentally enabled. The former eclass should be replaced with
>> inline code, the latter with multilib-minimal.eclass.
> 
> 
> Not that I particularly like those eclasses, but I seem to have
> missed the deprecation warnings for these. I hope you're planning
> in submitting patches "fixing" consumers...

Probably the developers should fix their ebuilds when they bump to
EAPI=6. While I haven't looked at the change exactly, Michał announced
it as a EAPI >= 6 Ban. So no backwards breakages expected.

Justin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0

iQJ8BAEBCgBmBQJWSZyJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiHY4P/0TjhS4isDESbDHkSgcWhdgs
aSexsiCJs1bCaTjGAH2Hn8cPaesV0CO96BMFWgjq/io/B+N1x+h5RbhbI/zXHXpK
I9sziWWI68J7SvumVEtkoccM4bdWDKj+pdsqCnyJYp0qkTVZbUBNK0vpUYBhIQRt
4LMCEZvo9me1FmBtdv5RssqkLw2nqcb3sfsQ5uQ7icdIR1rRp9OTNdT3/LQAOQ3l
nGDz/fZpHOlUhyMdCEtSzv51ZBvejFcuRrSea2jnqOdkcnDwOY8Fo9HH0iv1rVmd
SZkAV4yZSz+0OveisjPhQSa1h/uquv49KLcLp6CfPA5228POy/RhFwGx4ZLRhbe3
tlFUApr4ozI4Danry5SlMu2YadJdf+zPu7e/FLwdIVzv7eqZa8ov8cOHyNICVKpr
JZsFvk/7pyL0TB+zfo/MZCU5KY72HOcmi5yL7FpDyYg0m/0cn6bH+FHN/rUxpuLT
inztt4MThZUb+Oubd40GRpD8xSmhgQYo90Us10tb/6xU5tGD7+ZtvENKvPQsMQgp
Zh0tkzpp+jJpqlJ7lupa/f5EjWxhXefD5fkrtxjTAO9aIU6JoY6MWd3uqKndSwjA
WrdxnX/lPkDSTqLqPYvPxLYebBuAyKojeIEGaF558ELcwUxNRJdK84CqRsNsLwHe
vtEeQFPh0f3cl/+9EZju
=TvwF
-----END PGP SIGNATURE-----

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Alexis Ballier]

On Fri, 13 Nov 2015 23:53:05 +0000 (UTC)
"Michał Górny" <mgorny@gentoo.org> wrote:

> commit:     ad4c142684afb096e8fff2937ae5c5c3385dd22e
> Author:     Michał Górny <mgorny <AT> gentoo <DOT> org>
> AuthorDate: Fri Nov 13 18:46:33 2015 +0000
> Commit:     Michał Górny <mgorny <AT> gentoo <DOT> org>
> CommitDate: Fri Nov 13 23:52:53 2015 +0000
> URL:
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad4c1426
> 
> autotools-{utils,multilib}.eclass: Ban for EAPI=6
> 
> Ban autotools-utils.eclass and dependant autotools-multilib.eclass for
> EAPI=6 to avoid them being accidentally enabled. The former eclass
> should be replaced with inline code, the latter with
> multilib-minimal.eclass.


Not that I particularly like those eclasses, but I seem to have missed
the deprecation warnings for these. I hope you're planning in
submitting patches "fixing" consumers...


Alexis.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Luca Barbato]

On 11/11/15 10:09, Michał Górny wrote:
> I'd rather use the old standard 80. Minus 8 characters for friendly
> e-mail quoting, which is also kinda 'old standard'.

You can suggest as above, with this tone, and probably you would get
some consensus.

Personally I think 80col is nice since you can have three-way side by
side diff in most of the current screens.

You can deliver your point effectively w/out screaming and name calling.

lu

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Tue, 10 Nov 2015 18:53:03 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> On 31 Oct 2015 09:08, Michał Górny wrote:
> > On Sat, 31 Oct 2015 03:06:21 -0400 Mike Frysinger wrote:  
> > > On 30 Oct 2015 18:20, Michał Górny wrote:  
> > > > On Fri, 30 Oct 2015 12:03:59 +0000 (UTC) "Justin Lecher" wrote:    
> > > > > --- a/eclass/distutils-r1.eclass
> > > > > +++ b/eclass/distutils-r1.eclass
> > > > > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() {
> > > > >  
> > > > >  	_distutils-r1_disable_ez_setup
> > > > >  
> > > > > -	if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]
> > > > > -	then
> > > > > +	if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]; then    
> > > > 
> > > > This was intentionally wrapped to stay within 72-column line width. Not
> > > > saying the eclass is perfect in keeping text width, especially with
> > > > others committing random changes to it, but that's no reason to
> > > > introduce further offenders.    
> > > 
> > > Gentoo has never had a hard 80-col rule let alone 72-cols.  forcing a wrap
> > > here makes no sense and the new version is an improvement.  
> > 
> > For years, Gentoo was unable to make *any* *sane* *global* rules. Which
> > doesn't mean everything needs to be as crappy as the overall Gentoo
> > 'quality'.  
> 
> you forgot "imo".  we've had commonly accepted standards that people generally
> kept to, some of which were more fuzzy than others.  but we've never had a hard
> 80 col rule and claiming that 72 col is an improvement is pretty hard to
> swallow.  there's no reasonable argument for such minimal restrictions in
> todays's world, and "it's always been that way" doesn't fly.

How about this; my terminal barely fits 90 characters? Of course,
I could then just shot arbitrarily at 90 but for 10 characters... I'd
rather use the old standard 80. Minus 8 characters for friendly e-mail
quoting, which is also kinda 'old standard'.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Mike Frysinger]

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

On 31 Oct 2015 09:08, Michał Górny wrote:
> On Sat, 31 Oct 2015 03:06:21 -0400 Mike Frysinger wrote:
> > On 30 Oct 2015 18:20, Michał Górny wrote:
> > > On Fri, 30 Oct 2015 12:03:59 +0000 (UTC) "Justin Lecher" wrote:  
> > > > --- a/eclass/distutils-r1.eclass
> > > > +++ b/eclass/distutils-r1.eclass
> > > > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() {
> > > >  
> > > >  	_distutils-r1_disable_ez_setup
> > > >  
> > > > -	if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]
> > > > -	then
> > > > +	if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]; then  
> > > 
> > > This was intentionally wrapped to stay within 72-column line width. Not
> > > saying the eclass is perfect in keeping text width, especially with
> > > others committing random changes to it, but that's no reason to
> > > introduce further offenders.  
> > 
> > Gentoo has never had a hard 80-col rule let alone 72-cols.  forcing a wrap
> > here makes no sense and the new version is an improvement.
> 
> For years, Gentoo was unable to make *any* *sane* *global* rules. Which
> doesn't mean everything needs to be as crappy as the overall Gentoo
> 'quality'.

you forgot "imo".  we've had commonly accepted standards that people generally
kept to, some of which were more fuzzy than others.  but we've never had a hard
80 col rule and claiming that 72 col is an improvement is pretty hard to
swallow.  there's no reasonable argument for such minimal restrictions in
todays's world, and "it's always been that way" doesn't fly.

> So what's this improvement exactly? 'I like this style better, so it's
> an improvement'? As I see it, it's a pointless, changing-nothing-really
> commit that causes huge cache regen for no good reason except someone's
> fancy.

one thing that has been consistent is cuddling of the initial command.  we do
not write:
	if foo
	then
	for x in 1 2 3
	do
	while true
	do
we have always written:
	if foo ; then
	for x in 1 2 3 ; do
	while true ; do

as for "why consistency", i think your e-mail is a bit confused here.  one on
hand you beoman lack of official hard style rules while on the other claiming
that none exist and being inconsistent is fine.

as for cache regen due to changed eclasses, meh, that happens every day, and for
eclasses more widely used than this.  it's a non-issue considering the caches
are generated on servers and distributed to users.
-mike

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ian Delaney]

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

On Fri, 30 Oct 2015 18:20:08 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 30 Oct 2015 12:03:59 +0000 (UTC)
> "Justin Lecher" <jlec@gentoo.org> wrote:
> 
> > commit:     df8e399c9bac2dc30d7cf69c2462a81729a3ae69
> > Author:     Justin Lecher <jlec <AT> gentoo <DOT> org>
> > AuthorDate: Fri Oct 30 10:18:05 2015 +0000
> > Commit:     Justin Lecher <jlec <AT> gentoo <DOT> org>
> > CommitDate: Fri Oct 30 12:03:49 2015 +0000
> > URL:
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df8e399c
> > 
> > eclass: Use consistent place for then in if clause
> 
> Excuse me but who are you exactly to take a random eclass and commit
> random style changes inside without even bothering to contact
> the author?
> 

Well, what's this? he selected a random eclass? Then he recklessly
committed a random style change? To my observation, the lead recruiter
specifically selected the distutils-r1 eclass, not some random one like
base.eclass, and carefully edited a couple of lines to put "; then" at
the end of a line as is done in most any ebuild. So how RANDOM is that?
In fact it isn't, however you have no hesitation in taking him to task
not only over its randomness which isn't, but that he had the gaul to do
it at all.

Was it not you who insisted that I assign a bug over the func
distutils_install_for_testing and you insisted I assign it to the
python team, not to you as I did. You lectured me to follow the rules
stating that it belongs to the python herd / project / w/e which may
be authored by its members any time in the future. It seems you want it
both ways.

jlec is not only a member of python team but he is high ranked. That
exactly is who he is.
> Not to mention this commit message is incorrect as it doesn't state
> which eclass was modified.
> 

This is in fact correct.
> > 
> > Signed-off-by: Justin Lecher <jlec <AT> gentoo.org>
> > 
> >  eclass/distutils-r1.eclass | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> > index 185dd4f..dbd27a7 100644
> > --- a/eclass/distutils-r1.eclass
> > +++ b/eclass/distutils-r1.eclass
> > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() {
> >  
> >  	_distutils-r1_disable_ez_setup
> >  
> > -	if [[ ${DISTUTILS_IN_SOURCE_BUILD} && !
> > ${DISTUTILS_SINGLE_IMPL} ]]
> > -	then
> > +	if [[ ${DISTUTILS_IN_SOURCE_BUILD} && !
> > ${DISTUTILS_SINGLE_IMPL} ]]; then
> 
> This was intentionally wrapped to stay within 72-column line width.
> Not saying the eclass is perfect in keeping text width, especially
> with others committing random changes to it, but that's no reason to
> introduce further offenders.
> 

there's that random again. Once and for all mgorny get off your high
horse.

> >  		# create source copies for each implementation
> >  		python_copy_sources
> >  	fi
> > 
> 
> 
> 



- -- 
kind regards

Ian Delaney
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1

iKYEARECAGYFAlY0u/1fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldDdDQUM1OUY0ODkzMERBREU1NUQ1RjJBRkIy
OEVDMjEzQjgwNzJCMEQACgkQso7CE7gHKw3xZQCgyQb6Tyuw73CiBHgxXm/bvPX7
L1EAn0UfLOZTERZpMJN1VQXIgb81AkE6
=yt+k
-----END PGP SIGNATURE-----


-- 
kind regards

Ian Delaney

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Gregory Woodbury]

Grammar and style police are everywhere!
This week are they shooting themselves in the foot over some totally
trivial and meaningless extra characters somewhere on a line?
Is it a case of "#TriviaDoesntMatter"?

AFAICT the limitations on line lengths are are ANCIENT holdovers
from days of fixed lenght cards and glass-teletypes. Totally meaningless
in today's terminal emulator in GUIs world.

It is certainly laudable to keep text block widths reasonable. It is fact that
it is easier to read text at 6 or 7 inches wide versus more than 8 inches.
BUT, it is also clear that a *consistent* style is easier to read instead of
needlessly varying styles in one document.

As for "being hesitant to touch anything anymore"...
Practically all of the FOSS projects have adopted rather stringent and
ridiculuous requirements that programmers and other have to jump
through hoops (of flame?) to prove their qualifications to do anything.
Gentoo is maybe one of the more conservative about having to go
through the motions in oder to qualify as a "developer" and, personally,
I no longer have the time or inclination (at my age of 62) to do so, just so
that my 50+ years of programming and typing can be subject to the
arbitrary rules.  I don't expect to be granted free access to the
code base without some oversight, but a code review by one or
more others before a commit would/should be more than adequate
to exclude bugs and blunders from being introduced.

Over the years I have done much for the FOSS movement, and I
have posted some small tools and scripts that some may find usefull, and
where possible I contribute via bugzilla. I much prefer Gentoo as a platform
since it is still committed to allowing the users to make significant
choices about the environment instead of imposing "one way" policies
as some other projects have done.

But seeing this little tempest merely convinces me that some folks
still don't get the point that some things of a substative nature
(such as correctness and choice) are of more importance than
other things (like "style" or options.)  Also, avoiding idiosyncratic
changes that have unforseen or un-intended consequences should
be coordinated with others before introduction to a stable system.

-- 
G.Wolfe Woodbury
redwolfe@gmail.com

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Sat, 31 Oct 2015 03:06:21 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On 30 Oct 2015 18:20, Michał Górny wrote:
> > On Fri, 30 Oct 2015 12:03:59 +0000 (UTC) "Justin Lecher" wrote:  
> > > commit:     df8e399c9bac2dc30d7cf69c2462a81729a3ae69
> > > Author:     Justin Lecher <jlec <AT> gentoo <DOT> org>
> > > AuthorDate: Fri Oct 30 10:18:05 2015 +0000
> > > Commit:     Justin Lecher <jlec <AT> gentoo <DOT> org>
> > > CommitDate: Fri Oct 30 12:03:49 2015 +0000
> > > URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df8e399c
> > > 
> > > eclass: Use consistent place for then in if clause  
> > 
> > Excuse me but who are you exactly to take a random eclass and commit
> > random style changes inside without even bothering to contact
> > the author?  
> 
> your attitude is wrong and is a great example of why people in the project
> are hesitant to touch anything anymore
> 
> > > Signed-off-by: Justin Lecher <jlec <AT> gentoo.org>
> > > 
> > >  eclass/distutils-r1.eclass | 3 +--
> > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > > 
> > > diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> > > index 185dd4f..dbd27a7 100644
> > > --- a/eclass/distutils-r1.eclass
> > > +++ b/eclass/distutils-r1.eclass
> > > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() {
> > >  
> > >  	_distutils-r1_disable_ez_setup
> > >  
> > > -	if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]
> > > -	then
> > > +	if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]; then  
> > 
> > This was intentionally wrapped to stay within 72-column line width. Not
> > saying the eclass is perfect in keeping text width, especially with
> > others committing random changes to it, but that's no reason to
> > introduce further offenders.  
> 
> Gentoo has never had a hard 80-col rule let alone 72-cols.  forcing a wrap
> here makes no sense and the new version is an improvement.

For years, Gentoo was unable to make *any* *sane* *global* rules. Which
doesn't mean everything needs to be as crappy as the overall Gentoo
'quality'.

So what's this improvement exactly? 'I like this style better, so it's
an improvement'? As I see it, it's a pointless, changing-nothing-really
commit that causes huge cache regen for no good reason except someone's
fancy.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Mike Frysinger]

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

On 30 Oct 2015 18:20, Michał Górny wrote:
> On Fri, 30 Oct 2015 12:03:59 +0000 (UTC) "Justin Lecher" wrote:
> > commit:     df8e399c9bac2dc30d7cf69c2462a81729a3ae69
> > Author:     Justin Lecher <jlec <AT> gentoo <DOT> org>
> > AuthorDate: Fri Oct 30 10:18:05 2015 +0000
> > Commit:     Justin Lecher <jlec <AT> gentoo <DOT> org>
> > CommitDate: Fri Oct 30 12:03:49 2015 +0000
> > URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df8e399c
> > 
> > eclass: Use consistent place for then in if clause
> 
> Excuse me but who are you exactly to take a random eclass and commit
> random style changes inside without even bothering to contact
> the author?

your attitude is wrong and is a great example of why people in the project
are hesitant to touch anything anymore

> > Signed-off-by: Justin Lecher <jlec <AT> gentoo.org>
> > 
> >  eclass/distutils-r1.eclass | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> > index 185dd4f..dbd27a7 100644
> > --- a/eclass/distutils-r1.eclass
> > +++ b/eclass/distutils-r1.eclass
> > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() {
> >  
> >  	_distutils-r1_disable_ez_setup
> >  
> > -	if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]
> > -	then
> > +	if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]; then
> 
> This was intentionally wrapped to stay within 72-column line width. Not
> saying the eclass is perfect in keeping text width, especially with
> others committing random changes to it, but that's no reason to
> introduce further offenders.

Gentoo has never had a hard 80-col rule let alone 72-cols.  forcing a wrap
here makes no sense and the new version is an improvement.
-mike

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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

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

On Fri, 30 Oct 2015 12:03:59 +0000 (UTC)
"Justin Lecher" <jlec@gentoo.org> wrote:

> commit:     df8e399c9bac2dc30d7cf69c2462a81729a3ae69
> Author:     Justin Lecher <jlec <AT> gentoo <DOT> org>
> AuthorDate: Fri Oct 30 10:18:05 2015 +0000
> Commit:     Justin Lecher <jlec <AT> gentoo <DOT> org>
> CommitDate: Fri Oct 30 12:03:49 2015 +0000
> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df8e399c
> 
> eclass: Use consistent place for then in if clause

Excuse me but who are you exactly to take a random eclass and commit
random style changes inside without even bothering to contact
the author?

Not to mention this commit message is incorrect as it doesn't state
which eclass was modified.

> 
> Signed-off-by: Justin Lecher <jlec <AT> gentoo.org>
> 
>  eclass/distutils-r1.eclass | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index 185dd4f..dbd27a7 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() {
>  
>  	_distutils-r1_disable_ez_setup
>  
> -	if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]
> -	then
> +	if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]; then

This was intentionally wrapped to stay within 72-column line width. Not
saying the eclass is perfect in keeping text width, especially with
others committing random changes to it, but that's no reason to
introduce further offenders.

>  		# create source copies for each implementation
>  		python_copy_sources
>  	fi
> 



-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[hasufell]

On 10/09/2015 06:21 PM, Alexis Ballier wrote:
>> Ofc, I will expect people to jump in and say "the council hasn't
>> decided on that yet", but well... it mostly works fine and is not
>> really controversial.
> 
> not sure if council approval is needed; uniformity and consistency is
> way more important than whatever syntax is used
> 

I agree.

There is https://bugs.gentoo.org/show_bug.cgi?id=561190 and
https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:66 but as you can see
it is mostly empty.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Alexis Ballier]

On Fri, 9 Oct 2015 17:32:22 +0200
hasufell <hasufell@gentoo.org> wrote:

> On 10/09/2015 01:17 PM, Alexis Ballier wrote:
> > commit:     5220bb29741e1685b42a6312c0b7bf2821672040
> > Author:     Alexis Ballier <aballier <AT> gentoo <DOT> org>
> > AuthorDate: Fri Oct  9 11:16:38 2015 +0000
> > Commit:     Alexis Ballier <aballier <AT> gentoo <DOT> org>
> > CommitDate: Fri Oct  9 11:16:52 2015 +0000
> > URL:
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5220bb29
> > 
> > eclass: ros-catkin.eclass: Use cmake-utils_src_make instead of
> > plain emake for src_test so that it works with ninja too.
> > 
> 
> 
> Please try to use short summary lines and put more detailed
> description into the commit message after a newline, also see
> https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Example
> 
> The prefix is also a bit uncommon, see
> https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Commit_message_format

yeah, got that wrong; thx; i tried to remember it as '$dir: message',
which works in all but this case it seems :)

> Ofc, I will expect people to jump in and say "the council hasn't
> decided on that yet", but well... it mostly works fine and is not
> really controversial.

not sure if council approval is needed; uniformity and consistency is
way more important than whatever syntax is used

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[hasufell]

On 10/09/2015 01:17 PM, Alexis Ballier wrote:
> commit:     5220bb29741e1685b42a6312c0b7bf2821672040
> Author:     Alexis Ballier <aballier <AT> gentoo <DOT> org>
> AuthorDate: Fri Oct  9 11:16:38 2015 +0000
> Commit:     Alexis Ballier <aballier <AT> gentoo <DOT> org>
> CommitDate: Fri Oct  9 11:16:52 2015 +0000
> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5220bb29
> 
> eclass: ros-catkin.eclass: Use cmake-utils_src_make instead of plain emake for src_test so that it works with ninja too.
> 


Please try to use short summary lines and put more detailed description
into the commit message after a newline, also see
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Example

The prefix is also a bit uncommon, see
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Commit_message_format

Ofc, I will expect people to jump in and say "the council hasn't decided
on that yet", but well... it mostly works fine and is not really
controversial.