Re: [gentoo-dev] [PATCH] metadata: add slots element

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 12 Oct 2015 23:49:11 +0200
"Andreas K. Huettel"  wrote:

> There seems to be some general confusion about specific package SLOTs
> and their meaning, since there can be several naming schemes applied
> and documentation is either non-existent or is inside the ebuild via
> comments.
> Because of that it should be part of metadata.xml.
> 
> An example use case for media-libs/libpng would be:
> 
> For building against. This is the only slot
> that provides headers and command line tools.
> For binary compatibility, provides
> libpng12.so.0. For binary compatibility,
> provides libpng15.so.15. Represent ABI compatibility
> for libpng.so. 
> 
> For packages like x11-libs/wxGTK one could write:
> 
> Major versions.
> 
> ---
>  metadata.dtd | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/metadata.dtd b/metadata.dtd
> index ff2649c..4b29f3b 100644
> --- a/metadata.dtd
> +++ b/metadata.dtd
> @@ -5,7 +5,7 @@
>  
>  
>  
> - ( (herd|maintainer|natural-name|longdescription|use|upstream)* )>
> + ( (herd|maintainer|natural-name|longdescription|slots|use|upstream)*
> )>   @@ -20,6 +20,15 @@
>
>
>  
> +  
> +  
> +
> +
> +  
> +  
> +
> +
> +
>
> @@ -79,6 +88,7 @@
>language "C" or "en", which is equivalent -->
>
>
> +  
>
>  
>  

Re: [gentoo-dev] [PATCH] metadata: add slots element

[Ian Delaney]

On Mon, 12 Oct 2015 20:01:15 +0200
hasufell  wrote:

> On 10/12/2015 07:49 PM, Alexis Ballier wrote:
> > On Mon, 12 Oct 2015 19:19:33 +0200
> > Julian Ospald  wrote:
> > 
> >> There seems to be some general confusion about specific package
> >> SLOTs and their meaning, since there can be several naming schemes
> >> applied and documentation is either non-existent or is inside the
> >> ebuild via comments.
> >> Because of that it should be part of metadata.xml.
> > 
> > 

Oh that word should.
You appear to state this as fact.
> > Why not, but what's the advantage of xmlizing it vs comments in the
> > ebuilds?
> > 
> 
> Because metadata.xml is the place for metadata and has a defined,
> verifiable and useful (in terms of actual processing/parsing data)
> form.
> 
> Even if you want those things to be in the ebuild, it would definitely
> not be comments, but actual syntax (like exheres).
> 
> So basically the same arguments for not having random comments for USE
> flags in the ebuilds apply.
> 

random? RANDOM? How about a carefully thought out and pertinent one
then? While use of xmlizing appears fine, I fail to see anything wrong
with entering a commented line in an ebuild as developers do all the
time as standard 'workflow'.
Just my 2 phennigs worth.

-- 
kind regards

Ian Delaney

Re: [gentoo-dev] [PATCH] metadata: add slots element

[Andreas K. Huettel]

Am Montag, 12. Oktober 2015, 19:19:33 schrieb Julian Ospald:
> An example use case for media-libs/libpng would be:
> 
> For building against. This is the only slot
> that provides headers and command line tools.
> For binary compatibility, provides
> libpng12.so.0. For binary compatibility, provides
> libpng15.so.15. Represent ABI compatibility for
> libpng.so. 
> 
> For packages like x11-libs/wxGTK one could write:
> 
> Major versions.
> 

+1

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

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

[Matthias Maier]

Just a comment before this discussion gets entirely side tracked.



On Mon, Oct 12, 2015, at 11:45 CDT, Ian Delaney  wrote:

> [...]

> Users are neither seasoned nor prepared for the type of review put
> upon them by him and mgorny.

