[gentoo-portage-dev] [PATCH] repoman: deprecated_classes -> ...eclasses, to ease grep

[Michał Górny]

Rename deprecated_classes list to deprecated_eclasses, since the latter
is less ambiguous and easier to find.

Signed-off-by: Michał Górny 
---
 pym/repoman/checks/ebuilds/checks.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/pym/repoman/checks/ebuilds/checks.py 
b/pym/repoman/checks/ebuilds/checks.py
index 245ab2b..ae6d96e 100644
--- a/pym/repoman/checks/ebuilds/checks.py
+++ b/pym/repoman/checks/ebuilds/checks.py
@@ -408,7 +408,7 @@ class InheritDeprecated(LineCheck):
repoman_check_name = 'inherit.deprecated'
 
# deprecated eclass : new eclass (False if no new eclass)
-   deprecated_classes = {
+   deprecated_eclasses = {
"bash-completion": "bash-completion-r1",
"boost-utils": False,
"distutils": "distutils-r1",
@@ -436,7 +436,7 @@ class InheritDeprecated(LineCheck):
return
 
for eclass in direct_inherits:
-   replacement = self.deprecated_classes.get(eclass)
+   replacement = self.deprecated_eclasses.get(eclass)
if replacement is None:
pass
elif replacement is False:
-- 
2.6.1

[gentoo-portage-dev] [PATCH] repoman: Finally deprecate base.eclass

[Michał Górny]

Contributors are repeatedly adding base.eclass uses, so we should
finally make the deprecation formal, even at the cost of adding warnings
for some frequently used eclasses.

Signed-off-by: Michał Górny 
---
 pym/repoman/checks/ebuilds/checks.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/pym/repoman/checks/ebuilds/checks.py 
b/pym/repoman/checks/ebuilds/checks.py
index ae6d96e..a00d518 100644
--- a/pym/repoman/checks/ebuilds/checks.py
+++ b/pym/repoman/checks/ebuilds/checks.py
@@ -409,6 +409,7 @@ class InheritDeprecated(LineCheck):
 
# deprecated eclass : new eclass (False if no new eclass)
deprecated_eclasses = {
+   "base": False,
"bash-completion": "bash-completion-r1",
"boost-utils": False,
"distutils": "distutils-r1",
-- 
2.6.1

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Ian Delaney]

On Sun, 11 Oct 2015 19:17:58 +1100
wraeth  wrote:

> On 11/10/15 18:52, Ian Delaney wrote:
> > On Sat, 10 Oct 2015 16:27:15 +0200 Alexis Ballier
> >  wrote:
> > 
> 
> I am one of the users who spoke to idella4 about this, but I wanted to
> repeat this publicly in order to highlight the point of view of
> contributing user as opposed to a developer.
> 
> Firstly I would like to say that I appreciate feedback on my work - it
> helps me to improve the quality of my work both for Gentoo and
> personally.
> 
> I also agree whole-heartedly to the concept of the Reviewers project,
> in that highlighting common improvements that could be made would
> benefit both contributors who participate and Gentoo as a whole.
> 
> Having said that, however, I do not appreciate the method in which
> these criticisms were delivered, and believe it extends beyond the
> idea of the Reviewers project.
> 
> I feel that it is inappropriate for criticisms of contributor's work
> to be broadcast on a mailing list that is read not only by the
> developer community, but by users as well, without their consent.
> This is not a case where I am particularly embarrassed or upset - if
> others can learn from my mistakes, then they are mistakes I am happy
> to make (preferably only once). But doing so publicly, with
> identifying information, is inappropriate.
> 
> Like I said, I welcome input that would improve my contributions, but
> I am concerned that the way that the Reviewers project has been
> undertaken so far is leading more into an extended QA with standards
> that go beyond the enforcement of established Gentoo policy.
> 
> Kind Regards;
> 

I support wraeth's views. He is a keen and fine contributor to gentoo

-- 
kind regards

Ian Delaney


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Manuel Rüger]

On 11.10.2015 10:29, Brendan Horan wrote:
> - On 11 Oct, 2015, at 4:17 PM, wraeth wra...@wraeth.id.au wrote:
> 
>> On 11/10/15 18:52, Ian Delaney wrote:
>>> On Sat, 10 Oct 2015 16:27:15 +0200 Alexis Ballier
>>>  wrote:
>>>
 On Sat, 10 Oct 2015 10:09:11 +0200 Michał Górny
  wrote:

> Hello, developers.
>
> I have the pleasure
>>>
>>> :?
>>>
> to announce that we have formed a new Reviewers team [1] for
> Gentoo. The team is going to assemble developers willing to
> perform ebuild reviews and help contributors improve their
> ebuild skills.
>
> The main goal of the team is to handle GitHub pull requests. We
> are going to review incoming PRs, communicate with maintainers
> and merge them as appropriate. In particular, we're going to
> help willing contributors get high-quality, PGP-signed commits
> into Gentoo, therefore helping them prepare to become Gentoo
> developers.

 This is cool

> The side goal is to review current Gentoo commits for major QA
> violations and other issues, aiming at improving the quality
> of ebuilds in Gentoo and helping other developers using bash,
> ebuilds and git effectively.

 This is completely unrelated: since we've had gentoo-commits ml,
>>>
>>> which was promptly utlised
>>>
 every one has been able to do commit reviews easily, and most
 devs have done so. Self-proclamed reviewers project certainly
 does not have the monopoly of best practices nor perfect
 knowledge. I hope they do keep the monopoly of being harassing
 though :)

 Also, you should probably focus on what's really important:
 reviews like "this is weird, care to explain?" or stylistic
 nitpicks are just a waste of every one time, meaning more
 important stuff does not get done.

>>>
>>> To my observation the reaction to this has been between displeasure
>>> and dismay.  Yesterday the dev-ML was flooded with the first day's
>>> publication of the members' reviews. Firstly the gentoo-commits ML
>>> to my understanding is intended to be used for and by qa members.
>>> This project has one whom we presume has the discretion to declare
>>> the use of the qa hat at whim.
>>>
>>> As someone once put it, it's not the product or message it's the
>>> delivery of the package.  This project in its creation is made of
>>> self appointed members who assume the status and qualification to
>>> suddenly launch their evaluations upon unsuspecting folk the
>>> community wide with neither  warning  nor their prior knowledge nor
>>> consent. The editing to the page illustrates already significant
>>> back pedalling from feedback already challenging its selected mode
>>> of delivery.
>>>
>>> The project goals and 'would be' mission statement are in fact
>>> legitimate and have the backing of Council members.  The execution
>>> has been done independently, unilaterally and with no input or
>>> collaboration with Council to my knowledge.  The actions of this
>>> project potentially impact on every developer / user of the gentoo
>>> project, addressing the core skills of both. Yet it has been made,
>>> announced and executed in this style.
>>>
>>> I invested study time in several units in teaching and lecturing in
>>> my university education under the education department. Sorry but
>>> the modi operandi by these self proclaimed teachers and educators
>>> thus far violate almost every fundamental principle in the art of
>>> teaching that I learned from the course. There have also been users
>>> who have expressed concern to me over this directly, some of which
>>> have indicated they will also email this list to make their views
>>> known.
>>
>> I am one of the users who spoke to idella4 about this, but I wanted to
>> repeat this publicly in order to highlight the point of view of
>> contributing user as opposed to a developer.
>>
>> Firstly I would like to say that I appreciate feedback on my work - it
>> helps me to improve the quality of my work both for Gentoo and personally.
>>
>> I also agree whole-heartedly to the concept of the Reviewers project, in
>> that highlighting common improvements that could be made would benefit
>> both contributors who participate and Gentoo as a whole.
>>
>> Having said that, however, I do not appreciate the method in which these
>> criticisms were delivered, and believe it extends beyond the idea of
>> the Reviewers project.
>>
>> I feel that it is inappropriate for criticisms of contributor's work to
>> be broadcast on a mailing list that is read not only by the developer
>> community, but by users as well, without their consent. This is not a
>> case where I am particularly embarrassed or upset - if others can learn
>> from my mistakes, then they are mistakes I am happy to make (preferably
>> only once). But doing so publicly, with identifying information, is
>> inappropriate.
> 
> I will second your 

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/11/2015 09:52 AM, Ian Delaney wrote:
> 
> To my observation the reaction to this has been between displeasure and
> dismay.  Yesterday the dev-ML was flooded with the first day's
> publication of the members' reviews. Firstly the gentoo-commits ML to my
> understanding is intended to be used for and by qa members. This
> project has one whom we presume has the discretion to declare the use
> of the qa hat at whim.
> 

People have been responding to gentoo-commits ML on dev ML since years.
But mostly on smaller scale. I have no knowledge that this is restricted
to QA members.

The reason this dev-ML attempt was chosen is that we got very hostile
and aggressive opinions about our Github activity, telling us it is not
only against the social contract, but also not properly "public" and
everything in gentoo should be public on our own infra channels (they said).

So it seems... however you do it, you do it wrong. Github reviews are
not on our own infra channels, private mails are not public, don't spam
bugzilla, don't spam the ML... It's not particularly easy to not do it
wrong when you have so little options.

I suspect this is not even primarily about the chosen platform, but
about the fact that review culture can introduce a few negative thoughts
such as embarrassment. In order to fix that, we are going to focus the
reviews on Github (for developers who are known to be active there),
private mails and semi-private mails to aliases. In addition, it will
also require a shift of thinking. Reviews are not about exposing a
person, but about improving quality and knowledge. For both parties.

But I guess I have to make one point very clear again: we are not
affiliated with the QA team and this is an attempt to induct peer
reviews (even when private), since this has never happened on larger
scale in gentoo and people were just reverse-fixing mistakes instead of
communicating them in the first place. Which means a great loss for our
self-education.

So it seems a lot of people have got it wrong what the project is about.
It's specifically and explicitly not what the QA team is about, which we
said from the very start. It's not about a reviewers monopoly. It's
about the opposite.

> As someone once put it, it's not the product or message it's the
> delivery of the package

Yeah, so we can either dwell on that or start looking at the actual
product, which I'd expect from the gentoo community.

Re: [gentoo-dev] Dynamic dependencies

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/11/2015 01:21 PM, Rich Freeman wrote:
> On Thu, Sep 17, 2015 at 7:57 AM, Kristian Fiskerstrand 
>  wrote:
>> 
>> Another thing that strikes me is separation of stable vs ~arch 
>> behavior.
>> 


..

> 
> I'm not sure that we're doing stable users a favor by not 
> "disturbing" them with rebuilds but instead we're just silently 
> breaking their systems in subtle ways.  I think that if anybody 
> would benefit from a more conservative approach it would be the 
> stable users.

I think we are mostly in agreement, actually, the point wasn't about
the rebuild following a bump (which is necessary for vdb update and
indeed gets rid of issues down the road), it was more about whether it
is prudent to change eclasses used by stable packages without bumping
revision, and being careful in this consideration when selecting to
set deps in eclasses rather than directly in ebuild in the first place.

> 
> I'm all for having a separate discussion around when it is and 
> isn't appropriate to modify eclasses that are used by stable 
> packages in the first place.

Yeah, I don't think this discussion impacts the proposals you've
outlined for dyndeps, thanks for summing things up.

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWGkguAAoJECULev7WN52Fz7AIAK9CqQTXmduz17pydV4yzHwX
VIkEQ/5p+BoJixEceSLJo1KN2IBcDNHeZeyUgjxbY3yO/LuB+VzNzQk87gvaAKGw
EY81KJy7Y44vzejeMR1k1c7nnAtgaoyYgd2xAce57BPwvHVRtNJPTZeyvOunQiMo
bq5fB2IMrPrd59NdaM0ncF2Z5Cpx/0RMMyo2tQK2wTdF7I4upzjWiR9EwM39yyhC
OIHLXO6pj+1fFxrtUAPV5lnBs15FxRKwLRNfDOcvhOKlHnjgr9QinJcG4gvczq7+
v/Faw/NNO1b5qzYcprQsvWEk4lBvy29RF555cBxvEWU3z9LhyDbXdQldY6QNy4c=
=9Vcc
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[wraeth]

On 11/10/15 18:52, Ian Delaney wrote:
> On Sat, 10 Oct 2015 16:27:15 +0200 Alexis Ballier
>  wrote:
> 
>> On Sat, 10 Oct 2015 10:09:11 +0200 Michał Górny
>>  wrote:
>> 
>>> Hello, developers.
>>> 
>>> I have the pleasure
> 
> :?
> 
>>> to announce that we have formed a new Reviewers team [1] for
>>> Gentoo. The team is going to assemble developers willing to
>>> perform ebuild reviews and help contributors improve their
>>> ebuild skills.
>>> 
>>> The main goal of the team is to handle GitHub pull requests. We
>>> are going to review incoming PRs, communicate with maintainers
>>> and merge them as appropriate. In particular, we're going to
>>> help willing contributors get high-quality, PGP-signed commits
>>> into Gentoo, therefore helping them prepare to become Gentoo
>>> developers.
>> 
>> This is cool
>> 
>>> The side goal is to review current Gentoo commits for major QA 
>>> violations and other issues, aiming at improving the quality
>>> of ebuilds in Gentoo and helping other developers using bash,
>>> ebuilds and git effectively.
>> 
>> This is completely unrelated: since we've had gentoo-commits ml,
> 
> which was promptly utlised
> 
>> every one has been able to do commit reviews easily, and most
>> devs have done so. Self-proclamed reviewers project certainly
>> does not have the monopoly of best practices nor perfect
>> knowledge. I hope they do keep the monopoly of being harassing
>> though :)
>> 
>> Also, you should probably focus on what's really important:
>> reviews like "this is weird, care to explain?" or stylistic
>> nitpicks are just a waste of every one time, meaning more
>> important stuff does not get done.
>> 
> 
> To my observation the reaction to this has been between displeasure
> and dismay.  Yesterday the dev-ML was flooded with the first day's 
> publication of the members' reviews. Firstly the gentoo-commits ML
> to my understanding is intended to be used for and by qa members.
> This project has one whom we presume has the discretion to declare
> the use of the qa hat at whim.
> 
> As someone once put it, it's not the product or message it's the 
> delivery of the package.  This project in its creation is made of
> self appointed members who assume the status and qualification to
> suddenly launch their evaluations upon unsuspecting folk the
> community wide with neither  warning  nor their prior knowledge nor
> consent. The editing to the page illustrates already significant
> back pedalling from feedback already challenging its selected mode
> of delivery.
> 
> The project goals and 'would be' mission statement are in fact 
> legitimate and have the backing of Council members.  The execution
> has been done independently, unilaterally and with no input or
> collaboration with Council to my knowledge.  The actions of this
> project potentially impact on every developer / user of the gentoo
> project, addressing the core skills of both. Yet it has been made,
> announced and executed in this style.
> 
> I invested study time in several units in teaching and lecturing in
> my university education under the education department. Sorry but
> the modi operandi by these self proclaimed teachers and educators
> thus far violate almost every fundamental principle in the art of
> teaching that I learned from the course. There have also been users
> who have expressed concern to me over this directly, some of which
> have indicated they will also email this list to make their views
> known.

I am one of the users who spoke to idella4 about this, but I wanted to
repeat this publicly in order to highlight the point of view of
contributing user as opposed to a developer.

Firstly I would like to say that I appreciate feedback on my work - it
helps me to improve the quality of my work both for Gentoo and personally.

I also agree whole-heartedly to the concept of the Reviewers project, in
that highlighting common improvements that could be made would benefit
both contributors who participate and Gentoo as a whole.

Having said that, however, I do not appreciate the method in which these
criticisms were delivered, and believe it extends beyond the idea of
the Reviewers project.

I feel that it is inappropriate for criticisms of contributor's work to
be broadcast on a mailing list that is read not only by the developer
community, but by users as well, without their consent. This is not a
case where I am particularly embarrassed or upset - if others can learn
from my mistakes, then they are mistakes I am happy to make (preferably
only once). But doing so publicly, with identifying information, is
inappropriate.

Like I said, I welcome input that would improve my contributions, but
I am concerned that the way that the Reviewers project has been
undertaken so far is leading more into an extended QA with standards
that go beyond the enforcement of established Gentoo policy.

Kind Regards;

-- 
Sam Jorna (wraeth) 
GnuPG Key: B2D9F759

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

[Duncan]

Rich Freeman posted on Sat, 10 Oct 2015 10:30:32 -0400 as excerpted:

> I don't think it is a bad thing if you wanted to publish the top-5
> issues of the week/month/etc on the lists or something useful for
> general education/improvement.  The key is to keep the general relevance
> of the lists high.

++ on the top-5 idea.  That would let people know what the most common 
problems are, without singling out individuals (unless they're doing 
enough commits with the same mistake to end up in the top-5 all by 
themselves).

k_f's idea of putting it on the wiki could be done too, with the top-5 
post here linking the wiki for details like specific commits, etc.  That 
would leave them out of the posting here, helping to further remove any 
feeling of personal finger-pointing and to make it more about the most 
common problems and the easiest way to avoid them.

It'll be interesting to see how the most common issues and the number of 
occurrences thereof then change over time, and that should help in terms 
of review-project feedback as well.  Less directly publicized as ideally, 
individual offenders aren't named in the top-five posts themselves, but 
also helpful in terms of feedback and also possibly of interest to QA 
over longer periods, would be whether the same problems continue to show 
up from the same people, or whether once they're alerted to them, they 
improve, and even if the problem continues to appear in the top-5, it's 
not the same people repeating the same problem.

-- 
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: Dynamic dependencies

[Rich Freeman]

On Fri, Oct 2, 2015 at 5:46 AM, Rich Freeman  wrote:
> On Fri, Oct 2, 2015 at 2:22 AM, Martin Vaeth  wrote:
>> Rich Freeman  wrote:
>>>
>>> Proposal 3a might be: Anytime an RDEPEND in an eclass is changed, the
>>> eclass must be revisioned unless all ebuilds in the gentoo repository
>>> will continue to work correctly with the old RDEPEND.
>>> Proposal 4a might be: Anytime an RDEPEND in an eclass is changed, all
>>> ebuilds that inherit the eclass in the gentoo repository must be
>>> revisioned if they will not continue to work correctly with the old
>>> RDEPEND.
>>
>> Adding an || alternative should be included here:
>> The installed package would continue to work without that alternative,
>> but without a revbump the user is not able to see that he might
>> possibly drop a package.
>>
>
> Perhaps add "or if the new RDEPEND allows the ebuild to work with
> additional dependencies."  Or maybe just straight out say "or if
> additional || atoms are added."  The first wording might allow for
> additional cases, which is probably good.
>

So, here is a consolidated list of the latest proposals:

RDEPEND changes directly in ebuilds (non-virtual and virtual)
Proposal 5: Anytime an RDEPEND in an ebuild is changed, the
ebuild must be revisioned.  This includes adding/removing inherited
eclasses which set RDEPENDs.


RDEPEND changes in eclasses
Proposal 3b: Anytime an RDEPEND in an eclass is changed, the
eclass must be revisioned unless:
1. all ebuilds in the gentoo repository will continue to work
correctly with the old RDEPEND,
2. and the new RDEPEND is a subset of the old RDEPEND


Proposal 4b: Anytime an RDEPEND in an eclass is changed, all
ebuilds that inherit the eclass in the gentoo repository must be
revisioned unless:
1. all ebuilds in the gentoo repository will continue to work
correctly with the old RDEPEND,
2. and the new RDEPEND is a subset of the old RDEPEND.


>From the tone of discussion the wording of the eclass proposals still
might be a bit conservative, and there may be other cases where we
could avoid bumps.  However, I think this does cover the examples that
actually came up.


Here are ones that i consider outdated:
RDEPEND changes directly in ebuilds
Proposal 1: Anytime an RDEPEND in a non-virtual ebuild is changed, the
ebuild must be revisioned.  This includes adding/removing inherited
eclasses which set RDEPENDs.

RDEPEND changes directly in virtuals
Proposal 2: Anytime an RDEPEND in a virtual ebuild is changed, the
ebuild must be revisioned.  This includes adding/removing inherited
eclasses which set RDEPENDs.

RDEPEND changes in eclasses
Proposal 3: Anytime an RDEPEND in an eclass is changed, the eclass
must be revisioned.
Proposal 4: Anytime an RDEPEND in an eclass is changed, all ebuilds
that inherit the eclass in the gentoo repository must be revisioned.
Proposal 3a: Anytime an RDEPEND in an eclass is changed, the
eclass must be revisioned unless all ebuilds in the gentoo repository
will continue to work correctly with the old RDEPEND.
Proposal 4a: Anytime an RDEPEND in an eclass is changed, all
ebuilds that inherit the eclass in the gentoo repository must be
revisioned if they will not continue to work correctly with the old
RDEPEND.

-- 
Rich

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Alexis Ballier]

On Sun, 11 Oct 2015 13:04:31 +0200
hasufell  wrote:

> On 10/11/2015 09:52 AM, Ian Delaney wrote:
> > 
> > To my observation the reaction to this has been between displeasure
> > and dismay.  Yesterday the dev-ML was flooded with the first day's
> > publication of the members' reviews. Firstly the gentoo-commits ML
> > to my understanding is intended to be used for and by qa members.
> > This project has one whom we presume has the discretion to declare
> > the use of the qa hat at whim.
> > 
> 
> People have been responding to gentoo-commits ML on dev ML since
> years. But mostly on smaller scale. I have no knowledge that this is
> restricted to QA members.

True

> The reason this dev-ML attempt was chosen is that we got very hostile
> and aggressive opinions about our Github activity, telling us it is
> not only against the social contract, but also not properly "public"
> and everything in gentoo should be public on our own infra channels
> (they said).
> 
> So it seems... however you do it, you do it wrong. Github reviews are
> not on our own infra channels, private mails are not public, don't
> spam bugzilla, don't spam the ML... It's not particularly easy to not
> do it wrong when you have so little options.


Draw some line: Stuff that concerns a single, isolated issue, is sent
privately. Repeated issues go to -dev, to let everyone know, stating
clearly that the commit is random and that the issue has been
repeatedly found in various commits from various people.

Once this line is drawn, you'll probably realize what kind of doc or
guide is missing :)


> I suspect this is not even primarily about the chosen platform, but
> about the fact that review culture can introduce a few negative
> thoughts such as embarrassment. In order to fix that, we are going to
> focus the reviews on Github (for developers who are known to be
> active there), private mails and semi-private mails to aliases. In
> addition, it will also require a shift of thinking. Reviews are not
> about exposing a person, but about improving quality and knowledge.
> For both parties.


For what concerns me, please use emails even if I'm active on github:
I've failed to receive several notifications from github in the past,
and I don't monitor everything that happens here.

[...]

Alexis.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Sven Vermeulen]

On Sat, Oct 10, 2015 at 10:09:11AM +0200, Michał Górny wrote:
> I have the pleasure to announce that we have formed a new Reviewers
> team [1] for Gentoo. The team is going to assemble developers willing
> to perform ebuild reviews and help contributors improve their ebuild
> skills.
> 
> The main goal of the team is to handle GitHub pull requests. We are
> going to review incoming PRs, communicate with maintainers and merge
> them as appropriate. In particular, we're going to help willing
> contributors get high-quality, PGP-signed commits into Gentoo,
> therefore helping them prepare to become Gentoo developers.
> 
> The side goal is to review current Gentoo commits for major QA
> violations and other issues, aiming at improving the quality of ebuilds
> in Gentoo and helping other developers using bash, ebuilds and git
> effectively.
> 
> [1]:https://wiki.gentoo.org/wiki/Project:Reviewers

This is good news. There are quite a few developers that manage a small
subset of packages while doing tremendous work for Gentoo within that
community. For instance, they focus on particular deliverables in
repositories which eventually get packaged, or on integration of certain
components which have a strong, broader community coverage.

These developers will certainly welcome any helping hand (even post-commit)
in keeping packages of high quality.

I hope you will also focus on the documentation side. Certain processes that
we follow within Gentoo (for commits, for instance the Git workflow) would
benefit from a good document *set* (yes, set, as you'll definitely want such
processes to have both a single-screen version as well as an elaborate
version).

I've also found myself often looking for similar ebuilds in which a certain
problem would already have been implemented. For instance, ebuilds with an
optional python part using the python-r1 eclass. Do you think it is
worthwhile to have a number of packages assigned as good examples?

Wkr,
Sven Vermeulen

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Ian Delaney]

On Sat, 10 Oct 2015 16:27:15 +0200
Alexis Ballier  wrote:

> On Sat, 10 Oct 2015 10:09:11 +0200
> Michał Górny  wrote:
> 
> > Hello, developers.
> > 
> > I have the pleasure 

:?