My impression is that the reception of the code review on github is
predominantly positive. The point is - we _have_ to do some sort of code
review prior to merging (or stick to the old "let a developer do all the
work" workflow we suffered from all the years).

A very nice example of how this can be facilitated to get a lot of user
contributions is the science overlay - and I think the current review
for gentoo/gentoo is not far away from the approach, word choice, or
debate culture we have there.


> These users still needed support and a voice to help them speak up, and
> they did. Still, these members have fashioned themselves to teach and
> service users, They have alot of adapting to do before users will
> embrace their attempts to educate them.

Seriously? Shall we now all take an online tutorial in order to be
qualified to "help out"? Or shall we just merge every pull-request in
order to not have to interact with users?



There are some observations for Julian and Michał (as the two primary
reviewer on github) that I have, though. I think it might be worthwhile
to think about it and maybe "codify" it in the reviewer best practices
(if not already present):


 - I suggest that only one reviewer administers a given pull-request at
   a time. I have seen two instances where first Julian had roughly 20
   remarks and after those were resolved Michał slabbed another 10 code
   remarks on top of it.

   This seems to be a bit over the top. It feels a bit like vultures
   tearing apart dead prey ;-)

   The bottom line should be that if one Gentoo developer is satisfied
   with the state of a pull-request it should be okay.


 - With respect to the current post- "peer review" of commits: I suggest
   that comments on coding style (if not violating our indent rules) and
   other personal choice is kept at a bare minimum (or avoided
   entirely). While I appreciate comments on factual errors I have
   commited [1], I totally hate discussing something like whether a "\"
   might be omitted in bash or not.


 - Further, "weird" or "unusual" choices of, e.g., how to form up a
   configuration variable might be due to historical (and sometimes
   political reasons). For example, because of a switch of
   maintainership, or due to a developer just "helping out" (and
   obviously avoiding invasive, large changes).

   Thus, comments like "this is hard to read", "why do you do it like
   that" are usually more annoying than helpful [2].


 - And last, keep in mind that discussing the current state of an ebuild
   on a version bump is equivalent to discussing an arbitrary amount of
   commits over the last years (and given the vivid history of some
   ebuilds of code fragments from a lot of people).

   An example here would be the missing "|| die" statements on a sed
   statement that manipulated an entirely gentoo-developer controlled
   configuration file [3]. While it is technically correct that a "die"
   is missing - it doesn't hurt terribly much either (no file involved
   is controlled by upstream and might silently change during a version
   bump).


Best,
Matthias



[1] Julian, thanks again for catching this silly typo in
app-emulation/libvirt :-D

[2] notwithstanding whether the comments are correct/justified on a
purely technical level.

[3] again app-emulation/libvirt

Re: [gentoo-dev] [PATCH] metadata: add slots element

[Alexis Ballier]

On Mon, 12 Oct 2015 20:01:15 +0200
hasufell  wrote:

> On 10/12/2015 07:49 PM, Alexis Ballier wrote:
> > On Mon, 12 Oct 2015 19:19:33 +0200
> > Julian Ospald  wrote:
> >   
> >> There seems to be some general confusion about specific package
> >> SLOTs and their meaning, since there can be several naming schemes
> >> applied and documentation is either non-existent or is inside the
> >> ebuild via comments.
> >> Because of that it should be part of metadata.xml.  
> > 
> > 
> > Why not, but what's the advantage of xmlizing it vs comments in the
> > ebuilds?
> >   
> 
> Because metadata.xml is the place for metadata and has a defined,
> verifiable and useful (in terms of actual processing/parsing data)
> form.
> 
> Even if you want those things to be in the ebuild, it would definitely
> not be comments, but actual syntax (like exheres).
> 
> So basically the same arguments for not having random comments for USE
> flags in the ebuilds apply.
> 

makes sense

*clicks like*

Re: [gentoo-dev] [PATCH] metadata: add slots element

[hasufell]

On 10/12/2015 07:49 PM, Alexis Ballier wrote:
> On Mon, 12 Oct 2015 19:19:33 +0200
> Julian Ospald  wrote:
> 
>> There seems to be some general confusion about specific package SLOTs
>> and their meaning, since there can be several naming schemes applied
>> and documentation is either non-existent or is inside the ebuild via
>> comments.
>> Because of that it should be part of metadata.xml.
> 
> 
> Why not, but what's the advantage of xmlizing it vs comments in the
> ebuilds?
> 

Because metadata.xml is the place for metadata and has a defined,
verifiable and useful (in terms of actual processing/parsing data) form.

Even if you want those things to be in the ebuild, it would definitely
not be comments, but actual syntax (like exheres).

So basically the same arguments for not having random comments for USE
flags in the ebuilds apply.

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

[Rich Freeman]

On Mon, Oct 12, 2015 at 1:44 PM, Alec Warner  wrote:
>
>
> On Mon, Oct 12, 2015 at 3:58 AM, Rich Freeman  wrote:
>>
>> On Sun, Oct 11, 2015 at 11:35 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> >
>> > 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.
>>
>> Each commit really should be able to stand on its own all the same.
>>
>> They should all be able to pass a repoman check.
>
>
> I guess in some ideal world I sort of agree; but in practice I think
> workflows exist that involve people messing around in their local repo until
> they get stuff right, then running repoman at the end and pushing the result
> (that is kind of the whole point of having a local staging repo.)

I think the best practice here really depends on the nature of what
you're working on.  For most software the right way to handle such
things is to either:
1.  If you're just doing multiple iterations on one true logical
change, rebase your commits into a single commit once you have it
right.  You could extend this into a few commits in some cases as long
as they can stand on their own.
2.  Do all the work on a side branch and do a merge commit into the
master branch.  Then master still has a history where every commit
(along one side) works.  This is the best approach for the development
of major features which necessarily will not be complete for extended
periods but where the details are still useful.

#1 is likely to be most appropriate for the Gentoo repo in most cases.

-- 
Rich

Re: [gentoo-dev] [PATCH] metadata: add slots element

[Alexis Ballier]

On Mon, 12 Oct 2015 19:19:33 +0200
Julian Ospald  wrote:

> There seems to be some general confusion about specific package SLOTs
> and their meaning, since there can be several naming schemes applied
> and documentation is either non-existent or is inside the ebuild via
> comments.
> Because of that it should be part of metadata.xml.


Why not, but what's the advantage of xmlizing it vs comments in the
ebuilds?

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

[Alec Warner]

On Mon, Oct 12, 2015 at 3:58 AM, Rich Freeman  wrote:

> On Sun, Oct 11, 2015 at 11:35 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> >
> > 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.
>
> Each commit really should be able to stand on its own all the same.

They should all be able to pass a repoman check.
>

I guess in some ideal world I sort of agree; but in practice I think
workflows exist that involve people messing around in their local repo
until they get stuff right, then running repoman at the end and pushing the
result (that is kind of the whole point of having a local staging repo.)

-A


>
> Otherwise when you do try to use tools like bisect you can get
> breakage.  It is really frustrating when you're trying to track down a
> change that causes an issue and find a large stretch of commits that
> won't even build.
>
> --
> Rich
>
>

[gentoo-dev] [PATCH] metadata: add slots element

[Julian Ospald]

There seems to be some general confusion about specific package SLOTs
and their meaning, since there can be several naming schemes applied
and documentation is either non-existent or is inside the ebuild via
comments.
Because of that it should be part of metadata.xml.

An example use case for media-libs/libpng would be:

For building against. This is the only slot
that provides headers and command line tools.
For binary compatibility, provides libpng12.so.0.
For binary compatibility, provides libpng15.so.15.
Represent ABI compatibility for libpng.so.


For packages like x11-libs/wxGTK one could write:

Major versions.

---
 metadata.dtd | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/metadata.dtd b/metadata.dtd
index ff2649c..4b29f3b 100644
--- a/metadata.dtd
+++ b/metadata.dtd
@@ -5,7 +5,7 @@
 
 
 
-
+
 
 
   
@@ -20,6 +20,15 @@
   
   
 
+  
+  
+
+
+  
+  
+
+
+
   
   
@@ -79,6 +88,7 @@
   language "C" or "en", which is equivalent -->
   
   
+  
   
 
 

[gentoo-dev] [RFC] Allow SLOT documentation in metadata.xml

[Julian Ospald]

The following patch tries to address the lack of slot
documentation, since getting the slots of a dependency
right seems like a common problem.

Things that I was particularly not sure about: the 'subslots'
element. Having a sub-element for 'slot' seemed even more
messy, so I tried to make this as simple as possible, so
that maintainers don't get angry and give up when trying
to document their slots. However, this is a little bit
at the expense of correctness, because you cannot
document different subslot naming schemes if they differ
between slots of a single package (does such thing even exist
in the tree?).

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

[Michał Górny]

Taking a random commit to explain a recent-yet-common mistake.

> dev-python/subunit: Add python3.5 support
>
> [...]
> 
>  dev-python/subunit/subunit-1.1.0-r1.ebuild | 90 
> ++
>  1 file changed, 90 insertions(+)

Let's make this clear once and for all: there is no need to revbump
when adding python3.5 to PYTHON_COMPAT, and this includes stable
packages. This is because:

1. adding it to PYTHON_COMPAT adds a new USE flag, and the added
dependency is conditional to the USE flag. People who have the package
installed already don't have python3.5 support in it and don't need
the new dependency. People who want python3.5 will get the package
rebuilt due to --changed-use or cross-package USE dependencies.

2. python_targets_python3_5 is stable-masked. This means that the new
flag simply won't appear on stable packages until python3.5 goes
stable. No need to play with keywords.

So once again: please don't bump packages unnecessarily when adding
python3.5 to PYTHON_COMPAT. However, if you add new patches or other
ebuild code changes, revbump is desired.

-- 
Best regards,
Michał Górny



pgpAIjEBKLF26.pgp
Description: OpenPGP digital signature

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

[Ciaran McCreesh]