> > to announce that we have formed a new Reviewers
> > team [1] for Gentoo. The team is going to assemble developers
> > willing to perform ebuild reviews and help contributors improve
> > their ebuild skills.
> > 
> > The main goal of the team is to handle GitHub pull requests. We are
> > going to review incoming PRs, communicate with maintainers and merge
> > them as appropriate. In particular, we're going to help willing
> > contributors get high-quality, PGP-signed commits into Gentoo,
> > therefore helping them prepare to become Gentoo developers.
> 
> This is cool
> 
> > The side goal is to review current Gentoo commits for major QA
> > violations and other issues, aiming at improving the quality of
> > ebuilds in Gentoo and helping other developers using bash, ebuilds
> > and git effectively.
> 
> This is completely unrelated: since we've had gentoo-commits ml,

which was promptly utlised

> every one has been able to do commit reviews easily, and most devs
> have done so. Self-proclamed reviewers project certainly does not
> have the monopoly of best practices nor perfect knowledge. I hope
> they do keep the monopoly of being harassing though :)
> 
> Also, you should probably focus on what's really important: reviews
> like "this is weird, care to explain?" or stylistic nitpicks are just
> a waste of every one time, meaning more important stuff does not get
> done.
> 

To my observation the reaction to this has been between displeasure and
dismay.  Yesterday the dev-ML was flooded with the first day's
publication of the members' reviews. Firstly the gentoo-commits ML to my
understanding is intended to be used for and by qa members. This
project has one whom we presume has the discretion to declare the use
of the qa hat at whim.

As someone once put it, it's not the product or message it's the
delivery of the package.  This project in its creation is made of self
appointed members who assume the status and qualification to suddenly
launch their evaluations upon unsuspecting folk the community wide with
neither  warning  nor their prior knowledge nor consent. The editing
to the page illustrates already significant back pedalling from feedback
already challenging its selected mode of delivery.

The project goals and 'would be' mission statement are in fact
legitimate and have the backing of Council members.  The execution has
been done independently, unilaterally and with no input or collaboration
with Council to my knowledge.  The actions of this project potentially
impact on every developer / user of the gentoo project, addressing the
core skills of both. Yet it has been made, announced and executed in
this style. 

I invested study time in several units in teaching and lecturing in my
university education under the education department. Sorry but the
modi operandi by these self proclaimed teachers and educators thus far
violate almost every fundamental principle in the art of teaching that
I learned from the course. There have also been users who have
expressed concern to me over this directly, some of which have
indicated they will also email this list to make their views known.


-- 
kind regards

Ian Delaney

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Alexis Ballier]

On Sat, 10 Oct 2015 20:37:39 +0200
hasufell  wrote:
[...]
> >> This is just a concept of peer-reviewing, which was very difficult
> >> in CVS times.
> > 
> > I fail to see how post-commit reviews are made easier with git.
> > 
> 
> Quite offtopic, but we could discuss this off-list if you want.


You could just have said why. I don't see a difference between
reviewing gentoo-commits from cvs than reviewing gentoo-commits from
git. Maybe there's something you prefer, that I don't use, and I can't
debate your preferences.


> > [...]
> >>> Also, you should probably focus on what's really important:
> >>> reviews like "this is weird, care to explain?" or stylistic
> >>> nitpicks are just a waste of every one time, meaning more
> >>> important stuff does not get done.
> >>>
> >>
> >> 'has_version' (which you are probably referring to) as a
> >> conditional for sedding headers is more than just "weird" and
> >> indicates a serious build system bug that needs to be addressed
> >> properly.
> > 
> > It indicates a conditional fix. Just as the code says.
> 
> It's a hack, not a fix. And as such, it is worth discussing.

"It's a hack", "indicates a serious build system bug that needs to be
addressed", etc. : such comments are critics, a bit aggressive, and call
for more aggressiveness. In order to help, and have it welcomed, you
should probably try a bit more of courtesy :)
Not everyone has an "hasufell-translator" reading "hack" as "build
fix" :)

> > Before throwing
> > an email to -dev ml, I would have expected a reviewer to do his
> > homework and try to understand what the condition is, when it will
> > be satisfied, and why this was conditional. There is absolutely
> > nothing wrong about not knowing the answer, but using -dev ml for
> > it is a bit spammy IMHO.
> > 
> 
> I did have a look. I was checking both packages (dev-libs/libcdio and
> dev-libs/libcdio-paranoia) for the header and made up my own mind
> about this. I was still wondering if the maintainer even knows what
> this is about.

I don't think you can make a proper opinion on this without the history
of the split. The code in question is actually correct, it could just
benefit a bit of cleanup for legacy stuff. But again, nobody expects
you to know that.

Reviewing is about pointing out improvements, so in that case that
would be:
"Hi, the code you're sedding is actually only compiled when USE=cdda is
set, which actually always pulls dev-libs/libcdio-paranoia, so it seems
to me the conditional could be dropped for clarity."

This is what makes the difference between helpful reviews and critics
or even testing "if the maintainer even knows what this is about" :)

[...]

Alexis.

[gentoo-dev] Re: rfc: multilib and fhs 3

[Duncan]

William Hubbs posted on Sat, 10 Oct 2015 17:48:15 -0500 as excerpted:

> All,
> 
> fhs 3.0 was approved in June this year [1] [2].
> 
> The piece of it that I want to bring up is the lib and libxx
> directories, both in / and /usr. The way I read the fhs, /lib and
> /usr/lib should hold the files for the default abi and /libxx and
> /usr/libxx should hold the files for the alternate abis. In earlier fhs,
> there was an exception for amd64 which stated that the default libraries
> should be in /lib64 and /usr/lib64. However, that exception is now gone.
> 
> I know there was discussion/work in the past on removing the lib->lib64
> symlinks on amd64, but I don't remember what happened to that
> discussion. So, I would like to bring it up again and get the info.
> 
> What would it take for us to remove the lib->lib64 links?
> 
> What would it take for us to do this migration on live systems?
> 
> William
> 
> [1] https://wiki.linuxfoundation.org/en/FHS [2]
> http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html

I don't know what the current status is, but years ago, I used to run 
portage with FEATURES=multilib-strict.  There weren't many violations in 
my installed base at the time, and when there were I filed bugs.

This biggest problems didn't have to do with installing to the wrong 
place, but rather, with configuration paths, etc, not being corrected, 
resulting in runtime errors if lib and lib64 were not in fact the same 
directory, via symlink or whatever.  IIRC, openrc itself, or at least 
some openrc initscripts, possibly owned by other packages, was quite a 
headache in that regard.

However, I killed multilib-strict some years ago when I went no-multilib, 
and after experiencing problems when lib and lib64 weren't in fact the 
same dir, I've not touched those symlinks in years, plus I run systemd 
now so wouldn't know about openrc's status even if I was aware of the 
general status, so I've no idea what the current status is.

But multilib-strict in fact checks that packages use lib64 for 64-bit elf 
libs (tho I think it might actually get the specifics from the profile, 
the amd64 or portage folks should be able to say for sure), failing the 
install if lib is used instead, so if in fact FHS 3.0 reverses that, we'd 
either have to reverse its check, or possibly configure a test to some 
third directory, and then do a test run to catch anything that's 
installing to either location, hard-coded.

Tho as I said, the actual installed installation isn't the entire 
problem.  Multilib-strict doesn't catch it when a binary is installed to 
the right place, but some configuration hard-coding isn't corrected and 
still points elsewhere, so if the two locations aren't symlinked or 
otherwise actually the same location, things break.  That's somewhat 
harder to find, and in my experience, the worse headache to try to deal 
with, since it's often only caught at runtime, and even then, may only be 
caught in specific corner-cases when something doesn't load or isn't 
found that you know is installed and should be found and load.

-- 
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] [RFC/announcement] Reviewers project

[hasufell]

On 10/11/2015 09:19 AM, Sven Vermeulen wrote:
> 
> This is good news. There are quite a few developers that manage a small
> subset of packages while doing tremendous work for Gentoo within that
> community. For instance, they focus on particular deliverables in
> repositories which eventually get packaged, or on integration of certain
> components which have a strong, broader community coverage.
> 
> These developers will certainly welcome any helping hand (even post-commit)
> in keeping packages of high quality.
> 
> I hope you will also focus on the documentation side. Certain processes that
> we follow within Gentoo (for commits, for instance the Git workflow) would
> benefit from a good document *set* (yes, set, as you'll definitely want such
> processes to have both a single-screen version as well as an elaborate
> version).
> 
> I've also found myself often looking for similar ebuilds in which a certain
> problem would already have been implemented. For instance, ebuilds with an
> optional python part using the python-r1 eclass. Do you think it is
> worthwhile to have a number of packages assigned as good examples?
> 

Those are great ideas, unfortunately we currently don't have a wiki guru
in the team ;)

Re: [gentoo-dev] rfc: multilib and fhs 3

[Jason Zaman]

On Sat, Oct 10, 2015 at 05:48:15PM -0500, William Hubbs wrote:
> All,
> 
> fhs 3.0 was approved in June this year [1] [2].
> 
> The piece of it that I want to bring up is the lib and libxx
> directories, both in / and /usr. The way I read the fhs, /lib and
> /usr/lib should hold the files for the default abi and /libxx and
> /usr/libxx should hold the files for the alternate abis. In earlier fhs,
> there was an exception for amd64 which stated that the default libraries
> should be in /lib64 and /usr/lib64. However, that exception is now gone.
> 
> I know there was discussion/work in the past on removing the lib->lib64
> symlinks on amd64, but I don't remember what happened to that
> discussion. So, I would like to bring it up again and get the info.
> 
> What would it take for us to remove the lib->lib64 links?
> 
> What would it take for us to do this migration on live systems?
> 
> William
> 
> [1] https://wiki.linuxfoundation.org/en/FHS
> [2] http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html

Not sure we have to move it.

"3.10. /lib : Alternate format essential shared libraries (optional)
3.10.1. Purpose
There may be one or more variants of the /lib directory on systems which
support more than one binary format requiring separate libraries. [13]"

Note 13 is:
"[13] This is commonly used for 64-bit or 32-bit support on systems which
support multiple binary formats, but require libraries of the same name.
In this case, /lib32 and /lib64 might be the library directories, and
/lib a symlink to one of them."

Unless im misunderstanding, we are fine as is with lib32, lib64 and
lib->lib64

-- Jason

Re: [gentoo-dev] Dynamic dependencies

[Rich Freeman]

On Thu, Sep 17, 2015 at 7:57 AM, Kristian Fiskerstrand  wrote:
>
> Another thing that strikes me is separation of stable vs ~arch behavior.
>
> This applies in particular with in-place eclass alterations. Users on
> ~arch should normally expect more activity (in particular number of
> builds and changes, that is after all its definition). Stable users on
> the other hand might want slower update cycle for non-security upgrades.
>
> Reading this thread I got hit with a question whether this boundary is
> properly protected if doing in-place eclass changes?

This isn't about whether an eclass used by stable packages are allowed
to be modified or not.

This is about what has to be done AFTER an eclass is modified, so that
users won't run into problems down the road.

Today developers are modifying eclass RDEPENDs and not bumping
anything.  This impacts stable users, but it can do so in ways that
cause their systems to break months down the road in ways that are
hard to troubleshoot.

With the proposal when an eclass is changed the user will get a
rebuild, but they won't get the mysterious breakage.

I'm not sure that we're doing stable users a favor by not "disturbing"
them with rebuilds but instead we're just silently breaking their
systems in subtle ways.  I think that if anybody would benefit from a
more conservative approach it would be the stable users.

I'm all for having a separate discussion around when it is and isn't
appropriate to modify eclasses that are used by stable packages in the
first place.

-- 
Rich

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Brendan Horan]

- On 11 Oct, 2015, at 4:17 PM, wraeth wra...@wraeth.id.au wrote:

> On 11/10/15 18:52, Ian Delaney wrote:
>> On Sat, 10 Oct 2015 16:27:15 +0200 Alexis Ballier
>>  wrote:
>> 
>>> On Sat, 10 Oct 2015 10:09:11 +0200 Michał Górny
>>>  wrote:
>>> 
 Hello, developers.
 
 I have the pleasure
>> 
>> :?
>> 
 to announce that we have formed a new Reviewers team [1] for
 Gentoo. The team is going to assemble developers willing to
 perform ebuild reviews and help contributors improve their
 ebuild skills.
 
 The main goal of the team is to handle GitHub pull requests. We
 are going to review incoming PRs, communicate with maintainers
 and merge them as appropriate. In particular, we're going to
 help willing contributors get high-quality, PGP-signed commits
 into Gentoo, therefore helping them prepare to become Gentoo
 developers.
>>> 
>>> This is cool
>>> 
 The side goal is to review current Gentoo commits for major QA
 violations and other issues, aiming at improving the quality
 of ebuilds in Gentoo and helping other developers using bash,
 ebuilds and git effectively.