On Mon, 12 Oct 2015 13:13:15 +0800
Ian Delaney wrote:
> 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.

So how about letting them that if they make a mistake, there are now
ways of rectifying that quickly?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

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

[Ian Delaney]

On Mon, 12 Oct 2015 08:19:34 -0700
Matt Turner  wrote:

> On Mon, Oct 12, 2015 at 7:23 AM, hasufell  wrote:
> >
> > I'm not a native speaker and people have more than once told you
> > that your language is difficult to understand.
> >
> > So, can you elaborate what your sarcastic (that's how I read it)
> > anecdote was meant for then? Preferably off-list, since this doesn't
> > seem to help any of us.
> 
> I am a native speaker and I cannot understand what he's saying, for
> what it's worth.
> 
> I think he's indicating that the "right" in his earlier message was
> indicative of sarcasm, and so then he chides you for responding to his
> sarcastic message without knowing it was sarcasm. 

fwiw how about not sure what you mean by that please re-sate. Better
that than misinterpreting and responding to a totally wrong message.
This was an innocent accident mostly.    is to help all us who
cannot write ebuilds correctly or proficiently?  I generally don't do
sarcasm however with this thread it can be hard to avoid. right is
ambiguous here. He read it as:

all us who cannot write ebuilds, right?
or
all us who cannot write ebuilds? Right?

completely changing the meaning to

all us who cannot write ebuilds at all?
The sentence started out as a question so finishing with

ebuilds right?  unfortunately mislead him. Never intended. The sentence
was too long. I should have simply stopped it with 

How exactly may I ask does anyone actually offer help to the Reviewers
Project?
Confusing or misleading him was never my intent or goal. He has enough
of that already.

The absurd thing is
> that he then says "Please stop taking words out of my mouth and
> distorting my message" (which of course you weren't doing), which was
> *precisely* what he was doing.
> 

I was doing no such thing and I resent this accusation in the strongest
terms.  My meaning here was that he took the 'right' out or the
sentence, or question, equating to taking out.  Any distortion here was
accidental and unfortunate and you need not add to the tension by
accusing me of distortion.


The user here is indeed the exception to the rule, or the norm. And as
rich0 said, the 80% 20% rule may apply. The fact is however that the
20% were grossly unimpressed.  Users are neither seasoned nor prepared
for the type of review put upon them by him and mgorny. Even Amynka
struggled with it. Read the rest of the emails dev to dev and it's a
walk in the park. It all works.  His efforts aimed at devs developing
ebuilds are fine and happy with them.  

These users still needed support and a voice to help them speak up, and
they did. Still, these members have fashioned themselves to teach and
service users, They have alot of adapting to do before users will
embrace their attempts to educate them.

> In another subthread I really got the sense that he's simply
> attempting to provoke a response. I suggest not giving him that.
> 

I won't be giving any more to him I suspect.

enough it's late

-- 
kind regards

Ian Delaney

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

[Matt Turner]

On Mon, Oct 12, 2015 at 7:23 AM, hasufell  wrote:
> On 10/12/2015 04:12 PM, Ian Delaney wrote:
>> On Mon, 12 Oct 2015 15:47:19 +0200
>> hasufell  wrote:
>>
>>> On 10/12/2015 03:29 PM, Ian Delaney wrote:

 Not sure how to read this. The whole idea is for provider / client
 to communicate and negotiate a workable solution. At a glance this
 reads as the user needs to adapt to the service that the client is
 offering and appease the provider. What's wrong with this picture?

 How exactly may I ask does anyone actually offer help to the
 Reviewers project whose whole aim it seems is to help all us who
 cannot write ebuilds right?

>>>
>>> Nowhere did way say that people cannot write ebuilds, nor did we
>>> impose that picture. That all happened in your own mind.
>>>
>>
>> Yes Julian. Neither did I Julian. I said 'who cannot write ebuilds
>> RIGHT'. Please stop taking words out of my mouth and distorting my
>> message.
>>
>
> I'm not a native speaker and people have more than once told you that
> your language is difficult to understand.
>
> So, can you elaborate what your sarcastic (that's how I read it)
> anecdote was meant for then? Preferably off-list, since this doesn't
> seem to help any of us.

I am a native speaker and I cannot understand what he's saying, for
what it's worth.

I think he's indicating that the "right" in his earlier message was
indicative of sarcasm, and so then he chides you for responding to his
sarcastic message without knowing it was sarcasm. The absurd thing is
that he then says "Please stop taking words out of my mouth and
distorting my message" (which of course you weren't doing), which was
*precisely* what he was doing.

In another subthread I really got the sense that he's simply
attempting to provoke a response. I suggest not giving him that.

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

[Alexis Ballier]

On Mon, 12 Oct 2015 15:53:42 +0200
hasufell  wrote:

> On 10/12/2015 03:41 PM, Alexis Ballier wrote:
> > 
> > They might have failed to notify it,  
> 
> I did that 2 hours ago already on this thread. What does that tell
> us ;)


yes, I noticed from there :p

what I meant was rather that it hadn't been advertised enough yet :)

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

[hasufell]

On 10/12/2015 04:12 PM, Ian Delaney wrote:
> On Mon, 12 Oct 2015 15:47:19 +0200
> hasufell  wrote:
> 
>> On 10/12/2015 03:29 PM, Ian Delaney wrote:
>>>
>>> Not sure how to read this. The whole idea is for provider / client
>>> to communicate and negotiate a workable solution. At a glance this
>>> reads as the user needs to adapt to the service that the client is
>>> offering and appease the provider. What's wrong with this picture?
>>>
>>> How exactly may I ask does anyone actually offer help to the
>>> Reviewers project whose whole aim it seems is to help all us who
>>> cannot write ebuilds right?
>>>
>>
>> Nowhere did way say that people cannot write ebuilds, nor did we
>> impose that picture. That all happened in your own mind.
>>
> 
> Yes Julian. Neither did I Julian. I said 'who cannot write ebuilds
> RIGHT'. Please stop taking words out of my mouth and distorting my
> message.
> 

I'm not a native speaker and people have more than once told you that
your language is difficult to understand.

So, can you elaborate what your sarcastic (that's how I read it)
anecdote was meant for then? Preferably off-list, since this doesn't
seem to help any of us.

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

[Ian Delaney]

On Mon, 12 Oct 2015 15:47:19 +0200
hasufell  wrote:

> On 10/12/2015 03:29 PM, Ian Delaney wrote:
> > 
> > Not sure how to read this. The whole idea is for provider / client
> > to communicate and negotiate a workable solution. At a glance this
> > reads as the user needs to adapt to the service that the client is
> > offering and appease the provider. What's wrong with this picture?
> > 
> > How exactly may I ask does anyone actually offer help to the
> > Reviewers project whose whole aim it seems is to help all us who
> > cannot write ebuilds right?
> > 
> 
> Nowhere did way say that people cannot write ebuilds, nor did we
> impose that picture. That all happened in your own mind.
> 

Yes Julian. Neither did I Julian. I said 'who cannot write ebuilds
RIGHT'. Please stop taking words out of my mouth and distorting my
message.

> Your picture about our goals is completely incorrect and you seem to
> respond to something that's not really our project. So I'd like to ask
> you to take a few moments and actually read our replies and the
> project page, before we derail even further here.
> 

Yes Julian. You have it right and I have it wrong. I feel relieved now

-- 
kind regards

Ian Delaney

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

[hasufell]

On 10/12/2015 03:51 PM, Rich Freeman wrote:

> That's why I
> suggested a top-5 list or something like that, which would have weeded
> out false positives and focus more on resolutions and trends than
> individual incidents.
> 

https://wiki.gentoo.org/wiki/Project:Reviewers/Common_issues

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

[hasufell]

On 10/12/2015 03:58 PM, wraeth wrote:
> I don't expect everything to have been within the N^th degree of
> perfection from day one; and I honestly hope the Reviewers project
> finds its feet and benefits the community; I just believe that it's
> first day could have been handled better.
> 

We've had that discussed a hundred times now, can we move on? Because
honestly, I don't see how this gets us any further.

If you want to help, do reviews, suggest project page changes, propagate
the project.

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

[wraeth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/10/15 22:15, hasufell wrote:
> On 10/12/2015 06:44 AM, wraeth wrote:
>> 
>> 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).
>> 
> 
> We already have been working on making an internal policy about
> _how_ and _where_ to review.
> 
> https://wiki.gentoo.org/wiki/Project:Reviewers/Internal_policy

I have noticed this and have been watching it evolve over the last day
or so.

>> 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.
> 
> And another point that I have to make very clear... while we are 
> certainly trying to find the best suited channel for reviews, the 
> selection of which one is the best is definitely _not_ about "how
> do I minimize public exposure?", but "where is this review
> relevant?" and "where does the author of the patch respond to most
> quickly?".

I can appreciate that it is difficult to find the right channel for
these sort of reviews - it's something that could be useful to a lot
of people. As I've mentioned, I support the idea of the Reviewers
project and welcome feedback to my own work.

> And frankly, if "public exposure" is a problem for you, then
> that's something you have to work on if you like to contribute to
> FOSS. It's not personal, it's technical. We will definitely not
> keep a list of people who are afraid that a review of their code is
> posted somewhere more public (assuming that the ebuild is already
> GPL-2 or similar and public). But we'll try to post it where it is
> relevant and where the author will respond... if that place is
> private mail, then so be it, but again... we'll not keep a list for
> that around. And it will be a learning experience for us too to
> figure out how to approach this best, including the correct place,
> the amount of nitpicking and so on. You cannot expect that
> everything happens at day 1.

A relevant counterpoint to this is:
>> 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).

I expanded upon this in a different reply to earlier message.

It's not the fact that the reviews were posted publicly, it's the fact
that it was done so without warning. And further, while I'm somewhat
taken aback by it myself, it's more the fact that this type sudden
change to how feedback is given affects more than just seasoned
developers, it also affects existing and potential contributors, both
those who are used to the FOSS 'norm' and those who are offering their
first contributions to their favourite project. As I explained in my
other reply, typically when you begin contributing to a FOSS
community, you do so knowing what mechanisms are used for review and
where critiques of your work may end up.

I don't expect everything to have been within the N^th degree of
perfection from day one; and I honestly hope the Reviewers project
finds its feet and benefits the community; I just believe that it's
first day could have been handled better.

Kind Regards;
- -- 
Sam Jorna (wraeth) 
GnuPG Key: B2D9F759
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYbvGwACgkQXcRKerLZ91k1/gD/e3Tbigd1BeEtb6ghOAFZv0Jq
9PmPPbSDrq6v8NfKd5kA/1CQoJnrHzFB38BrHvZHQmvuuQtKG+9kmHQ10WJ5kJD2
=9UP+
-END PGP SIGNATURE-

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

[hasufell]

On 10/12/2015 03:41 PM, Alexis Ballier wrote:
> 
> They might have failed to notify it,

I did that 2 hours ago already on this thread. What does that tell us ;)

 but I think they've taken into
> account most, if not all, of the problems that had been pointed out:
> https://wiki.gentoo.org/wiki/Project:Reviewers/Internal_policy
> 
> 

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

[Rich Freeman]

On Mon, Oct 12, 2015 at 9:29 AM, Ian Delaney  wrote:
>
> Not sure how to read this. The whole idea is for provider / client to
> communicate and negotiate a workable solution. At a glance this reads
> as the user needs to adapt to the service that the client is offering
> and appease the provider. What's wrong with this picture?

While I agree that this had a bit of a rough start, I don't think it
is realistic for any Gentoo project to tailor how it communicates to
each individual.  By all means find the 80% solution that works for
most, but if having bugs being opened seems to be the best solution,
we can't really have individual developers saying "don't open bugs for
me - just ping me on IRC/email/phone/the-bar-at-the-next-FOSDEM/etc."

I suggest we focus more on finding that common solution.

FWIW I don't see any issue with this stuff being public.  It shouldn't
be personal, and we should be making feedback as helpful as reasonably
possible.  That could be as simple as an email signature that says
"the above feedback is intended to be concise and is targeted at an
experienced Gentoo developer, if you have any questions about how to
handle it please do ABC to get help."  Just having an invitation for
support would probably go a long way, and we could have a separate set
of volunteers (perhaps overlapping) who volunteer to provide this
help.