>>> 
>>> This is completely unrelated: since we've had gentoo-commits ml,
>> 
>> which was promptly utlised
>> 
>>> every one has been able to do commit reviews easily, and most
>>> devs have done so. Self-proclamed reviewers project certainly
>>> does not have the monopoly of best practices nor perfect
>>> knowledge. I hope they do keep the monopoly of being harassing
>>> though :)
>>> 
>>> Also, you should probably focus on what's really important:
>>> reviews like "this is weird, care to explain?" or stylistic
>>> nitpicks are just a waste of every one time, meaning more
>>> important stuff does not get done.
>>> 
>> 
>> To my observation the reaction to this has been between displeasure
>> and dismay.  Yesterday the dev-ML was flooded with the first day's
>> publication of the members' reviews. Firstly the gentoo-commits ML
>> to my understanding is intended to be used for and by qa members.
>> This project has one whom we presume has the discretion to declare
>> the use of the qa hat at whim.
>> 
>> As someone once put it, it's not the product or message it's the
>> delivery of the package.  This project in its creation is made of
>> self appointed members who assume the status and qualification to
>> suddenly launch their evaluations upon unsuspecting folk the
>> community wide with neither  warning  nor their prior knowledge nor
>> consent. The editing to the page illustrates already significant
>> back pedalling from feedback already challenging its selected mode
>> of delivery.
>> 
>> The project goals and 'would be' mission statement are in fact
>> legitimate and have the backing of Council members.  The execution
>> has been done independently, unilaterally and with no input or
>> collaboration with Council to my knowledge.  The actions of this
>> project potentially impact on every developer / user of the gentoo
>> project, addressing the core skills of both. Yet it has been made,
>> announced and executed in this style.
>> 
>> I invested study time in several units in teaching and lecturing in
>> my university education under the education department. Sorry but
>> the modi operandi by these self proclaimed teachers and educators
>> thus far violate almost every fundamental principle in the art of
>> teaching that I learned from the course. There have also been users
>> who have expressed concern to me over this directly, some of which
>> have indicated they will also email this list to make their views
>> known.
> 
> I am one of the users who spoke to idella4 about this, but I wanted to
> repeat this publicly in order to highlight the point of view of
> contributing user as opposed to a developer.
> 
> Firstly I would like to say that I appreciate feedback on my work - it
> helps me to improve the quality of my work both for Gentoo and personally.
> 
> I also agree whole-heartedly to the concept of the Reviewers project, in
> that highlighting common improvements that could be made would benefit
> both contributors who participate and Gentoo as a whole.
> 
> Having said that, however, I do not appreciate the method in which these
> criticisms were delivered, and believe it extends beyond the idea of
> the Reviewers project.
> 
> I feel that it is inappropriate for criticisms of contributor's work to
> be broadcast on a mailing list that is read not only by the developer
> community, but by users as well, without their consent. This is not a
> case where I am particularly embarrassed or upset - if others can learn
> from my mistakes, then they are mistakes I am happy to make (preferably
> only once). But doing so publicly, with identifying information, is
> inappropriate.

I will second your thoughts on this. 
As a new proxy-maintainer I expect a lot of feedback, and I welcome 
the idea of the reviewers project to help 

Re: [gentoo-dev] rfc: multilib and fhs 3

[Alexis Ballier]

On Sat, 10 Oct 2015 17:48:15 -0500
William Hubbs  wrote:

> All,
> 
> fhs 3.0 was approved in June this year [1] [2].
> 
> The piece of it that I want to bring up is the lib and libxx
> directories, both in / and /usr. The way I read the fhs, /lib and
> /usr/lib should hold the files for the default abi and /libxx and
> /usr/libxx should hold the files for the alternate abis. In earlier
> fhs, there was an exception for amd64 which stated that the default
> libraries should be in /lib64 and /usr/lib64. However, that exception
> is now gone.
> 
> I know there was discussion/work in the past on removing the
> lib->lib64 symlinks on amd64, but I don't remember what happened to
> that discussion. So, I would like to bring it up again and get the
> info.
> 
> What would it take for us to remove the lib->lib64 links?
> 
> What would it take for us to do this migration on live systems?

I did this for amd64-fbsd, close to its beginning in gentoo; it's a
pain for users: it basically sums up to 'set SYMLINK_LIB=no, rm
lib, mv lib64 lib, ln -s lib lib64, emerge -e world, rm lib64'
( see
https://wiki.gentoo.org/wiki/Gentoo_FreeBSD#All_commands_is_not_working_after_emerge_sys-apps.2Fbaselayout
)

emerge -e world was there to kill every hardcoded lib64 in binaries

vapier has been working on this afaik
( https://bugs.gentoo.org/show_bug.cgi?id=506276 ), so maybe there is a
better solution, but since this changes econf args and get_libdir
ouput, I'm not sure 'emerge -e world' can be avoided...


Alexis.

Re: [gentoo-dev] Re: rfc: multilib and fhs 3

[William Hubbs]

On Sun, Oct 11, 2015 at 09:46:20AM +, Duncan wrote:
> William Hubbs posted on Sat, 10 Oct 2015 17:48:15 -0500 as excerpted:
> 
> > All,
> > 
> > fhs 3.0 was approved in June this year [1] [2].
> > 
> > The piece of it that I want to bring up is the lib and libxx
> > directories, both in / and /usr. The way I read the fhs, /lib and
> > /usr/lib should hold the files for the default abi and /libxx and
> > /usr/libxx should hold the files for the alternate abis. In earlier fhs,
> > there was an exception for amd64 which stated that the default libraries
> > should be in /lib64 and /usr/lib64. However, that exception is now gone.
> > 
> > I know there was discussion/work in the past on removing the lib->lib64
> > symlinks on amd64, but I don't remember what happened to that
> > discussion. So, I would like to bring it up again and get the info.
> > 
> > What would it take for us to remove the lib->lib64 links?
> > 
> > What would it take for us to do this migration on live systems?
> > 
> > William
> > 
> > [1] https://wiki.linuxfoundation.org/en/FHS [2]
> > http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html
> 
> I don't know what the current status is, but years ago, I used to run 
> portage with FEATURES=multilib-strict.  There weren't many violations in 
> my installed base at the time, and when there were I filed bugs.
> 
> This biggest problems didn't have to do with installing to the wrong 
> place, but rather, with configuration paths, etc, not being corrected, 
> resulting in runtime errors if lib and lib64 were not in fact the same 
> directory, via symlink or whatever.  IIRC, openrc itself, or at least 
> some openrc initscripts, possibly owned by other packages, was quite a 
> headache in that regard.
> 
> However, I killed multilib-strict some years ago when I went no-multilib, 
> and after experiencing problems when lib and lib64 weren't in fact the 
> same dir, I've not touched those symlinks in years, plus I run systemd 
> now so wouldn't know about openrc's status even if I was aware of the 
> general status, so I've no idea what the current status is.
> 
> But multilib-strict in fact checks that packages use lib64 for 64-bit elf 
> libs (tho I think it might actually get the specifics from the profile, 
> the amd64 or portage folks should be able to say for sure), failing the 
> install if lib is used instead, so if in fact FHS 3.0 reverses that, we'd 
> either have to reverse its check, or possibly configure a test to some 
> third directory, and then do a test run to catch anything that's 
> installing to either location, hard-coded.
> 
> Tho as I said, the actual installed installation isn't the entire 
> problem.  Multilib-strict doesn't catch it when a binary is installed to 
> the right place, but some configuration hard-coding isn't corrected and 
> still points elsewhere, so if the two locations aren't symlinked or 
> otherwise actually the same location, things break.  That's somewhat 
> harder to find, and in my experience, the worse headache to try to deal 
> with, since it's often only caught at runtime, and even then, may only be 
> caught in specific corner-cases when something doesn't load or isn't 
> found that you know is installed and should be found and load.

If I'm reading the new fhs correctly, /usr/lib64 and /lib64 should no
longer exist and we should put all 64 bit code in /usr/lib and /lib.
This means all no-multilib and multilib setups would have
/usr/lib and /lib directories, and multilib setups would add /usr/lib32
and /lib32. It is not a reversal; it is the equivalent of
"rm lib;mv lib64 lib" run both in / and /usr.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[James Le Cuirot]

On Sun, 11 Oct 2015 13:02:50 +0200
Manuel Rüger  wrote:

> It might be also worth to think about limiting the feedback to the
> actual patch that is included in a pull request or whatever is used as
> transport media.
> I have the feeling that some pull requests are accepted, after the
> package has been refactored or mistakes or deprecated styles former
> maintainers applied have been fixed. I'm not sure if new contributors
> like that kind of extra work to get their pull requests accepted or
> feel overloaded by the mass of comments some ancient ebuilds may
> produce.

Nit-picking over mistakes or old standards that the contributor didn't
even add has proven to be quite frustrating. I feel this largely comes
about from the fact that new ebuild revisions appear in a diff as
entirely new content and there's no quick way, at least on GitHub, to
compare it against the previous revision that still exists. It also
seems a tad wasteful as I don't think git will optimize around the fact
that this new revision may have as little as one changed character.
This is where Subversion has the upper-hand as it explicitly supports
copying as well as moving. I tried to think of some clever way around
this but came up empty. :(

I think we should therefore encourage reviewers to not just look at the
raw diff but also compare against the previous revision to see what has
really changed. While mistakes and old standards should be corrected,
if they have already been present, and possibly even stable, for months
or years then they're probably not doing that much harm. We should
allow improvements to be done iteratively.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpih6fMbyp9B.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Michał Górny]

Dnia 2015-10-11, o godz. 15:52:40
Ian Delaney napisał(a):

> To my observation the reaction to this has been between displeasure and
> dismay.  Yesterday the dev-ML was flooded with the first day's
> publication of the members' reviews. Firstly the gentoo-commits ML to my
> understanding is intended to be used for and by qa members. This
> project has one whom we presume has the discretion to declare the use
> of the qa hat at whim.
> 
> As someone once put it, it's not the product or message it's the
> delivery of the package.  This project in its creation is made of self
> appointed members who assume the status and qualification to suddenly
> launch their evaluations upon unsuspecting folk the community wide with
> neither  warning  nor their prior knowledge nor consent. The editing
> to the page illustrates already significant back pedalling from feedback
> already challenging its selected mode of delivery.
> 
> The project goals and 'would be' mission statement are in fact
> legitimate and have the backing of Council members.  The execution has
> been done independently, unilaterally and with no input or collaboration
> with Council to my knowledge.  The actions of this project potentially
> impact on every developer / user of the gentoo project, addressing the
> core skills of both. Yet it has been made, announced and executed in
> this style. 

Per GLEP 39, there is no requirement or even a recommendation for
a project to be approved by Council. The Reviewers project has no
special powers. Anyone can post their opinion which includes reviewing
ebuilds or communicating common problems. Some of us has been doing
this for some time already.

The only change about having this project, really, is that there's
a common contact point for people looking for help with ebuilds. This
also improves the quality of reviews through sharing of ebuild
knowledge between different reviewers.

-- 
Best regards,
Michał Górny



pgpPavXDiY6T0.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Michał Górny]

Dnia 2015-10-11, o godz. 13:02:50
Manuel Rüger  napisał(a):