To the extent that anything is said which shouldn't be said in public,
we probably shouldn't be saying it in private either, at least not in
the context of this project.

My concern with the -dev list was more that it ends up being a lot of
noise for most on the list, not that it is public.  That's why I
suggested a top-5 list or something like that, which would have weeded
out false positives and focus more on resolutions and trends than
individual incidents.

-- 
Rich

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

[hasufell]

On 10/12/2015 03:29 PM, Ian Delaney wrote:
> 
> Not sure how to read this. The whole idea is for provider / client to
> communicate and negotiate a workable solution. At a glance this reads
> as the user needs to adapt to the service that the client is offering
> and appease the provider. What's wrong with this picture?
> 
> How exactly may I ask does anyone actually offer help to the Reviewers
> project whose whole aim it seems is to help all us who cannot write
> ebuilds right?
> 

Nowhere did way say that people cannot write ebuilds, nor did we impose
that picture. That all happened in your own mind.

Your picture about our goals is completely incorrect and you seem to
respond to something that's not really our project. So I'd like to ask
you to take a few moments and actually read our replies and the project
page, before we derail even further here.

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

[Alexis Ballier]

On Mon, 12 Oct 2015 21:29:26 +0800
Ian Delaney wrote:

> On Mon, 12 Oct 2015 13:16:01 +0200
> hasufell  wrote:
> 
> > On 10/12/2015 06:56 AM, Matt Turner wrote:  
> > > 
> > > So work with the reviewers to ensure the communication is tactful
> > > and graceful.
> > >   
> > 
> > That would be appreciated. So far, we mostly got people complaining
> > (and some setting up sieve filters to throw all our mails to
> > trash),  
> 
> what does this tell you?
> > but not people offering help. The latter has a bigger chance of
> > actually having an impact.
> > 
> >   
> 
> Not sure how to read this. The whole idea is for provider / client to
> communicate and negotiate a workable solution. At a glance this reads
> as the user needs to adapt to the service that the client is offering
> and appease the provider. What's wrong with this picture?
> 
> How exactly may I ask does anyone actually offer help to the Reviewers
> project whose whole aim it seems is to help all us who cannot write
> ebuilds right? By going along with your flow, with neither question
> nor comment?  Where is the part about the educators leading the way
> with tact and grace? Who is the leader here?
> 

They might have failed to notify it, but I think they've taken into
account most, if not all, of the problems that had been pointed out:
https://wiki.gentoo.org/wiki/Project:Reviewers/Internal_policy

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

[Ian Delaney]

On Mon, 12 Oct 2015 13:16:01 +0200
hasufell  wrote:

> On 10/12/2015 06:56 AM, Matt Turner wrote:
> > 
> > So work with the reviewers to ensure the communication is tactful
> > and graceful.
> > 
> 
> That would be appreciated. So far, we mostly got people complaining
> (and some setting up sieve filters to throw all our mails to trash),

what does this tell you?
> but not people offering help. The latter has a bigger chance of
> actually having an impact.
> 
> 

Not sure how to read this. The whole idea is for provider / client to
communicate and negotiate a workable solution. At a glance this reads
as the user needs to adapt to the service that the client is offering
and appease the provider. What's wrong with this picture?

How exactly may I ask does anyone actually offer help to the Reviewers
project whose whole aim it seems is to help all us who cannot write
ebuilds right? By going along with your flow, with neither question nor
comment?  Where is the part about the educators leading the way with
tact and grace? Who is the leader here?

-- 
kind regards

Ian Delaney

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

[hasufell]

On 10/12/2015 06:56 AM, Matt Turner wrote:
> 
> So work with the reviewers to ensure the communication is tactful and 
> graceful.
> 

That would be appreciated. So far, we mostly got people complaining (and
some setting up sieve filters to throw all our mails to trash), but not
people offering help. The latter has a bigger chance of actually having
an impact.

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

[hasufell]

On 10/12/2015 06:44 AM, wraeth wrote:
> 
> 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).
> 

We already have been working on making an internal policy about _how_
and _where_ to review.

https://wiki.gentoo.org/wiki/Project:Reviewers/Internal_policy

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

And another point that I have to make very clear... while we are
certainly trying to find the best suited channel for reviews, the
selection of which one is the best is definitely _not_ about "how do I
minimize public exposure?", but "where is this review relevant?" and
"where does the author of the patch respond to most quickly?".

And frankly, if "public exposure" is a problem for you, then that's
something you have to work on if you like to contribute to FOSS. It's
not personal, it's technical. We will definitely not keep a list of
people who are afraid that a review of their code is posted somewhere
more public (assuming that the ebuild is already GPL-2 or similar and
public). But we'll try to post it where it is relevant and where the
author will respond... if that place is private mail, then so be it, but
again... we'll not keep a list for that around. And it will be a
learning experience for us too to figure out how to approach this best,
including the correct place, the amount of nitpicking and so on. You
cannot expect that everything happens at day 1.

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

[Rich Freeman]

On Sun, Oct 11, 2015 at 11:35 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> 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.

Each commit really should be able to stand on its own all the same.
They should all be able to pass a repoman check.

Otherwise when you do try to use tools like bisect you can get
breakage.  It is really frustrating when you're trying to track down a
change that causes an issue and find a large stretch of commits that
won't even build.

-- 
Rich

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

[grozin]

On Sat, 10 Oct 2015, hasufell wrote:

I am a bit confused how this is a bump to "1.2.16". Is just the commit
message wrong or what happened here?

There was a bump in c473e4fcbe3a17d7bc98d3fa1c19624687774165 afais.

And why was BV_X64_MACOS changed?
Sorry for the confusion. When I did it, I haven't noticed that 1.2.16 was 
already committed to the tree. I've just reversed BV_X64_MACOS to the 
newer version 1.2.11.


Sorry,
Andrey

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