> On 11.10.2015 10:29, Brendan Horan wrote:
> > - On 11 Oct, 2015, at 4:17 PM, wraeth wra...@wraeth.id.au wrote:
> > 
> >> On 11/10/15 18:52, Ian Delaney wrote:
> >>> On Sat, 10 Oct 2015 16:27:15 +0200 Alexis Ballier
> >>>  wrote:
> >>>
>  On Sat, 10 Oct 2015 10:09:11 +0200 Michał Górny
>   wrote:
> 
> > Hello, developers.
> >
> > I have the pleasure
> >>>
> >>> :?
> >>>
> > to announce that we have formed a new Reviewers team [1] for
> > Gentoo. The team is going to assemble developers willing to
> > perform ebuild reviews and help contributors improve their
> > ebuild skills.
> >
> > The main goal of the team is to handle GitHub pull requests. We
> > are going to review incoming PRs, communicate with maintainers
> > and merge them as appropriate. In particular, we're going to
> > help willing contributors get high-quality, PGP-signed commits
> > into Gentoo, therefore helping them prepare to become Gentoo
> > developers.
> 
>  This is cool
> 
> > The side goal is to review current Gentoo commits for major QA
> > violations and other issues, aiming at improving the quality
> > of ebuilds in Gentoo and helping other developers using bash,
> > ebuilds and git effectively.
> 
>  This is completely unrelated: since we've had gentoo-commits ml,
> >>>
> >>> which was promptly utlised
> >>>
>  every one has been able to do commit reviews easily, and most
>  devs have done so. Self-proclamed reviewers project certainly
>  does not have the monopoly of best practices nor perfect
>  knowledge. I hope they do keep the monopoly of being harassing
>  though :)
> 
>  Also, you should probably focus on what's really important:
>  reviews like "this is weird, care to explain?" or stylistic
>  nitpicks are just a waste of every one time, meaning more
>  important stuff does not get done.
> 
> >>>
> >>> To my observation the reaction to this has been between displeasure
> >>> and dismay.  Yesterday the dev-ML was flooded with the first day's
> >>> publication of the members' reviews. Firstly the gentoo-commits ML
> >>> to my understanding is intended to be used for and by qa members.
> >>> This project has one whom we presume has the discretion to declare
> >>> the use of the qa hat at whim.
> >>>
> >>> As someone once put it, it's not the product or message it's the
> >>> delivery of the package.  This project in its creation is made of
> >>> self appointed members who assume the status and qualification to
> >>> suddenly launch their evaluations upon unsuspecting folk the
> >>> community wide with neither  warning  nor their prior knowledge nor
> >>> consent. The editing to the page illustrates already significant
> >>> back pedalling from feedback already challenging its selected mode
> >>> of delivery.
> >>>
> >>> The project goals and 'would be' mission statement are in fact
> >>> legitimate and have the backing of Council members.  The execution
> >>> has been done independently, unilaterally and with no input or
> >>> collaboration with Council to my knowledge.  The actions of this
> >>> project potentially impact on every developer / user of the gentoo
> >>> project, addressing the core skills of both. Yet it has been made,
> >>> announced and executed in this style.
> >>>
> >>> I invested study time in several units in teaching and lecturing in
> >>> my university education under the education department. Sorry but
> >>> the modi operandi by these self proclaimed teachers and educators
> >>> thus far violate almost every fundamental principle in the art of
> >>> teaching that I learned from the course. There have also been users
> >>> who have expressed concern to me over this directly, some of which
> >>> have indicated they will also email this list to make their views
> >>> known.
> >>
> >> I am one of the users who spoke to idella4 about this, but I wanted to
> >> repeat this publicly in order to highlight the point of view of
> >> contributing user as opposed to a developer.
> >>
> >> Firstly I would like to say that I appreciate feedback on my work - it
> >> helps me to improve the quality of my work both for Gentoo and personally.
> >>
> >> I also agree whole-heartedly to the concept of the Reviewers project, in
> >> that highlighting common improvements that could be made would benefit
> >> both contributors who participate and Gentoo as a whole.
> >>
> >> Having said that, however, I do not appreciate the method in which these
> >> criticisms were delivered, and believe it extends beyond the idea of
> >> the Reviewers project.
> >>
> >> I feel that it is inappropriate for criticisms of contributor's work to
> >> be broadcast on a mailing list that is read not only by the developer
> >> community, but by users as well, without their 

Re: [gentoo-dev] Re: Dynamic dependencies

[Rich Freeman]

On Sun, Oct 11, 2015 at 7:09 AM, Rich Freeman  wrote:
> So, here is a consolidated list of the latest proposals:
>

It has been suggested that there might be rare cases where the
exceptions in the eclass proposals might apply to ebuilds, so doing
some refactoring I think the latest proposals are:

RDEPEND changes directly in ebuilds (non-virtual and virtual)
Proposal 5: Anytime an RDEPEND in an ebuild is changed, the
ebuild must be revisioned.  This includes adding/removing inherited
eclasses which set RDEPENDs.


RDEPEND changes in eclasses
Proposal 3: Anytime an RDEPEND in an eclass is changed, the eclass
must be revisioned.
Proposal 4: Anytime an RDEPEND in an eclass is changed, all ebuilds
that inherit the eclass in the gentoo repository must be revisioned.

General exception to the above:
Proposal 6: Maintainers may avoid revbumps at their discretion if:
1. all ebuilds in the gentoo repository will continue to work
correctly with the old RDEPEND,
2. and the new RDEPEND is a subset of the old RDEPEND

(Ironically splitting that out just reverts us back to the original
proposals, but it is also simpler.)

-- 
Rich

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/portage/

[Michał Górny]

Dnia 2015-10-10, o godz. 18:50:51
"Brian Dolbec"  napisał(a):

> commit: 6d6b97e870f98e26a6e5de0712da048495057286
> Author: Brian Dolbec  gentoo  org>
> AuthorDate: Sat Oct 10 17:47:28 2015 +
> Commit: Brian Dolbec  gentoo  org>
> CommitDate: Sat Oct 10 18:49:55 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6d6b97e8

(taking this as an example of common mistake, please don't take it
personally)

> sys-apps/portage: Add py3.5 compatibility to 2.2.23 and .
>
> Clean out older versions.
> Keep 2.2.8-r2 for python-2.6/3.2 upgrade compatibility.

The commit message does not follow the standard guidelines for git
commit messages. The summary line should describe the change shortly,
and the body should expand on it. In your case, the summary line
describes part of the change and the body part another change.

As a result, a user looking at --oneline logs would see that you only
added py3.5 compatibility while you also removed ebuilds.

Furthermore, *please* don't mix old version removals with other
changes. This makes it unnecessarily hard to revert breaking changes.
Let's suppose you accidentally removed a version that had reverse
dependencies. If you did it in a separate commit, we could quickly
revert that commit and save users from seeing the breakage, and we
could do the removal properly afterwards. When changes are mixed like
this, you have to do partial reverts and partial re-commits, and things
get unnecessarily hard.

> Package-Manager: portage-2.2.23
> 
>  sys-apps/portage/Manifest  |   4 -
>  sys-apps/portage/portage-2.2.14.ebuild | 352 ---
>  sys-apps/portage/portage-2.2.18.ebuild | 352 ---
>  sys-apps/portage/portage-2.2.20.ebuild | 365 
> -
>  sys-apps/portage/portage-2.2.22.ebuild | 363 
>  sys-apps/portage/portage-2.2.23.ebuild |   2 +-
>  sys-apps/portage/portage-.ebuild   |   2 +-
>  7 files changed, 2 insertions(+), 1438 deletions(-)

-- 
Best regards,
Michał Górny



pgpujx6AAiIPl.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: multilib and fhs 3

[Michał Górny]

Dnia 2015-10-10, o godz. 17:48:15
William Hubbs  napisał(a):

> All,
> 
> fhs 3.0 was approved in June this year [1] [2].
> 
> The piece of it that I want to bring up is the lib and libxx
> directories, both in / and /usr. The way I read the fhs, /lib and
> /usr/lib should hold the files for the default abi and /libxx and
> /usr/libxx should hold the files for the alternate abis. In earlier fhs,
> there was an exception for amd64 which stated that the default libraries
> should be in /lib64 and /usr/lib64. However, that exception is now gone.

Which only proves we ended up with yet another broken, pointless spec
that's missing the point and can't be implemented sanely. I don't see
a point discussing it further.

> I know there was discussion/work in the past on removing the lib->lib64
> symlinks on amd64, but I don't remember what happened to that
> discussion. So, I would like to bring it up again and get the info.
> 
> What would it take for us to remove the lib->lib64 links?
> 
> What would it take for us to do this migration on live systems?

vapier was working on it but it would probably involve lot more
politics than we can handle right now. He's got some script to fix live
systems but it is a quite dangerous operation by design, so I'm not
convinced we really want to play with live systems like that.

> [1] https://wiki.linuxfoundation.org/en/FHS
> [2] http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html

-- 
Best regards,
Michał Górny



pgpZ0mapz4i9n.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Matt Turner]

On Sun, Oct 11, 2015 at 1:17 AM, wraeth  wrote:
> I am one of the users who spoke to idella4 about this, but I wanted to
> repeat this publicly in order to highlight the point of view of
> contributing user as opposed to a developer.
>
> Firstly I would like to say that I appreciate feedback on my work - it
> helps me to improve the quality of my work both for Gentoo and personally.
>
> I also agree whole-heartedly to the concept of the Reviewers project, in
> that highlighting common improvements that could be made would benefit
> both contributors who participate and Gentoo as a whole.
>
> Having said that, however, I do not appreciate the method in which these
> criticisms were delivered, and believe it extends beyond the idea of
> the Reviewers project.
>
> I feel that it is inappropriate for criticisms of contributor's work to
> be broadcast on a mailing list that is read not only by the developer
> community, but by users as well, without their consent. This is not a
> case where I am particularly embarrassed or upset - if others can learn
> from my mistakes, then they are mistakes I am happy to make (preferably
> only once). But doing so publicly, with identifying information, is
> inappropriate.

Good grief. Seriously?

Mailing list review is the *norm* in the free software world.

I haven't seen anything noted that should have caused embarrassment.

This whole thing, as far as I can see, is about improving the quality
of Gentoo. I have learned from the reviewers reviewing my commits and
the commits of others. It's extremely valuable to do this in public
and the idea that noting an error on a public mailing list is somehow
bad is simply misguided.

Re: [gentoo-portage-dev] [PATCH] repoman: Finally deprecate base.eclass

[Michał Górny]

Dnia 2015-10-11, o godz. 18:16:44
Alexander Berntsen  napisał(a):

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> I don't even remember the last time this was discussed. Could you link
> to some discussion or a decision on this?

Nope, don't have any. Though AFAICS there's all-over-the-place
consensus that it's deprecated, and most of the developers complain
when they see it.

> Also, this patch won't actually apply to HEAD since you are basing it
> on one of your patches that aren't in yet. Try to avoid that in the
> future.

If I based it on HEAD, it wouldn't apply with the other patch on ;-P.

-- 
Best regards,
Michał Górny



pgp8WF3lA6zbY.pgp
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] repoman: Finally deprecate base.eclass

[Zac Medico]

On 10/11/2015 09:51 AM, Alexander Berntsen wrote:
> On 11/10/15 18:45, Michał Górny wrote:
>> Nope, don't have any. Though AFAICS there's all-over-the-place 
>> consensus that it's deprecated, and most of the developers complain
>>  when they see it.
> If you can show me the consensus, I'll ACK it. Alternatively anyone
> else on the team that have observed this consensus may ACK it.

I've found a tracker bug here:

https://bugs.gentoo.org/show_bug.cgi?id=497022
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH] repoman: deprecated_classes -> ...eclasses, to ease grep

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Wonky commit message aside, this LGTM.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWGosXAAoJENQqWdRUGk8BgCwP/i9NdrgQQfTkcvRhamansomm
1xov9aK0+7qhIgLRSCgbuTMCTfZHo3uTbcw0cDbeSPN9PeeuFXvs/iYNo1z0YZzg
Za3kXlfDlznUNbmqK/Qze2OFINgOLsgbx3vEAHGEYy/QBjfHWrsI+lNthl5U4v81
BSTWxy56plZMck7bAuAuf+CJtM9JLBbNMvLL4gGTMJCS+Qh6ovo/DrnlhnVh7Jkd
EbCSdCx82BSV+ITNBYqYYmcDJYGROyAvupbBW8dBBuDIQkJeB7ZmZDQ6XFtfKPbs
YU+AvTEBa2pkBoENwK6IiK3ZXAcJ1dUkaFA73WLTYsTCED4WJgRW9t31tzOQtITz
7LoxdCek7Vo/x6KaBXvrTvdU78yEDc7R+WVQTPH02kLlVxjZTk7J4mQmTyNcXVtE
L4NHxBDijTvwCSDJBtMlYdOIJfeCxv8ZX9vEdPEXu6aZGpM2TEW9AtL4rVSoizlm
SK8nrPTjjosE1zeH7OD6EvCVWtWxRvr9fsdY/nW4tu5DbOeJg5cQrgJA6FUFB1Sh
ZLmGVVWrkm9mVKjMrZU8UcgPRt3GpZgxEiP7FRmi3Ofhq2lki4V1Ol9EYwTiqvp7
wWpbG0CVruvOHoen7Hr2uw5JZyii/GXcSQqIcOu9CcvvTJx1rpttYEfpQA4mstIx
344hQl5l7hL4x+T6Ap9o
=NZZt
-END PGP SIGNATURE-

Re: [gentoo-portage-dev] [PATCH] repoman: Finally deprecate base.eclass

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I don't even remember the last time this was discussed. Could you link
to some discussion or a decision on this?

Also, this patch won't actually apply to HEAD since you are basing it
on one of your patches that aren't in yet. Try to avoid that in the
future.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWGotpAAoJENQqWdRUGk8BczYQALcMg+Ugs1WHW7q6K3JpDc0R
YRqt3zB12FNtYeD5PsUV0jAVuwObagbdryM+61ZJYDGl8MoIy0mEnhuM//QbhLuu
7ehRGT7R7iJmryScX+sSYamlWOOFysh8srTMxyGX+tk3lJFX8iL15ERHq2jmBxCz
BNGwGHbKUSb4a60kJaC4GdeaKPNGU79U4N3QIiynMV+QqQsLHZ6SF9eIBEHiCiAk
JLms46/q3X/IZT5Dx+xXVFO88SP2YMWeZ+/Yv8UmYNyPtO75lv7TVelmJwKTmcPT
zPZI7aKSlSNpwmwk5l6bf8ZANeoEqOtMLCHT1gpfkcgKWm45dZuNvXVsqD91lI9x
W06haJ4pC8URE17Qq/o3/kasnL4VI3Y6k+E+XmZLzNYKM80smluekZynrhKbWWba
JDdbOSiT55LORM1QUPImqoMJrbO+n4GLZ/KsHVrcD2N+z4BLquqqyBx3/i0nxvAj
fdmpAwzWlsGBPSyKL3u9JJZiMXy5T77M8yu3Wm1o4j+A66aXI6BKxzZEiC+Iu2B6
lkZQ59OlW4XGd7uzDbZ74REWFM6AGMtIoxWuEdS1hPdYEPvwNFcLf3FEZTmVkAys
MJxp47kxaKk+d5YtriIGmyC6UmGdJQEG/ntYeAg/qImMnhdvmNTEv9FOe+85NIAA
TCTkmrtvw8YncbqaDOQY
=oiR6
-END PGP SIGNATURE-

Re: [gentoo-portage-dev] [PATCH] repoman: Finally deprecate base.eclass

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/10/15 18:45, Michał Górny wrote:
> Nope, don't have any. Though AFAICS there's all-over-the-place 
> consensus that it's deprecated, and most of the developers complain
>  when they see it.
If you can show me the consensus, I'll ACK it. Alternatively anyone
else on the team that have observed this consensus may ACK it.

I'm sorry, but I've been so busy that I'm a bit out of the loop with
Gentoo. I'm not doing this to be annoying, but it is effectively
(probably) all my fault.

> If I based it on HEAD, it wouldn't apply with the other patch on 
> ;-P.
Yeah, but if we for some reason we decided to not apply that one, but
do apply this one, it would be a bit of a hassle. And they are not
related enough to be in a patch series, so... But this is nitpicking
and a non-issue since I ACKed the first patch. :]

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWGpOXAAoJENQqWdRUGk8BhK8P/ihHagl/CgC65yPXCW0LsHGE
duSIw7Oi8h2nmeHjnrSSWpn9NnAfq9+uamPncMPSGQRKi15/0SvmhMsNFr/yinxL
Bhsqp2a4V3W+vhQ5uZAeaBwK1UWng9hDIXwEBOfQvBa+4ULFHFKuMQA1dfqUp8Jt
mYstCQHUjP23xKmgfVXmN1Ak1K6pOp0nQ260URiSHkpx3U26wJhN/0sx793eiJcS
I1NvMm6aoHqiqa0afEDnemE+Z1tgKLJQmlJJdrtQuBIOdVNxdS1O74/N5v0xdn+E
Eizb3NiRk9Q3kZEnvV+fvFF0P7+QJxVuMN0OV/Oju3e3sto0y8RLzlJ1Kfi6MlKw
KUH6KBNG/NWUD3nvINMAxVHCE5cSCHLlIaBqoSH7LEBhu2Hu7pnzGRh9qdyno+UG
i3viyhRRYG1AVtziq5kT27Y0oSpoRdVZCLsoPTJ13cU3RORexQy1KKSVReok9oWc
1IXzYIRrzTT6McpcRiLW4oySqIkP4XFnmVTFvOsB2RiK2XyRy5Ef8D/lVnf/LM0e
1hqm5AseK2aaZyWp4CnTJ0QSI5IvsGdHSmnz4uNxfE474QpDFqo9qrMoQY3qy/v9
yJjHJGskpl75Kb77ZcHEzmcgP/BFZkXAxynRXs6aI69MaHKXLvqlcS0OdAvCqTxd
ZmLsKsjSlayjCoekr3qP
=W+yH
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Dynamic dependencies

[Rich Freeman]

Ok, in the Council meeting today the following was made policy:
"Maintainers must not assume that dynamic dependencies will be applied
by the package manager. When changing runtime dependencies the
maintainer should revision the ebuild if the changes are likely to
cause problems for end users."

The wording intentionally left some room for maintainer discretion,
but this should be used with care.  Eclass changes were really the
main area of concern, and it was suggested that it would be a good
practice to talk about whether bumping makes sense when discussing the
eclass change on -dev as already required by policy.

The proposals I sent out earlier will be adopted as guidelines.  They
can go in the devmanual once they're worked out here, and can be
maintained as with anything else in the devmanual.  Adding additional
edge cases/etc them doesn't require explicit council approval
(obviously large controversies can always be appealed).

Guidelines:

RDEPEND changes directly in ebuilds
Anytime an RDEPEND in an ebuild is changed, the ebuild should be
revisioned.  This includes adding/removing inherited eclasses which
set RDEPENDs.

RDEPEND changes in eclasses
Anytime an RDEPEND in an eclass is changed, all ebuilds that inherit
the eclass in the gentoo repository should be revisioned.
It is generally going to be easier to do that all at once, but it may
make sense in some cases to revision the eclass itself to allow
gradual adoption of the change.  Ebuilds would be revisioned as they
adopt the new eclass.

General exception to the above:
There are cases where a change in runtime dependencies will not cause problems.

Maintainers may safely avoid revbumps if:
1. all ebuilds in the gentoo repository will continue to work
correctly with the old RDEPEND,
2. and the new RDEPEND is a subset of the old RDEPEND

A common example of a situation where a bump is not needed is when
increasing the minimum version of a dependency in an eclass, when the
old version was working for all ebuilds that used the eclass at the
change (i.e. the change is being made for the sake of ebuilds that are
about to be introduced to the tree).

Please reply if you see any need to improve these.  I would encourage
developers to take these guidelines seriously.  The purpose of
allowing discretion is so that we're not locked into rigid rules that
don't capture every nuance.  If you change an RDEPEND and don't bump
it can cause subtle problems that can show up weeks or months later,
when devs make changes that repoman considers valid but which are
inconsistent with what is recorded on user's vdbs.

-- 
Rich

Re: [gentoo-portage-dev] [PATCH] repoman: Finally deprecate base.eclass

[Zac Medico]

On 10/11/2015 12:23 PM, Zac Medico wrote:
> On 10/11/2015 09:51 AM, Alexander Berntsen wrote:
>> On 11/10/15 18:45, Michał Górny wrote:
>>> Nope, don't have any. Though AFAICS there's all-over-the-place 
>>> consensus that it's deprecated, and most of the developers complain
>>>  when they see it.
>> If you can show me the consensus, I'll ACK it. Alternatively anyone
>> else on the team that have observed this consensus may ACK it.
> 
> I've found a tracker bug here:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=497022
> 

The patch is consistent with the QA team's policy discussed in bug
497022, it looks good to me.
-- 
Thanks,
Zac

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-10-11 23:59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2015-10-11 23:59 UTC.

Removals:
sys-apps/cv  20151005-09:53 zx2c4  4688772
x11-libs/libXevie20151010-01:56 mattst88   5c9c2f4

Additions:
app-dicts/hunspell-kk20151008-00:56 idella45bd8c21
app-vim/vimclojure   20151008-07:54 monsieurp  af5bff7
dev-java/vldocking   20151010-14:44 monsieurp  175450a
dev-lang/crystal 20150918-06:24 idella4cd98a9d
dev-libs/libdbh  20151007-16:33 angelos0f76084
dev-libs/libtubo 20151007-16:33 angelos4193577
dev-libs/pcl 20150918-06:24 idella4cd98a9d
dev-lua/lua-openssl  20151003-14:36 jakub  6dc1794
dev-python/uhashring 20151007-16:23 ultrabug   c3a604e
dev-python/vulture   20151006-21:43 vapier 48c3ef6
dev-ros/calibration_estimation   20151011-13:59 aballier   6cbb969
dev-ros/calibration_launch   20151011-14:03 aballier   a8d6e91
dev-ros/calibration_msgs 20151011-12:15 aballier   67b05ab
dev-ros/calibration_setup_helper 20151011-14:05 aballier   d6c9d0f
dev-ros/image_cb_detector20151011-12:21 aballier   e96a4a8
dev-ros/imu_processors   20151011-12:07 aballier   55817d1
dev-ros/imu_transformer  20151011-12:11 aballier   ab8826a
dev-ros/interval_intersection20151011-14:00 aballier   95a6f20
dev-ros/joint_states_settler 20151011-14:03 aballier   8001be0
dev-ros/laser_cb_detector20151011-14:01 aballier   e064dbf
dev-ros/monocam_settler  20151011-12:19 aballier   13a0ae8
dev-ros/octomap_ros  20151011-15:34 aballier   620a2a9
dev-ros/rosapi   20151011-15:08 aballier   5305430
dev-ros/rosauth  20151011-15:12 aballier   4bb80a0
dev-ros/rosbridge_library20151011-15:07 aballier   58ed876
dev-ros/rosbridge_server 20151011-15:13 aballier   23d0fed
dev-ros/rosserial_arduino20151011-16:13 aballier   f055f0b
dev-ros/rosserial_client 20151011-16:10 aballier   6cb7e11
dev-ros/rosserial_embeddedlinux  20151011-16:11 aballier   bc8b78d
dev-ros/rosserial_msgs   20151011-16:07 aballier   baa36e1
dev-ros/rosserial_python 20151011-16:08 aballier   3a38425
dev-ros/rosserial_server 20151011-16:11 aballier   d278776
dev-ros/rosserial_windows20151011-16:13 aballier   1d3f51e
dev-ros/rosserial_xbee   20151011-16:09 aballier   dd7801c
dev-ros/settlerlib   20151011-12:16 aballier   d7e6c2b
dev-ros/turtle_tf20151011-11:59 aballier   bfb845d
dev-ros/turtle_tf2   20151011-12:02 aballier   ec0cc18
dev-ruby/metasm  20151008-20:45 zerochaos  f05eda2
net-p2p/bitcoinxtd   20151009-00:48 blueness   075c391
ros-meta/calibration 20151011-14:08 aballier   4499f9b
ros-meta/geometry_tutorials  20151011-12:03 aballier   78e4b91
ros-meta/imu_pipeline20151011-12:13 aballier   949e3c9
ros-meta/rosbridge_suite 20151011-15:14 aballier   f28fca3
ros-meta/rosserial   20151011-16:14 aballier   a29a8fa
sys-apps/progress20151005-09:53 zx2c4  4688772
www-apps/icingaweb2  20151005-04:27 prometheanfire a9dea26
x11-libs/librfm  20151007-16:34 angelos6c309e7

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
x11-libs/libXevie,removed,mattst88,20151010-01:56,5c9c2f4
sys-apps/cv,removed,zx2c4,20151005-09:53,4688772
Added Packages:
ros-meta/rosserial,added,aballier,20151011-16:14,a29a8fa
dev-ros/rosserial_windows,added,aballier,20151011-16:13,1d3f51e
dev-ros/rosserial_arduino,added,aballier,20151011-16:13,f055f0b
dev-ros/rosserial_server,added,aballier,20151011-16:11,d278776
dev-ros/rosserial_embeddedlinux,added,aballier,20151011-16:11,bc8b78d
dev-ros/rosserial_client,added,aballier,20151011-16:10,6cb7e11
dev-ros/rosserial_xbee,added,aballier,20151011-16:09,dd7801c
dev-ros/rosserial_python,added,aballier,20151011-16:08,3a38425
dev-ros/rosserial_msgs,added,aballier,20151011-16:07,baa36e1
dev-ros/octomap_ros,added,aballier,20151011-15:34,620a2a9
ros-meta/rosbridge_suite,added,aballier,20151011-15:14,f28fca3
dev-ros/rosbridge_server,added,aballier,20151011-15:13,23d0fed
dev-ros/rosauth,added,aballier,20151011-15:12,4bb80a0
dev-ros/rosapi,added,aballier,20151011-15:08,5305430
dev-ros/rosbridge_library,added,aballier,20151011-15:07,58ed876
ros-meta/calibration,added,aballier,20151011-14:08,4499f9b
dev-ros/calibration_setup_helper,added,aballier,20151011-14:05,d6c9d0f
dev-ros/calibration_launch,added

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Ian Delaney]

On Sun, 11 Oct 2015 09:56:28 -0700
Matt Turner  wrote:

> On Sun, Oct 11, 2015 at 1:17 AM, wraeth  wrote:

> >
> > I feel that it is inappropriate for criticisms of contributor's
> > work to be broadcast on a mailing list that is read not only by the
> > developer community, but by users as well, without their consent.
> > This is not a case where I am particularly embarrassed or upset -
> > if others can learn from my mistakes, then they are mistakes I am
> > happy to make (preferably only once). But doing so publicly, with
> > identifying information, is inappropriate.
> 
> Good grief. Seriously?
> 
> Mailing list review is the *norm* in the free software world.
> 

Oh, the norm
> I haven't seen anything noted that should have caused embarrassment.
> 

Nor I.
> This whole thing, as far as I can see, is about improving the quality
> of Gentoo. I have learned from the reviewers reviewing my commits and
> the commits of others.

The you haven't been embarrassed or demeaned or nitpicked. So far. Good.
> It's extremely valuable to do this in public
> and the idea that noting an error on a public mailing list is somehow
> bad is simply misguided.
> 

You throw your opinion on that of a user offering his personal
reaction. What do you want here? Users to comply to your perspective
and fit in? Users to tough out the exposure to full public view even if
they don't like it?

Once and for all this is a review put onto recipients whether they
wanted it or not without their request or consent. A key aspect of
learning is that the informative experience be made a positive one.
This user is not alone. These self appointed educators have background
in technical prowess and that's all. Quite simply, dishing out lessons
that make users cringe and recoil is counter productive. This exercise
is about educating, so these educators had better get their heads
around some the fundamental requirement to command respect from their
target audience. To date they have managed to deliver their product as
they see fit. Now they get the feedback that follows from delivering
their lessons.

These educators have already started to learn some lessons of their
own. An intrinsic aspect of the flow of teaching / educating is the
impact of teacher behaviour upon their learners and a teacher's
responsibility as an educator to deal with it productively. What's
happening here? Teacher says take it because I gave it to you,now be
quiet ?
 
This is not a captive audience. It's an immediately convenient one.
Educators snubbed by their students are not educators. At least not
effective ones.  These students are so by nature of their own
voluntary participation. They have the option of rejecting these
lessons at their whim.


-- 
kind regards

Ian Delaney

[gentoo-dev] Re: [RFC/announcement] Reviewers project

[Duncan]

Matt Turner posted on Sun, 11 Oct 2015 09:56:28 -0700 as excerpted:

> Mailing list review is the *norm* in the free software world.

Just noting that I've been watching this first-hand on both the gentoo-
portage-dev list and the btrfs list.  I don't claim to be a coder, but I 
often make it a point to read comments and the vX patch revision notes, 
because it's both informative (even to a more admin than dev user) and 
exciting to watch as a patch develops and matures thru multiple rounds of 
review.

And I'd say it's roughly equally often that the original patch submitter 
is able to point out to the reviewer that they overlooked something that 
answers the question, vs "oops, I overlooked that possibility, thanks!"  
Either way, both parties (as well as other interested parties reading the 
exchange) end up with a keener appreciation of how things actually work, 
resulting in both a better patch in the near term, and better coders who 
much more thoroughly understand the domain in which they're working, in 
the longer term.

It's absolutely /not/ about being right or being wrong, but about the 
process of both the patch submitter and the reviewer together growing in 
their understanding of the code they both work with, and in the better 
end result that comes of that process.

And it really /is/ a neat thing to watch unfold, as I have the privilege 
of doing both on the portage-dev list and on the btrfs list, because 
they /are/ public and open.  =:^)

-- 
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] [RFC/announcement] Reviewers project

[Ian Delaney]

On Sun, 11 Oct 2015 19:37:23 -0700
Matt Turner  wrote:

> >>
> >> Mailing list review is the *norm* in the free software world.
> >>
> >
> > Oh, the norm
> 
> You're being quite rude with attempted mockery -- actually, the rest
> of your reply is pretty abrupt as well.
> 
> If you want to fight, find someone and some place and  else. Otherwise
> if you're interested in having a reasonable discussion, please read
> on.
> 

Oh so this is a fight? Your words not mine. I thought this was a
discussion. Please stop putting words into my mouth.
> >
> > These educators have already started to learn some lessons of their
> > own. An intrinsic aspect of the flow of teaching / educating is the
> > impact of teacher behaviour upon their learners and a teacher's
> > responsibility as an educator to deal with it productively. What's
> > happening here? Teacher says take it because I gave it to you,now be
> > quiet ?
> 
> No. It's a discussion. Review can be responded to -- reviewers aren't
> intrinsically right.
> 

Oh thanks for reminding me.
> > This is not a captive audience. It's an immediately convenient one.
> > Educators snubbed by their students are not educators. At least not
> > effective ones.  These students are so by nature of their own
> > voluntary participation. They have the option of rejecting these
> > lessons at their whim.
> 
> Patch review is widely accepted as a quality-improving tool. Some have
> had difficulty adjusting to it when coming from, for instance, the
> closed-source world, primarily because they equate making a mistake to
> personal failure (and as such, having it pointed out in public makes
> it worse).
> 
> http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/
> offers a good explanation.
> 
> "The most productive contributors see each mistake they make as a
> growth opportunity, instead of a personal failure."
> 

The main target learners here are keen users.  You can take told a
mistake with the background and status of a dev. They don't. They are
often intimidated and fearful if gentoo devs. We wonder why.

-- 
kind regards

Ian Delaney

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[wraeth]

I'm not trying to escalate the argument but you seem to have
misinterpreted my initial message.

On 12/10/15 03:56, Matt Turner wrote:
> On Sun, Oct 11, 2015 at 1:17 AM, wraeth  wrote:
>> I am one of the users who spoke to idella4 about this, but I wanted
>> to repeat this publicly in order to highlight the point of view of 
>> contributing user as opposed to a developer.
>> 
>> Firstly I would like to say that I appreciate feedback on my work -
>> it helps me to improve the quality of my work both for Gentoo and
personally.
>> 
>> I also agree whole-heartedly to the concept of the Reviewers
>> project, in that highlighting common improvements that could be
>> made would benefit both contributors who participate and Gentoo as
>> a whole.
>> 
>> Having said that, however, I do not appreciate the method in which
>> these criticisms were delivered, and believe it extends beyond the
>> idea of the Reviewers project.
>> 
>> I feel that it is inappropriate for criticisms of contributor's
>> work to be broadcast on a mailing list that is read not only by the
>> developer community, but by users as well, without their consent.
>> This is not a case where I am particularly embarrassed or upset -
>> if others can learn from my mistakes, then they are mistakes I am
>> happy to make (preferably only once). But doing so publicly, with
>> identifying information, is inappropriate.
> 
> Good grief. Seriously?

Yes, I am being serious. Thanks for asking.

> Mailing list review is the *norm* in the free software world.

I am aware of this and that it has been the way for quite
some time. However, while it may be the norm in the wider FOSS
community, it has not been the norm on the gentoo-dev list - certainly
people will post things specifically for review, or may highlight
critical issues; but it has not until recently been a channel for review
of any and all commits that the Reviewers inspect.

It is not the fact that there is a review or education process, but that
this process was executed with the level of tact and grace becoming of a
flock of ducks flying into the side of a building.

This education process was implemented in a way that indiscriminately
pointed the finger at contributors, developer and user alike, sometimes
for things that mattered, and other times for things that simply didn't.
What's more, it was implemented without warning and included publishing
who the author of those mistakes was without the contributor knowing
that it would be used so (you know, since the whole commit header was in
this educational message, too).

> I haven't seen anything noted that should have caused embarrassment.

Perhaps you missed:
>> This is not a case where I am particularly embarrassed or upset -
>> if others can learn from my mistakes, then they are mistakes I am
>> happy to make (preferably only once).

> This whole thing, as far as I can see, is about improving the
> quality of Gentoo. I have learned from the reviewers reviewing my
> commits and the commits of others. It's extremely valuable to do this
> in public and the idea that noting an error on a public mailing list
> is somehow bad is simply misguided.

Perhaps you also missed:
>> Firstly I would like to say that I appreciate feedback on my work
>> - it helps me to improve the quality of my work both for Gentoo
>> and personally.
>> 
>> I also agree whole-heartedly to the concept of the Reviewers 
>> project, in that highlighting common improvements that could be
>> made would benefit both contributors who participate and Gentoo as
>> a whole.

I am not saying feedback is bad. I am not saying that learning to do
better is bad.

What I am saying is that until now contributors to Gentoo have received
feedback on their work in channels that they elected, whether it was
IRC, Bugzilla, Pull Requests or E-Mail; until suddenly their work (or
more accurately, the Reviewers teams issues with their work) were
getting broadcast to anyone who is subscribed to this list, regardless
of if that contributor wanted that kind of public critiquing.

I hope this clears up this apparent misunderstanding.

Kind Regards;
-- 
Sam Jorna (wraeth) 
GnuPG Key: B2D9F759



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/portage/

[Duncan]

Michał Górny posted on Sun, 11 Oct 2015 15:02:43 +0200 as excerpted:

> Furthermore, *please* don't mix old version removals with other changes.
> This makes it unnecessarily hard to revert breaking changes. Let's
> suppose you accidentally removed a version that had reverse
> dependencies. If you did it in a separate commit, we could quickly
> revert that commit and save users from seeing the breakage, and we could
> do the removal properly afterwards. When changes are mixed like this,
> you have to do partial reverts and partial re-commits, and things get
> unnecessarily hard.

Yes, please.  Advanced users doing direct git syncs appreciate it too. 
=:^)

The git experts drill this and drill this, as handled correctly, it's a 
major advantage git has over more traditional VCS tools, but it's oh so 
easy to not "get it", for those used to working with those more 
traditional but less flexible tools.  One single logical change per 
commit.  If you want to bunch up, bunch up the commits and push them all 
at once, but the commits really do need to be one logical change per 
commit.  It makes bisect-debugging, reverting, and cherry-picking, all 
three, /so/ much simpler. =:^)

Adding new python compatibility is one logical change.  Removing old 
ebuilds is another.  In fact, ideally each removal would be a separate 
commit.

It is, however, worth repeating that in git, commits are entirely 
separate from pushes and are very (as in, extremely!) cheap, while 
pushes, particularly if properly repoman-checked, are obviously much more 
expensive.  It's thus very possible to do all the above in a single 
/push/ even with each logical change in a separate /commit/.  Simply make 
each logical change a commit of its own without a push, until finished 
with what you wanted to do.  Then do the push of all the commits at 
once.  In fact, with git it's entirely possible to do separate commits to 
several unrelated things (in gentoo context, probably packages), then 
push them all at once, without screwing things up, because again, commits 
and pushes are entirely separate things, and just because all the changes/
commits happen to arrive at the same time with a single push, doesn't 
necessarily have anything at all to do with whether they're related, 
because the logical unit is the individual commit, not the push that 
lands all those individual commits upstream.

-- 
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] [RFC/announcement] Reviewers project

[Matt Turner]

On Sun, Oct 11, 2015 at 9:49 PM, NP-Hardass  wrote:
> I'm not sure if this is what Ian is referring to, but between the sheer
> quantity (flooding) and the way I perceived some of the messages to be
> formulated, it all seemed rather abrasive in nature.  Of course this
> was my own viewpoint on how things appeared, and I can't say whether
> that is what Ian or others perceived as well.

gentoo-dev@, the land of super threads. It's because of this mailing
list that I learned that gmail breaks threads at 100 messages.

I certainly haven't had trouble categorizing review threads appropriately.

Can someone point me (privately if you like) to a review they found
abrasive? I think I've read all the review threads, and nothing stood
out to me (but that was before I was specifically looking for such
things).

> Obviously, the goal of the project, which is an admirable one, is to
> provide reviews of commits and improve the quality of submissions both
> current and future.  It's my opinion that the means under which it has
> proceeded thus far undermine the end goal.  I'd love to see commentary
> on commits, but I am not sure that I think that the gentoo-dev list is
> appropriate.  I'd much rather see it happen on the gentoo-commits list.

I find the suggestion to use gentoo-commits@ for review illogical if
the quantity of mail received is a problem. :)

> Additionally, as mentioned by many others in this thread on all sides
> of the issue, the goal is to provide feedback and improve both
> users(whether they be end users or developers) and their submissions.
> I'd just like to state that those providing feedback should be mindful
> that how they provide that feedback is sometimes as important as the
> feedback itself.  I think care should be taken to be as friendly and
> approachable as possible.  Though some might disagree, I agree with the
> saying "you can catch more flies with honey than vinegar."
>
> Just my two cents of course.  Hopefully it'll help guide this new
> project toward a great future.

Totally agree. Thanks for your reply!

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Matt Turner]