[wraeth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/10/15 15:56, Matt Turner wrote:
> On Sun, Oct 11, 2015 at 9:44 PM, wraeth 
> wrote:
>> 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.

Yes and no. It is part of it (see below) but not the only part.

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

For me personally, no, but see below.

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

That is also part of it - I submit something and expect perhaps a bug
or a ping on IRC; instead I get my submission sent to a public list
with someone telling me what I did wrong.

Now put that in the perspective of someone for whom it's their first
contribution to a major project. What are the chances they'll
contribute a second time? If they new beforehand that it was going to
a public list, then it changes - knowing this, they implicitly (or
explicitly) acknowledge that they're going to publicly critiqued; but
this was a sudden change with arguable comments within these reviews.

Ever had your teacher stand you in front of the class, hold up your
workbook and say "this is wrong"?

> I don't know -- a lot of the value is precisely that -- because
> it's in on gentoo-dev@, everyone reading can learning from others' 
> experiences, whereas if the reviews were in private emails or even 
> public bugzilla most people likely wouldn't see them.

I can understand this sentiment - for a community education project,
having it's input tucked away in some dark corner doesn't benefit
anyone. But having one's contribution unexpectedly published as an
example, good or bad, can be very discouraging; particularly if some
of the comments are preferential or simply wrong (which newer
contributors may not recognise).

Peer review is also a good thing, but again it's something that is
typically entered into with the knowledge that it will be such. If you
asked someone privately for their opinion on something you created and
they proceeded to share it around and get input from everyone else, it
would discourage you from asking that friend again, wouldn't it?

As I've mentioned, I welcome feedback for the improvement it brings
both Gentoo and my own work and I think the concept of the Reviewers
project is a great one; but there is a difference between education
and auditing; and suddenly posting everyone's mistakes, however well
intentioned you are, is certainly more vinegar than honey.

Personally, I like the idea of the "top improvements of the week" as
an aggregate of common possible improvements, or even perhaps an
opt-in participation to have one's code reviewed and published could
work, too - there are a number of ways (and not mutually exclusive
ones) that this could be done, and I look forward to improving my
coding as a result of the project in the future.

Kind Regards;
- -- 
Sam Jorna (wraeth) 
GnuPG Key: B2D9F759
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYbeScACgkQXcRKerLZ91k+5gD+KD468i93dwE7eatHqk2nPbjk
wAFjhuKY2KAnNMh3NvIA+wbeoYAiAHjUot4j9X1mg9mHMEAOGe7qexdwXUvEvR91
=wU4M
-END PGP 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):

> 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've talked to William about this yesterday. And raised two major
points.

Firstly, I think that this paragraph can be interpreted as 64-bit ABI
being an alternative ABI to x86 architecture. This follows the late
trend of treating amd64 as a superset of x86 rather than something
completely new. This also fits ppc64 > ppc, s390x > s390 etc.

Secondly, I think that the ABI standards are more relevant than FHS.
And they clearly state that:

- /lib is for x86 ABI,
- /lib64 is for x86_64,
- /libx32 is for x32.

-- 
Best regards,
Michał Górny



pgp31nrSNVtQT.pgp
Description: OpenPGP digital signature

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

[Patrick Lauer]

On 10/10/15 14:25, hasufell wrote:
> On 10/10/2015 02:24 PM, Fabian Groffen wrote:
>> On 10-10-2015 14:19:44 +0200, hasufell wrote:
 +RDEPEND="
 +  !libressl? ( dev-libs/openssl:0 )
 +  libressl? ( dev-libs/libressl )
 +  sys-libs/zlib
 +  net-libs/http-parser
>>> Please order deps alphabetically (I know I added libressl without
>>> reordering, but that was just to keep the diff as small as possible).
>> Is this a policy 
> It is undocumented policy.
>
>
No it's not.

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

[Jason Zaman]

On Mon, Oct 12, 2015 at 06:56:27AM +0200, Cor Legemaat wrote:
> 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?

So the problem here is the "inherit linux-info xorg-2" line.
The xorg-2 eclass defines few default phase functions which you have
overridden.

If you want to patch the source you should be doing something like this:
src_prepare() {
use debounce && epatch ${FILESDIR}/your-patch

xorg-2_src_prepare # this will call the xorg-2 eclass
#defined phase function to do the rest of the work
}

Alternatively, if you just want to apply that patch, you are probably
better off using epatch_user.
Drop your patch in
/etc/portage/patches/x11-drivers/xf86-input-evdev/your-name.patch
and the eclasses will automatically apply the patch. you do not have to
make your own ebuild just to apply the patch.

This has more info: https://wiki.gentoo.org/wiki//etc/portage/patches

-- Jason