On Sun, Oct 11, 2015 at 5:03 PM, Ian Delaney  wrote:
> On Sun, 11 Oct 2015 09:56:28 -0700
> Matt Turner  wrote:
>
>> On Sun, Oct 11, 2015 at 1:17 AM, wraeth  wrote:
>
>> >
>> > I feel that it is inappropriate for criticisms of contributor's
>> > work to be broadcast on a mailing list that is read not only by the
>> > developer community, but by users as well, without their consent.
>> > This is not a case where I am particularly embarrassed or upset -
>> > if others can learn from my mistakes, then they are mistakes I am
>> > happy to make (preferably only once). But doing so publicly, with
>> > identifying information, is inappropriate.
>>
>> Good grief. Seriously?
>>
>> Mailing list review is the *norm* in the free software world.
>>
>
> Oh, the norm

You're being quite rude with attempted mockery -- actually, the rest
of your reply is pretty abrupt as well.

If you want to fight, find someone and some place and  else. Otherwise
if you're interested in having a reasonable discussion, please read
on.

>> I haven't seen anything noted that should have caused embarrassment.
>>
>
> Nor I.
>> This whole thing, as far as I can see, is about improving the quality
>> of Gentoo. I have learned from the reviewers reviewing my commits and
>> the commits of others.
>
> The you haven't been embarrassed or demeaned or nitpicked. So far. Good.
>> It's extremely valuable to do this in public
>> and the idea that noting an error on a public mailing list is somehow
>> bad is simply misguided.
>>
>
> You throw your opinion on that of a user offering his personal
> reaction. What do you want here? Users to comply to your perspective
> and fit in? Users to tough out the exposure to full public view even if
> they don't like it?

I want to set expectations and explain that noting a mistake is not
anything to be self-conscious or embarrassed about.

> Once and for all this is a review put onto recipients whether they
> wanted it or not without their request or consent. A key aspect of
> learning is that the informative experience be made a positive one.
> This user is not alone. These self appointed educators have background
> in technical prowess and that's all. Quite simply, dishing out lessons
> that make users cringe and recoil is counter productive. This exercise

Why and where was a review "dished out" that made someone cringe or
recoil? I suspect this is just a strawman.

> is about educating, so these educators had better get their heads
> around some the fundamental requirement to command respect from their
> target audience. To date they have managed to deliver their product as
> they see fit. Now they get the feedback that follows from delivering
> their lessons.
>
> These educators have already started to learn some lessons of their
> own. An intrinsic aspect of the flow of teaching / educating is the
> impact of teacher behaviour upon their learners and a teacher's
> responsibility as an educator to deal with it productively. What's
> happening here? Teacher says take it because I gave it to you,now be
> quiet ?

No. It's a discussion. Review can be responded to -- reviewers aren't
intrinsically right.

> This is not a captive audience. It's an immediately convenient one.
> Educators snubbed by their students are not educators. At least not
> effective ones.  These students are so by nature of their own
> voluntary participation. They have the option of rejecting these
> lessons at their whim.

Patch review is widely accepted as a quality-improving tool. Some have
had difficulty adjusting to it when coming from, for instance, the
closed-source world, primarily because they equate making a mistake to
personal failure (and as such, having it pointed out in public makes
it worse).

http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/
offers a good explanation.

"The most productive contributors see each mistake they make as a
growth opportunity, instead of a personal failure."

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[NP-Hardass]

On Sun, 11 Oct 2015 19:37:23 -0700
Matt Turner  wrote:

> On Sun, Oct 11, 2015 at 5:03 PM, Ian Delaney  
> wrote:
>> On Sun, 11 Oct 2015 09:56:28 -0700 Matt Turner 
>>  wrote:
>> 
>>> On Sun, Oct 11, 2015 at 1:17 AM, wraeth  
>>> wrote:
>> 
 
 I feel that it is inappropriate for criticisms of 
 contributor's work to be broadcast on a mailing list that is
  read not only by the developer community, but by users as 
 well, without their consent. This is not a case where I am 
 particularly embarrassed or upset - if others can learn from
  my mistakes, then they are mistakes I am happy to make 
 (preferably only once). But doing so publicly, with 
 identifying information, is inappropriate.
>>> 
>>> Good grief. Seriously?
>>> 
>>> Mailing list review is the *norm* in the free software world.
>>> 
>> 
>> Oh, the norm
> 
> You're being quite rude with attempted mockery -- actually, the 
> rest of your reply is pretty abrupt as well.
> 
> If you want to fight, find someone and some place and  else. 
> Otherwise if you're interested in having a reasonable discussion, 
> please read on.
> 
>>> I haven't seen anything noted that should have caused 
>>> embarrassment.
>>> 
>> 
>> Nor I.
>>> This whole thing, as far as I can see, is about improving the 
>>> quality of Gentoo. I have learned from the reviewers reviewing
>>>  my commits and the commits of others.
>> 
>> The you haven't been embarrassed or demeaned or nitpicked. So 
>> far. Good.
>>> It's extremely valuable to do this in public and the idea that
>>>  noting an error on a public mailing list is somehow bad is 
>>> simply misguided.
>>> 
>> 
>> You throw your opinion on that of a user offering his personal 
>> reaction. What do you want here? Users to comply to your 
>> perspective and fit in? Users to tough out the exposure to full 
>> public view even if they don't like it?
> 
> I want to set expectations and explain that noting a mistake is
> not anything to be self-conscious or embarrassed about.
> 
>> Once and for all this is a review put onto recipients whether 
>> they wanted it or not without their request or consent. A key 
>> aspect of learning is that the informative experience be made a 
>> positive one. This user is not alone. These self appointed 
>> educators have background in technical prowess and that's all. 
>> Quite simply, dishing out lessons that make users cringe and 
>> recoil is counter productive. This exercise
> 
> Why and where was a review "dished out" that made someone cringe
> or recoil? I suspect this is just a strawman.
> 
>> is about educating, so these educators had better get their
>> heads around some the fundamental requirement to command respect
>> from their target audience. To date they have managed to deliver
>> their product as they see fit. Now they get the feedback that
>> follows from delivering their lessons.
>> 
>> These educators have already started to learn some lessons of 
>> their own. An intrinsic aspect of the flow of teaching / 
>> educating is the impact of teacher behaviour upon their learners
>>  and a teacher's responsibility as an educator to deal with it 
>> productively. What's happening here? Teacher says take it because
>> I gave it to you,now be quiet ?
> 
> No. It's a discussion. Review can be responded to -- reviewers 
> aren't intrinsically right.
> 
>> This is not a captive audience. It's an immediately convenient 
>> one. Educators snubbed by their students are not educators. At 
>> least not effective ones.  These students are so by nature of 
>> their own voluntary participation. They have the option of 
>> rejecting these lessons at their whim.
> 
> Patch review is widely accepted as a quality-improving tool. Some 
> have had difficulty adjusting to it when coming from, for instance,
> the closed-source world, primarily because they equate making a
> mistake to personal failure (and as such, having it pointed out in
> public makes it worse).
> 
> http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/
>
>
>
> 
offers a good explanation.
> 
> "The most productive contributors see each mistake they make as a 
> growth opportunity, instead of a personal failure."
> 

I'm not sure if this is what Ian is referring to, but between the sheer
quantity (flooding) and the way I perceived some of the messages to be
formulated, it all seemed rather abrasive in nature.  Of course this
was my own viewpoint on how things appeared, and I can't say whether
that is what Ian or others perceived as well.

Obviously, the goal of the project, which is an admirable one, is to
provide reviews of commits and improve the quality of submissions both
current and future.  It's my opinion that the means under which it has
proceeded thus far undermine the end goal.  I'd love to see commentary
on commits, but I am not sure that I think that the gentoo-dev list is
appropriate.  I'd 

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Matt Turner]

On Sun, Oct 11, 2015 at 9:44 PM, wraeth  wrote:
> I'm not trying to escalate the argument but you seem to have
> misinterpreted my initial message.
>
> On 12/10/15 03:56, Matt Turner wrote:
>> On Sun, Oct 11, 2015 at 1:17 AM, wraeth  wrote:
>>> I am one of the users who spoke to idella4 about this, but I wanted
>>> to repeat this publicly in order to highlight the point of view of
>>> contributing user as opposed to a developer.
>>>
>>> Firstly I would like to say that I appreciate feedback on my work -
>>> it helps me to improve the quality of my work both for Gentoo and
> personally.
>>>
>>> I also agree whole-heartedly to the concept of the Reviewers
>>> project, in that highlighting common improvements that could be
>>> made would benefit both contributors who participate and Gentoo as
>>> a whole.
>>>
>>> Having said that, however, I do not appreciate the method in which
>>> these criticisms were delivered, and believe it extends beyond the
>>> idea of the Reviewers project.
>>>
>>> I feel that it is inappropriate for criticisms of contributor's
>>> work to be broadcast on a mailing list that is read not only by the
>>> developer community, but by users as well, without their consent.
>>> This is not a case where I am particularly embarrassed or upset -
>>> if others can learn from my mistakes, then they are mistakes I am
>>> happy to make (preferably only once). But doing so publicly, with
>>> identifying information, is inappropriate.
>>
>> Good grief. Seriously?
>
> Yes, I am being serious. Thanks for asking.
>
>> Mailing list review is the *norm* in the free software world.
>
> I am aware of this and that it has been the way for quite
> some time. However, while it may be the norm in the wider FOSS
> community, it has not been the norm on the gentoo-dev list - certainly
> people will post things specifically for review, or may highlight
> critical issues; but it has not until recently been a channel for review
> of any and all commits that the Reviewers inspect.
>
> It is not the fact that there is a review or education process, but that
> this process was executed with the level of tact and grace becoming of a
> flock of ducks flying into the side of a building.

So work with the reviewers to ensure the communication is tactful and graceful.

FWIW, I haven't seen any review comments that were impolite or
uncivil. Feel free to direct me to them... I've been correcting
miscommunications on gentoo-dev this week...

> This education process was implemented in a way that indiscriminately
> pointed the finger at contributors, developer and user alike, sometimes

I think this confirms my belief -- that people are misinterpreting a
mistake as a personal failing and are upset by it being addressed in
(a new) public forum.

> for things that mattered, and other times for things that simply didn't.
> What's more, it was implemented without warning and included publishing
> who the author of those mistakes was without the contributor knowing
> that it would be used so (you know, since the whole commit header was in
> this educational message, too).
>
>> I haven't seen anything noted that should have caused embarrassment.
>
> Perhaps you missed:
>>> This is not a case where I am particularly embarrassed or upset -
>>> if others can learn from my mistakes, then they are mistakes I am
>>> happy to make (preferably only once).
>
>> This whole thing, as far as I can see, is about improving the
>> quality of Gentoo. I have learned from the reviewers reviewing my
>> commits and the commits of others. It's extremely valuable to do this
>> in public and the idea that noting an error on a public mailing list
>> is somehow bad is simply misguided.
>
> Perhaps you also missed:
>>> Firstly I would like to say that I appreciate feedback on my work
>>> - it helps me to improve the quality of my work both for Gentoo
>>> and personally.
>>>
>>> I also agree whole-heartedly to the concept of the Reviewers
>>> project, in that highlighting common improvements that could be
>>> made would benefit both contributors who participate and Gentoo as
>>> a whole.
>
> I am not saying feedback is bad. I am not saying that learning to do
> better is bad.

Okay, so it's not about embarrassment or having one's work scrutinized.

> What I am saying is that until now contributors to Gentoo have received
> feedback on their work in channels that they elected, whether it was
> IRC, Bugzilla, Pull Requests or E-Mail; until suddenly their work (or
> more accurately, the Reviewers teams issues with their work) were
> getting broadcast to anyone who is subscribed to this list, regardless
> of if that contributor wanted that kind of public critiquing.
>
> I hope this clears up this apparent misunderstanding.

The problem is that the review is being done in... a different forum
that you expect? Or that it's a forum that more people are reading?

I don't know -- a lot of the value is precisely that -- 

[gentoo-dev] xf86-input-evdev patch problem

[Cor Legemaat]

Hi:
 
I created a ebuild with a patch for xf86-input-evdev to try and 
debounce my mouse button. The ebuild is at 
https://github.com/cor-mt/portage-overlay/blob/master/x11-drivers/xf86-input-evdev/xf86-input-evdev-2.9.2-r1.ebuild
 it compile and install fine but with it installed neither the 
keyboard nor mouse is working. If I am correct it should install 100% 
the same as from gentoo without the "debounce" use flag but it gives 
the same symptoms.
 
What am I doing wrong?
 
Regards:
Cor

signature.asc
Description: This is a digitally signed message part