[gentoo-dev] New virtuals for libudev and libgudev

[gentoo-dev] New virtuals for libudev and libgudev

[Rick "Zero_Chaos" Farina]

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

Recently, without discussion as suggested by the dev manual, new
virtuals were added for libudev and libgudev.

These virtuals are different than any virtuals use in gentoo in the
past, and due to this, I fell the discussion step is critical. As such,
I have put a temporary QA mask on these virtuals.

All below information is based on my understanding of what is happening
and why, since these new virtuals were added with no previous
discussion, I can only guess why things were done as they were.

These new virtuals represent a new idea in how to avoid needless subslot
rebuilds.  In this case, it occurs that libudev and libgudev (both part
of the udev package at this time) can (and do) change soname separately.
 This means that it is impossible to perform just needed subslot
rebuilds since the package udev can only have one subslot.

To battle this, virtual/libudev and virtual/libgudev were introduced,
each with the subslot indicating version of their namesake.  In this
way, packages which currently dep on virtual/udev can be adjusted to dep
on one or both of the new virtuals and possibly avoid unneeded subslot
rebuilds.

All in all, this isn't a bad idea on the surface, but the first
arguement shows immediately when this is scaled up.  How many other
packages have multiple libs with different sonames? Off hand, I can
think of poplar, but I'm sure there must be more.  Is it really
scalable, desirable, or sane, to break each package on the system into
multiple different virtuals like this?

Discussion, go.

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

iQIcBAEBAgAGBQJTNe4mAAoJEKXdFCfdEflKDdAP/iZA0CcRY1TW8JYoZwWgkx6q
KaY2jVRMVHDuIRHGv1IRPbhS0vhAxJ9ksX98gkV8fXyXaBrLe4CQbuRR5YhqHKiv
Wlwn4V8yjT3VW+39Km3xUKSCqN+ERphMY1NXnu80Atx0cp6/kXPMPoxsUdvmFW//
0guIWQh7BamJF1T3U1GnuuexhHVnMBdsPPRn9AfpXSmUBUQ0C1E4l74Vkvwa6+7D
+U0a8NDtiha7WreCt4e2luMTfmYUezv5uE5E+b/hZvCf9cg5BaPQMjQyldzqd+c0
kP29GsB6dxZ+BbDDlepvIll36gnAmgiYbipATmUxY9T2YY9dj34aLU/wdHjZJl5G
5NMDnhmkBTxmg5B5t5W+1JagMtFjNqPhayXcHYtU/0cinwWI2fG24rdiSRya30SX
vVXzBUe7wMbYMe/mokjtPBraL1S4nL0Svvoft/qkvojy9hEezNX8caA/NkgEFJWO
c1C920o8jrWB2MI5MnEnjs0DZRLI7MfXW2FOBtymignNjW7NSs/gZj62PM08pzD0
9vEBlw/Yku1s3uGmEYGECWTrZTqiYgMCHI50lw0hAmGF8L3OYO120j4Rybr1cqgV
gmsFcHCGsUXlEyx+uIB1hF59w8vI0GzIDqwSDMtpQ8SlByrgKXd/B7Pzn1RZDMfO
Fu7jIfz700SRT3hmnTDw
=kF//
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Rich Freeman]

On Fri, Mar 28, 2014 at 5:48 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> All in all, this isn't a bad idea on the surface, but the first
> arguement shows immediately when this is scaled up.  How many other
> packages have multiple libs with different sonames? Off hand, I can
> think of poplar, but I'm sure there must be more.  Is it really
> scalable, desirable, or sane, to break each package on the system into
> multiple different virtuals like this?

Clever idea, actually, though I'd be interested in whether anybody
else can think of any unintended consequences.

I agree that there could end up being many cases of this, but that
really just amounts to clutter, and more granular dependencies (which
also make me think that a next step could actually be packages that
only install the necessary libraries, and somehow controlling this by
dependencies rather than USE flags which are a bit more cumbersome).

There really isn't anything special about virtual packages other than
the fact that they don't install anything.  I wonder if it would make
sense to actually create a new category for virtuals that only exist
to express library dependencies.  Functionally it would be no
different, but it would split up the namespace so that we don't have
an additional 193 packages in the virtual category.  Plus, when
looking at ebuilds it will be a bit more clear what each dependency is
actually pulling in.

One thing you didn't mention in your email is the interaction with
conventional virtuals.  The dep string for libudev reads:
RDEPEND="
        || (
                >=sys-fs/udev-208:0/0[${MULTILIB_USEDEP},static-libs?]
                >=sys-apps/systemd-208:0/2[${MULTILIB_USEDEP},static-libs(-)?]
                >=sys-apps/systemd-208:0/1[${MULTILIB_USEDEP},static-libs(-)?]
                >=sys-apps/systemd-208:0/0[${MULTILIB_USEDEP},static-libs(-)?]
                >=sys-fs/eudev-1.3:0/0[${MULTILIB_USEDEP},static-libs?]
        )"

What happens if eudev-209 and udev-209 don't bundle the sane SONAME
for libudev, and thus need different subslots?  The virtual libudev is
versioned 208.

Would it make more sense to version the virtual after the actual
SONAME, and state the dependency in terms of ranges.  That is
libudev-1.0.0 is satisfied by udev-208 through udev-215, and eudev-208
through eudev-216 (with all the headaches of ranged dependencies -
especially since the final version number isn't known when the first
version is introduced)?  So, instead of having many virtual packages
with the same subslot, you'd have one virtual for each subslot, but
which is satisfied by a number of versions of the real package.

These sorts of issues are less of a problem if the virtual doesn't
depend on multiple packages - that is, it isn't a virtual in the
conventional sense at all.  libudev is what might be considered a
compound virtual in that we're overloading two different things in a
single PV.

Part of me wonders if a more elegant solution is some way of
auto-generating library dependencies of some kind - basically
extracting all the libraries from any package that installs them and
creating virtuals matching their SONAMEs.  Really this is just a way
of caching SONAME info (which also allows a package manager to detect
SONAME changes before even starting a build).  I'm not sure that
virtuals are the best way to capture this - it is just a mechanism
that works with EAPI5.

Those are just some of the potential issues/perspectives/etc I could
think of offhand, and none of them are fully thought-out...

Rich

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

You broke the gentoo-x86 by masking these virtuals without the already
converted reverse
dependencies.
Plus I told you to not bother me about this until there is something
broken, or you get
this banned by the PMS, or you get this feature dropped from the PM.

I took the liberty to unbreak the tree for you. Don't ever touch my
packages again unless
they are broken.


On 28/03/14 23:48, Rick "Zero_Chaos" Farina wrote:
> Recently, without discussion as suggested by the dev manual, new
> virtuals were added for libudev and libgudev.
>
> These virtuals are different than any virtuals use in gentoo in the
> past, and due to this, I fell the discussion step is critical. As such,
> I have put a temporary QA mask on these virtuals.
>
> All below information is based on my understanding of what is happening
> and why, since these new virtuals were added with no previous
> discussion, I can only guess why things were done as they were.
>
> These new virtuals represent a new idea in how to avoid needless subslot
> rebuilds.  In this case, it occurs that libudev and libgudev (both part
> of the udev package at this time) can (and do) change soname separately.
>  This means that it is impossible to perform just needed subslot
> rebuilds since the package udev can only have one subslot.
>
> To battle this, virtual/libudev and virtual/libgudev were introduced,
> each with the subslot indicating version of their namesake.  In this
> way, packages which currently dep on virtual/udev can be adjusted to dep
> on one or both of the new virtuals and possibly avoid unneeded subslot
> rebuilds.
>
> All in all, this isn't a bad idea on the surface, but the first
> arguement shows immediately when this is scaled up.  How many other
> packages have multiple libs with different sonames? Off hand, I can
> think of poplar, but I'm sure there must be more.  Is it really
> scalable, desirable, or sane, to break each package on the system into
> multiple different virtuals like this?
>
> Discussion, go.
>
> Thanks,
> Zero
>

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Michał Górny]

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

Dnia 2014-03-28, o godz. 19:53:07
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Fri, Mar 28, 2014 at 5:48 PM, Rick "Zero_Chaos" Farina
> <zerochaos@gentoo.org> wrote:
> > All in all, this isn't a bad idea on the surface, but the first
> > arguement shows immediately when this is scaled up.  How many other
> > packages have multiple libs with different sonames? Off hand, I can
> > think of poplar, but I'm sure there must be more.  Is it really
> > scalable, desirable, or sane, to break each package on the system into
> > multiple different virtuals like this?
> 
> Clever idea, actually, though I'd be interested in whether anybody
> else can think of any unintended consequences.
> 
> I agree that there could end up being many cases of this, but that
> really just amounts to clutter, and more granular dependencies (which
> also make me think that a next step could actually be packages that
> only install the necessary libraries, and somehow controlling this by
> dependencies rather than USE flags which are a bit more cumbersome).

This is the other side of this. People already requested libudev
without whole udev, and this is a way of allowing it in the future.

> There really isn't anything special about virtual packages other than
> the fact that they don't install anything.  I wonder if it would make
> sense to actually create a new category for virtuals that only exist
> to express library dependencies.  Functionally it would be no
> different, but it would split up the namespace so that we don't have
> an additional 193 packages in the virtual category.  Plus, when
> looking at ebuilds it will be a bit more clear what each dependency is
> actually pulling in.

I have already suggested separate category for perl virtuals but been
quieted down at the time. I doubt people really want another category
for virtuals since some of their poor tools rely on 'virtual/'.

> One thing you didn't mention in your email is the interaction with
> conventional virtuals.  The dep string for libudev reads:
> RDEPEND="
>         || (
>                 >=sys-fs/udev-208:0/0[${MULTILIB_USEDEP},static-libs?]
>                 >=sys-apps/systemd-208:0/2[${MULTILIB_USEDEP},static-libs(-)?]
>                 >=sys-apps/systemd-208:0/1[${MULTILIB_USEDEP},static-libs(-)?]
>                 >=sys-apps/systemd-208:0/0[${MULTILIB_USEDEP},static-libs(-)?]
>                 >=sys-fs/eudev-1.3:0/0[${MULTILIB_USEDEP},static-libs?]
>         )"
> 
> What happens if eudev-209 and udev-209 don't bundle the sane SONAME
> for libudev, and thus need different subslots?  The virtual libudev is
> versioned 208.

There's an exact subslot dep in there (:M/N). If either of them changes
SONAME of any of the libraries, the provider subslot is bumped
and the virtual no longer matches it.

The systemd deps are a good example of that. The subslots 0, 1 and 2
correspond to changes in libsystemd.so. Now, if any of SONAMES
in systemd change, it will have subslot 3 and the virtual will no
longer match. If it's libudev or libgudev changing, we'd introduce
a new version (subslot) of the virtual; otherwise, a new revision with
systemd:0/3 added.

In fact, the versions are not even really necessary there.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Anthony G. Basile]

On 03/28/2014 07:53 PM, Rich Freeman wrote:
> On Fri, Mar 28, 2014 at 5:48 PM, Rick "Zero_Chaos" Farina
> <zerochaos@gentoo.org> wrote:
>> All in all, this isn't a bad idea on the surface, but the first
>> arguement shows immediately when this is scaled up.  How many other
>> packages have multiple libs with different sonames? Off hand, I can
>> think of poplar, but I'm sure there must be more.  Is it really
>> scalable, desirable, or sane, to break each package on the system into
>> multiple different virtuals like this?
> Clever idea, actually, though I'd be interested in whether anybody
> else can think of any unintended consequences.
>
My objection to what happened with the introduction of these virtuals 
was that they directly affected eudev and yet the eudev team was not 
consulted.  The question of "unintended consequences" is precisely why 
design decisions should be discussed on this list. The following bug 
shows who was invovled in the discussion: 
https://bugs.gentoo.org/show_bug.cgi?id=506034.  (I just added the eudev 
team but it was not there until just now.)  We now face similar design 
idiosyncrasies with respect to a request that ABI information be 
included in CHOSTs for MIPS which does not conform to gnuconfig 
standards.  To avoid engineering ourselves into corners, we really need 
to have as many smart people looking at a design change as possible 
before it is implemented, not after.

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Rich Freeman]

On Sat, Mar 29, 2014 at 4:34 AM, Michał Górny <mgorny@gentoo.org> wrote:
> I have already suggested separate category for perl virtuals but been
> quieted down at the time. I doubt people really want another category
> for virtuals since some of their poor tools rely on 'virtual/'.

So, first the obvious - the "poor tools" are, well, poor.  If we need
a way of distinguishing virtual packages it might make sense to add a
tag to metadata.xml or such, if not to the ebuilds themselves.
Distinguishing by category/name seems like a really bad idea.

But, second, if people really want to have tools that treat virtuals
in a special way, then it seems likely to me that they'd want to be
able to distinguish between "traditional" virtuals and these new
SONAME-driven virtuals.  Of course, I'd still advocate doing it with a
different tag in metadata.xml/etc and not by doing it with the
category when it is a script doing the interpretation.  For us mere
mortals, having multiple virtual categories might be useful.  I can
see the argument about perl (though I wouldn't have minded a
virtual-perl category), but this is a bit different in that this isn't
just another group of packages being virtualized, but a fairly
different use of virtual packages entirely.

Otherwise, thanks for pointing out the use of subslots in the udev/etc
packages themselves.

Rich

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 29/03/14 14:30, Anthony G. Basile wrote:
> On 03/28/2014 07:53 PM, Rich Freeman wrote:
>> On Fri, Mar 28, 2014 at 5:48 PM, Rick "Zero_Chaos" Farina
>> <zerochaos@gentoo.org> wrote:
>>> All in all, this isn't a bad idea on the surface, but the first
>>> arguement shows immediately when this is scaled up.  How many other
>>> packages have multiple libs with different sonames? Off hand, I can
>>> think of poplar, but I'm sure there must be more.  Is it really
>>> scalable, desirable, or sane, to break each package on the system into
>>> multiple different virtuals like this?
>> Clever idea, actually, though I'd be interested in whether anybody
>> else can think of any unintended consequences.
>>
> My objection to what happened with the introduction of these virtuals
> was that they directly affected eudev and yet the eudev team was not
> consulted.

eudev developer was contacted before any real impact on tree was made to
make an ebuild-only change to build multilib libgudev like udev and systemd
does
at which point any objections could have been raised, instead, like
expected, the version of eudev was provided to move forward, and we did

so I don't agree with your assesment of not being consulted, when you were

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Anthony G. Basile]

On 03/29/2014 08:58 AM, Samuli Suominen wrote:
> On 29/03/14 14:30, Anthony G. Basile wrote:
>> On 03/28/2014 07:53 PM, Rich Freeman wrote:
>>> On Fri, Mar 28, 2014 at 5:48 PM, Rick "Zero_Chaos" Farina
>>> <zerochaos@gentoo.org> wrote:
>>>> All in all, this isn't a bad idea on the surface, but the first
>>>> arguement shows immediately when this is scaled up.  How many other
>>>> packages have multiple libs with different sonames? Off hand, I can
>>>> think of poplar, but I'm sure there must be more.  Is it really
>>>> scalable, desirable, or sane, to break each package on the system into
>>>> multiple different virtuals like this?
>>> Clever idea, actually, though I'd be interested in whether anybody
>>> else can think of any unintended consequences.
>>>
>> My objection to what happened with the introduction of these virtuals
>> was that they directly affected eudev and yet the eudev team was not
>> consulted.
> eudev developer was contacted before any real impact on tree was made to
> make an ebuild-only change to build multilib libgudev like udev and systemd
> does
> at which point any objections could have been raised, instead, like
> expected, the version of eudev was provided to move forward, and we did
>
> so I don't agree with your assesment of not being consulted, when you were
>
Not before the decision was made to go ahead with the change. Consulting 
means input before the decision.

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Anthony G. Basile]

On 03/29/2014 09:23 AM, Anthony G. Basile wrote:
> On 03/29/2014 08:58 AM, Samuli Suominen wrote:
>> On 29/03/14 14:30, Anthony G. Basile wrote:
>>> On 03/28/2014 07:53 PM, Rich Freeman wrote:
>>>> On Fri, Mar 28, 2014 at 5:48 PM, Rick "Zero_Chaos" Farina
>>>> <zerochaos@gentoo.org> wrote:
>>>>> All in all, this isn't a bad idea on the surface, but the first
>>>>> arguement shows immediately when this is scaled up.  How many other
>>>>> packages have multiple libs with different sonames? Off hand, I can
>>>>> think of poplar, but I'm sure there must be more.  Is it really
>>>>> scalable, desirable, or sane, to break each package on the system 
>>>>> into
>>>>> multiple different virtuals like this?
>>>> Clever idea, actually, though I'd be interested in whether anybody
>>>> else can think of any unintended consequences.
>>>>
>>> My objection to what happened with the introduction of these virtuals
>>> was that they directly affected eudev and yet the eudev team was not
>>> consulted.
>> eudev developer was contacted before any real impact on tree was made to
>> make an ebuild-only change to build multilib libgudev like udev and 
>> systemd
>> does
>> at which point any objections could have been raised, instead, like
>> expected, the version of eudev was provided to move forward, and we did
>>
>> so I don't agree with your assesment of not being consulted, when you 
>> were
>>
> Not before the decision was made to go ahead with the change. 
> Consulting means input before the decision.
>
Following up on this, do you have any objection to me co-maintianing 
those virtuals?

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 29/03/14 15:24, Anthony G. Basile wrote:
> On 03/29/2014 09:23 AM, Anthony G. Basile wrote:
>> On 03/29/2014 08:58 AM, Samuli Suominen wrote:
>>> On 29/03/14 14:30, Anthony G. Basile wrote:
>>>> On 03/28/2014 07:53 PM, Rich Freeman wrote:
>>>>> On Fri, Mar 28, 2014 at 5:48 PM, Rick "Zero_Chaos" Farina
>>>>> <zerochaos@gentoo.org> wrote:
>>>>>> All in all, this isn't a bad idea on the surface, but the first
>>>>>> arguement shows immediately when this is scaled up.  How many other
>>>>>> packages have multiple libs with different sonames? Off hand, I can
>>>>>> think of poplar, but I'm sure there must be more.  Is it really
>>>>>> scalable, desirable, or sane, to break each package on the system
>>>>>> into
>>>>>> multiple different virtuals like this?
>>>>> Clever idea, actually, though I'd be interested in whether anybody
>>>>> else can think of any unintended consequences.
>>>>>
>>>> My objection to what happened with the introduction of these virtuals
>>>> was that they directly affected eudev and yet the eudev team was not
>>>> consulted.
>>> eudev developer was contacted before any real impact on tree was
>>> made to
>>> make an ebuild-only change to build multilib libgudev like udev and
>>> systemd
>>> does
>>> at which point any objections could have been raised, instead, like
>>> expected, the version of eudev was provided to move forward, and we did
>>>
>>> so I don't agree with your assesment of not being consulted, when
>>> you were
>>>
>> Not before the decision was made to go ahead with the change.
>> Consulting means input before the decision.
>>
> Following up on this, do you have any objection to me co-maintianing
> those virtuals?
>

With the inappropiate feedback I got from yesterday from you in
#gentoo-dev, I'm not sure you are the best fit
for maintaining any of these.

However, I suppose both of eudev@gentoo.org and systemd@gentoo.org
should still be in metadata.xml of
the virtuals as co-maintainers.

But it doesn't mean you get to do dramatical changes to them without
first discussing it with the main providers
maintainers, that is, sys-fs/udev, and WilliamH and me. Dramatical
changes, such as unannouncedly reverting
others changes, masking them, etc.

I shouldn't even be needing to tell any of this, as common sense should
prevail, but lately it has been lost,
so covering basis. Don't take insult of it.

+1 for adding systemd and eudev to metadata.xml

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Anthony G. Basile]

On 03/29/2014 09:33 AM, Samuli Suominen wrote:
> On 29/03/14 15:24, Anthony G. Basile wrote:
>> On 03/29/2014 09:23 AM, Anthony G. Basile wrote:
>>> On 03/29/2014 08:58 AM, Samuli Suominen wrote:
>>>> On 29/03/14 14:30, Anthony G. Basile wrote:
>>>>> On 03/28/2014 07:53 PM, Rich Freeman wrote:
>>>>>> On Fri, Mar 28, 2014 at 5:48 PM, Rick "Zero_Chaos" Farina
>>>>>> <zerochaos@gentoo.org> wrote:
>>>>>>> All in all, this isn't a bad idea on the surface, but the first
>>>>>>> arguement shows immediately when this is scaled up.  How many other
>>>>>>> packages have multiple libs with different sonames? Off hand, I can
>>>>>>> think of poplar, but I'm sure there must be more.  Is it really
>>>>>>> scalable, desirable, or sane, to break each package on the system
>>>>>>> into
>>>>>>> multiple different virtuals like this?
>>>>>> Clever idea, actually, though I'd be interested in whether anybody
>>>>>> else can think of any unintended consequences.
>>>>>>
>>>>> My objection to what happened with the introduction of these virtuals
>>>>> was that they directly affected eudev and yet the eudev team was not
>>>>> consulted.
>>>> eudev developer was contacted before any real impact on tree was
>>>> made to
>>>> make an ebuild-only change to build multilib libgudev like udev and
>>>> systemd
>>>> does
>>>> at which point any objections could have been raised, instead, like
>>>> expected, the version of eudev was provided to move forward, and we did
>>>>
>>>> so I don't agree with your assesment of not being consulted, when
>>>> you were
>>>>
>>> Not before the decision was made to go ahead with the change.
>>> Consulting means input before the decision.
>>>
>> Following up on this, do you have any objection to me co-maintianing
>> those virtuals?
>>
> With the inappropiate feedback I got from yesterday from you in
> #gentoo-dev, I'm not sure you are the best fit
> for maintaining any of these.

Others have these logs and are better judges of the responses.  Let the 
community read the responses for themselves.

>
> However, I suppose both of eudev@gentoo.org and systemd@gentoo.org
> should still be in metadata.xml of
> the virtuals as co-maintainers.
>
> But it doesn't mean you get to do dramatical changes to them without
> first discussing it with the main providers
> maintainers, that is, sys-fs/udev, and WilliamH and me. Dramatical
> changes, such as unannouncedly reverting
> others changes, masking them, etc.

This implies to the list that I made any changes.  I did not touch or 
mask any of these packages.  In fact, I asked you to please look at the 
eudev ebuilds to make sure they would work with the new virtual structure.

Furthermore, I am in favor of discussion.  You ask of me precisely what 
I ask of you.  It is a good thing that we discuss these changes together.

>
> I shouldn't even be needing to tell any of this, as common sense should
> prevail, but lately it has been lost,
> so covering basis. Don't take insult of it.
>
> +1 for adding systemd and eudev to metadata.xml
>

Again, let the community judge "common sense".  If eudev is added, then 
that means we get to follow these packages as needed.  It is not my 
intention to obstruct what udev and systemd are doing, but to make sure 
that the eudev ebuilds are not marginalized.

As for "main" providers, there are other distributions that are now 
adopting eudev such as Linux From Scratch [1] and Crux is considering it 
[2].


Ref.

[1] 
http://www.linuxfromscratch.org/lfs/view/development/chapter06/eudev.html
[2] http://crux.nu/Wiki/TODO31

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Francisco Blas Izquierdo Riera (klondike)]

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

Hi!

El 29/03/14 05:13, Samuli Suominen escribió:
> I took the liberty to unbreak the tree for you. Don't ever touch my
> packages again unless
> they are broken.
Udev is broken:
* They have known off by one string handling errors on their libraries,
the developers were warned of that but have chosen to ignore the issue.
The issue is still on
http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/strxcpyx.c
on the function size_t strpcpyf(char **dest, size_t size, const char
*src, ...) which can overflow the string boundaries in some case. This
issue keeps coming up from time to time thanks to their "nice" efforts
for cahnging the whole thing instead of fixing bugs. Also after a year
nothing has been done.
* They keep losing cohesion
(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29) by
inserting more and more unrelated software into Udev/systemd. This helps
things like the above happen again.
* They have the bad habit of recoding functions that are already
provided by their only supported c library. This helps things like the
above happen.ç
* They keep reengineering everything reintroducing bugs that were fixed
on previous iterations.

Thus given the potential security issues udev (and systemd) have, the
poor design decissions, and the lack of interest in their maintainers of
fixing these, I'd strongly recommend masking it as was done with packets
like wordpress or at least putting a big warning to the users.


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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 29/03/14 22:27, Francisco Blas Izquierdo Riera (klondike) wrote:
> Hi!
>
> El 29/03/14 05:13, Samuli Suominen escribió:
>> I took the liberty to unbreak the tree for you. Don't ever touch my
>> packages again unless
>> they are broken.
> Udev is broken:
> * They have known off by one string handling errors on their libraries,
> the developers were warned of that but have chosen to ignore the issue.
> The issue is still on
> http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/strxcpyx.c
> on the function size_t strpcpyf(char **dest, size_t size, const char
> *src, ...) which can overflow the string boundaries in some case. This
> issue keeps coming up from time to time thanks to their "nice" efforts
> for cahnging the whole thing instead of fixing bugs. Also after a year
> nothing has been done.
> * They keep losing cohesion
> (http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29) by
> inserting more and more unrelated software into Udev/systemd. This helps
> things like the above happen again.
> * They have the bad habit of recoding functions that are already
> provided by their only supported c library. This helps things like the
> above happen.ç
> * They keep reengineering everything reintroducing bugs that were fixed
> on previous iterations.
>
> Thus given the potential security issues udev (and systemd) have, the
> poor design decissions, and the lack of interest in their maintainers of
> fixing these, I'd strongly recommend masking it as was done with packets
> like wordpress or at least putting a big warning to the users.
>

You are confusing the mailing list with bugzilla.   Enough said.

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Rick "Zero_Chaos" Farina]

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

On 03/29/2014 12:13 AM, Samuli Suominen wrote:
> You broke the gentoo-x86 by masking these virtuals without the already
> converted reverse
> dependencies.
No, I didn't, before accusing people of breaking the tree you may want
to cvs up.

> Plus I told you to not bother me about this until there is something
> broken, or you get
> this banned by the PMS, or you get this feature dropped from the PM.
> 
Your input was considered.

> I took the liberty to unbreak the tree for you. Don't ever touch my
> packages again unless
> they are broken.
You didn't unbreak the tree, you reverted a QA mask without permission.
 A comrel bug was opened for this, I'm sure they won't care at all.

Your input will be considered here with all the weight it deserves.  My
mask was to force this discussion on the list and it has done it's job well.

Thanks,
Zero
> 
> 
> On 28/03/14 23:48, Rick "Zero_Chaos" Farina wrote:
>> Recently, without discussion as suggested by the dev manual, new
>> virtuals were added for libudev and libgudev.
>>
>> These virtuals are different than any virtuals use in gentoo in the
>> past, and due to this, I fell the discussion step is critical. As such,
>> I have put a temporary QA mask on these virtuals.
>>
>> All below information is based on my understanding of what is happening
>> and why, since these new virtuals were added with no previous
>> discussion, I can only guess why things were done as they were.
>>
>> These new virtuals represent a new idea in how to avoid needless subslot
>> rebuilds.  In this case, it occurs that libudev and libgudev (both part
>> of the udev package at this time) can (and do) change soname separately.
>>  This means that it is impossible to perform just needed subslot
>> rebuilds since the package udev can only have one subslot.
>>
>> To battle this, virtual/libudev and virtual/libgudev were introduced,
>> each with the subslot indicating version of their namesake.  In this
>> way, packages which currently dep on virtual/udev can be adjusted to dep
>> on one or both of the new virtuals and possibly avoid unneeded subslot
>> rebuilds.
>>
>> All in all, this isn't a bad idea on the surface, but the first
>> arguement shows immediately when this is scaled up.  How many other
>> packages have multiple libs with different sonames? Off hand, I can
>> think of poplar, but I'm sure there must be more.  Is it really
>> scalable, desirable, or sane, to break each package on the system into
>> multiple different virtuals like this?
>>
>> Discussion, go.
>>
>> Thanks,
>> Zero
>>
> 
> 
> 
> 

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

iQIcBAEBAgAGBQJTOIKAAAoJEKXdFCfdEflKq44QAJUOhKvqrVZKIEm074f6ozZF
0eo5dfAQTjcwdYWDWJQ8sKkc26rnrqQjHzGP/cm19lAQAzMceCIw5gKUNXovKwKi
/Bl8u3oQIbwDqpqRQFs9kGcToLpyMgX8J+YhWg18IcfJvHWpdW5JR7/0Zuw8A+FI
bqkRiXqBVe16uN0iy5JRVwYVcHxTvDCCU/oM+Vpy87+8FPUnzduh8HlY2NoH5nq/
D9TFISaNHkxuhTtVj+OahnHxP/9RkcaI3uZEoCKSEebSWKJ4kxlEoM2D7SBGjQWg
kVcPsAddfVdumoShrQkEPEpS3jSlCKp9MP5MUur6xCPOOom/6XnOFQqO49MN2zjj
udNWLY1c8pjAIwRLk9+CRCvwuiXfHxFh2FCDsf92LZ4D3Vwt2tb1tuXMllfMlmNL
KcUV8GMRBE9Bwb8ovPvHCP78/tphLXr24OjoUhJw4UXa7lbSIVyXqjhTkTtkBWHb
q6cIvmMvPdAkMttLKz+n5sNhYNeC+nR8L8y0uUayPuKGXWWwbvJz5Llfu6DcrrsA
WkHBlywJz7sOwIHFTTHZqp4oijqHwdUCYiTGQ0GPbjQ7JW4HSEK9KX5MV1Jjr8lu
nHdznf4LCLqY8NL56oHgwH0Y6fxlVne5JRW95R1ei5oL4yH5KgFg+fAA4/MH/bRN
racYsCXksRf133Jv6etG
=xzP+
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 30/03/14 23:45, Rick "Zero_Chaos" Farina wrote:
>
> Your input will be considered here with all the weight it deserves.  My
> mask was to force this discussion on the list and it has done it's job
> well.

So, you admit breaking the policy of gentoo-dev being a optional ML
for developers[1]

I really dislike the recent trend of some newer developers trying to force
everything to be discussed here, even if the involved people have already
discussed it elsewhere with relavent people

[1]
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?full=1#book_part1_chap3

"3.h. Mailing lists
All developers must be subscribed to the gentoo-core and
gentoo-dev-announce mailing lists. All developers should be subscribed
to gentoo-dev and gentoo-project,"

*should*, not *must*

Likewise, http://devmanual.gentoo.org/general-concepts/virtuals/index.html

"Before adding a new virtual, it should be discussed on |gentoo-dev|."

*should*, not *must*

You can't change the policies on your own without rest of the QA team,
rest of the council, and so forth.

QA is for enforcing estabilished policies, not making up them as you go
based on your personal likes and dislikes.

Futhermore no productive discussion has happened here as you masqueraded
the use of subslotting you supposedly want to be discussed,
to be somehow udev specific.
But that's not suprising as you yourself admitted you started all of
this only because you saw the word 'udev':

Freenode, #gentoo-qa, at the same time you started this endeavour:

18:19 <@Zero_Chaos> granted, the udev changes sparked this line of thought.

So, congratulations for making the QA team look like a crapshoot once again.

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Rick "Zero_Chaos" Farina]

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

On 03/31/2014 01:50 AM, Samuli Suominen wrote:
> 
> On 30/03/14 23:45, Rick "Zero_Chaos" Farina wrote:
>>
>> Your input will be considered here with all the weight it deserves.  My
>> mask was to force this discussion on the list and it has done it's job
>> well.
> 
> So, you admit breaking the policy of gentoo-dev being a optional ML
> for developers[1]
> 
> I really dislike the recent trend of some newer developers trying to force
> everything to be discussed here, even if the involved people have already
> discussed it elsewhere with relavent people

Given that the eudev maintainers already said these changes were made
without discussing with them, clearly you missed some "relevant" people.

Additionally, it was only after the added attention which I brought that
it was noticed that the udev ebuilds had improper pdepends on the
virtual.  If not for the added eyes and attention who knows when that
would have been caught, likely after stabilization.  You are welcome for
the bug fix.
> 
> [1]
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?full=1#book_part1_chap3
> 
> "3.h. Mailing lists
> All developers must be subscribed to the gentoo-core and
> gentoo-dev-announce mailing lists. All developers should be subscribed
> to gentoo-dev and gentoo-project,"
> 
> *should*, not *must*
> 
> Likewise, http://devmanual.gentoo.org/general-concepts/virtuals/index.html
> 
> "Before adding a new virtual, it should be discussed on |gentoo-dev|."
> 
> *should*, not *must*
> 
> You can't change the policies on your own without rest of the QA team,
> rest of the council, and so forth.

I didn't change the policy, I felt that your change was important enough
that it deserved discussion, especially after bugs were found AND
relevant people were mentioning on irc that they were unhappy about
being left out.
> 
> QA is for enforcing estabilished policies, not making up them as you go
> based on your personal likes and dislikes.
> 
> Futhermore no productive discussion has happened here as you masqueraded
> the use of subslotting you supposedly want to be discussed,
> to be somehow udev specific.

I want the the fact that a single package now has one virtual per lib so
that proper subslot rebuilds can happen to be discussed.  Earlier in
this thread, before you divulged into personal attacks, it was discussed
lightly.  Clearly, no one felt strongly against it, and with this
discussion done, I am happy to be out of your way on this.

> But that's not suprising as you yourself admitted you started all of
> this only because you saw the word 'udev':
> 
> Freenode, #gentoo-qa, at the same time you started this endeavour:
> 
> 18:19 <@Zero_Chaos> granted, the udev changes sparked this line of thought.
> 
I know english isn't everyone's first language, but even completely out
of context this statement doesn't at all mean what you are claiming it
does.  I couldn't possibly care less that this was udev related.  "the
udev changes sparked this line of thought" means that the changes to
udev made me think of how using virtuals in this new way could possibly
be dangerous.  I had previously not noticed the same was suggested (and
shot down) for poplar, so this was a completely new idea which had not
been discussed anywhere I have seen.  Again, now that I brought it to
- -dev (after you refused to do so) and no one else seems to care, I am
out of your way, and I hope it goes as well as you believe it will.

> So, congratulations for making the QA team look like a crapshoot once again.
> 
> 
https://wiki.gentoo.org/wiki/GLEP:48

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

Per GLEP 48 your actions of reverting the QA mask (the first time) was
entirely inappropriate, and your personal attacks on me are even more
so.  While you flaunt the fact that the rules do not apply to you maybe
you should be less concerned with how QA looks and more concerned with
how your behavior makes you look.

We can continue this pointless back and forth for as long as you like,
but honestly, there will be no winner, only two losers.  Let's just wait
for comrel to resolve my complaint against you with no action and move
on with our lives.  I think we both have better things to do, I know I do.

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

iQIcBAEBAgAGBQJTOdGAAAoJEKXdFCfdEflKdEYP/icwMgYxNfaUsqKJNFCznd7N
HvuGxgz0qeobsny51TL+Cr/Mqv+nW1hcGhxHz6X2Ndd19Hr84d3maq7+bEBRrGxG
PNItodqjEgPvcsbiUQ29hEcz63iZXfhBkvDh9tjXSAZNRaKrOPiVLAQG4w9Ys8e3
YKYWrF0z7EDcoPwn5WfrY284xWBd/VmWTIJPLeIZmBrlA36UthJLa5FLOHUlk0vL
/sQfnrH9blzwsDb2vV9PMI2jFLgXffcrad5Od3zz5DWBF7MU7b70gXaExJlcqzjW
lbz7pq/aSaEWzQOK1mz4d6S+Lwl4r2RC0pPeTVCzSAJwLsyNbOC4M/CRx6/ShjR0
Dv7ViNcJbSfNioza9uOPoONlmtFECm2lZhuCcA1jGjTx+4BN6zHpWu06mvf1Slqw
RIuCVLbgUtJIGVPFlBJXvkJ0XIRsociJq1xE7ODsGEpEzFtMtIro0TCvP2iOJARa
Uw8mnGWO7ov/h7ahDMC0A1iiXBP/ZzW14+vo7EsT4Lj1GyWMYRFJkFbCZeOSIw68
2go4fvosmFQdEctAVGWFbH0hWYaWEYxPvpfsPSVAUOz3hMO9Slc+kwUUgXU8aKN1
xj0eUor+QN3EHQ3Zokvlg1nfUBm/yIrXMWvjF6+5WSGqPAs1khoc4Pb/X4cfCaAB
p7te3CfK3mNOytohr8kp
=E4Ui
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 31/03/14 23:35, Rick "Zero_Chaos" Farina wrote:
>
> https://wiki.gentoo.org/wiki/GLEP:48
>
> "In the event that a developer still insists that a package does not
> break QA standards, an appeal can be made at the next council meeting.
> The package should be dealt with per QA's request until such a time that
> a decision is made by the council."

The same GLEP says,

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

While other QA members said masking them at the point you masked them
was already too late for any masking.
Thus, majority is required here and majority is gained by a vote.
You are not the sole authority of QA, which I'm extremely happy of.

>
> We can continue this pointless back and forth for as long as you like,
> but honestly, there will be no winner, only two losers.  Let's just wait
> for comrel to resolve my complaint against you with no action and move
> on with our lives.  I think we both have better things to do, I know I do.
>

You are right, no winners here, which is why I'm leaving this reply
short as per, good advise, from comrel.

- Samuli

Re: [gentoo-dev] New virtuals for libudev and libgudev

[hasufell]

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

Samuli Suominen:
> 
> 
> The same GLEP says,
> 
> "In the case of disagreement among QA members the majority of 
> established QA members must agree with the action. Some examples
> of disagreements are whether the perceived problem violates the
> policy or whether the solution makes the situation worse."
> 
> While other QA members said masking them at the point you masked
> them was already too late for any masking. Thus, majority is
> required here and majority is gained by a vote. You are not the
> sole authority of QA, which I'm extremely happy of.
> 

Seems there is a serious communication or authority problem in QA team
then.

And this is going to get worse if people don't trust them. Currently
it looks more like a loose club, instead of a team with strong
hierarchical structure, which is the only thing that enables a quick
line of action if needed. And that is one of its purposes, afaiu.

I'm not saying this because I find it funny, but because I think it
needs improvement.
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTOq/OXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAg3pkP/2jFbh7zswmwfXS7O1V1aFCN
U3yDAx8UslkynzxCquHtI5gHoor1i1IO9E1ggfdJdZMbls8U6FknlyOU/1ZFkFHT
Gq8LZvQ9jn8uF4mY0vnygosxElYOuZ79Cl1S1wwauWzCz1VRdUZOL+IA57TA+Oj8
j9xT2M8hlYzrKRqMWGLCDXpwOy0uDTXFVossK+06MRM2gMU41lmO4SPFHLDu6MQA
MHpfnmapDf5gqDWCuNNDnj/XA240qNFSGT0Z5Qo2KVoZvrFOVzWYXKAoI5pTKRzL
upicwygQ88CGB+rL7xpfD+AgjRxH31qhSDP1a8+9iNHa+LNn/Jw28ITBbr7t8mjr
UTJ0qtaFZ5jbO2RcyoKV3FkQnUwEcT/4pHrJXydFS2M+2DJX7tXK2H2b+ayXOCpF
YsicGQYfxLQU0Bkn+b+wswcmIqeD/aqv3lNN54N5Faea47AeTr5KfpbQNm5NVLOA
u2MA7qMCyXUhLS/WtHd0bFSBTnZAQoW8Vc2KmuZ5vT6yBwNsu0KOpA/OIPFbRUur
qdTNOpV59ePlgvuMYpvmp03iOhWDx+We9+QbJENO6m2c5/kMpsqdImViJ0253r3d
a0JzmZVF53+oe3Y6x+6aDsh9JVzt7dilpska+REiDOXum+0D2wvcJYGrFcodQTM1
JNobhbbHvXoo37rSg5L4
=+Go7
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Tom Wijsman]

On Tue, 01 Apr 2014 08:48:24 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> The same GLEP says,
> 
> "In the case of disagreement among QA members the majority of
> established QA members must agree with the action. Some examples of
> disagreements are whether the perceived problem violates the policy or
> whether the solution makes the situation worse."
> 
> While other QA members said masking them at the point you masked them
> was already too late for any masking.
> Thus, majority is required here and majority is gained by a vote.
> You are not the sole authority of QA, which I'm extremely happy of.

Majority is, in the GLEP's context, required in the case of disagreement.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Tom Wijsman]

On Tue, 01 Apr 2014 12:23:43 +0000
hasufell <hasufell@gentoo.org> wrote:

> Seems there is a serious communication or authority problem in QA team
> then.

In the weekend, when this came up, there weren't much people around; as
for authority, that appears to be conforming [1] to the GLEP.

 [1] "Majority is required in the case of disagreement."
 http://article.gmane.org/gmane.linux.gentoo.devel/90855
 
> And this is going to get worse if people don't trust them. Currently
> it looks more like a loose club, instead of a team with strong
> hierarchical structure, which is the only thing that enables a quick
> line of action if needed. And that is one of its purposes, afaiu.

There is a strong structure present; for policy enforcement and
breakage prevention, we have the ability to 1) act until there is
disagreement, 2) vote by majority, 3) elevate to deputy and/or lead.

If there is a quick line of action needed, it'll be there; better to be
awesome [2], than to be safe, than to be sorry.

 [2] "How to Stop Sucking and Be Awesome Instead"
 http://blog.codinghorror.com/how-to-stop-sucking-and-be-awesome-instead/

> I'm not saying this because I find it funny, but because I think it
> needs improvement.

What needs improvement is an understanding of what people can('t) do as
well as where communication is preferable to cleaning up or losing time.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 01/04/14 18:28, Tom Wijsman wrote:
> On Tue, 01 Apr 2014 12:23:43 +0000
> hasufell <hasufell@gentoo.org> wrote:
>
>> And this is going to get worse if people don't trust them. Currently
>> it looks more like a loose club, instead of a team with strong
>> hierarchical structure, which is the only thing that enables a quick
>> line of action if needed. And that is one of its purposes, afaiu.
> There is a strong structure present; for policy enforcement and
> breakage prevention, we have the ability to 1) act until there is

And let's be perfectly clear here, nothing was, or is broken. Futher,
no policy was violated, none, whatsoever.
This is an individual, albeit a QA member, disagreeing with a design model.

If joining QA team means you get to dictate, alone, how others do their
work,
even when they are not breaking anything while doing so, without the
rest of the
team, we'd be setting a bad precedence.
The QA membership is not a large trout you get to bash others with when you
feel like it.
Otherwise everyone would be lining up the QA team membership just to protect
their work from others.

- Samuli

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 01/04/14 18:55, Samuli Suominen wrote:
> Otherwise everyone would be lining up the QA team membership just to protect
> their work from others.
*lining up to join (sorry, typing error)

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Tom Wijsman]

On Tue, 01 Apr 2014 18:55:40 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 01/04/14 18:28, Tom Wijsman wrote:
> > On Tue, 01 Apr 2014 12:23:43 +0000
> > hasufell <hasufell@gentoo.org> wrote:
> >
> >> And this is going to get worse if people don't trust them.
> >> Currently it looks more like a loose club, instead of a team with
> >> strong hierarchical structure, which is the only thing that
> >> enables a quick line of action if needed. And that is one of its
> >> purposes, afaiu.
> > There is a strong structure present; for policy enforcement and
> > breakage prevention, we have the ability to 1) act until there is
> 
> And let's be perfectly clear here, nothing was, or is broken.

Or would be; for instance, the PDEPEND. It is usually done in
prevention; see it more as a "what if" and less of a "spank for
breakage", in this case his decision might have been taken too fast.

> Futher, no policy was violated, none, whatsoever.

The "appeal to ..." policy was, but it was a first time event; this
can serve as a reminder how people can respond to such a QA action,
that is to talk to the 1) QA person, 2) QA team and then 3) Council.

> This is an individual, albeit a QA member, disagreeing with a design
> model.

How can we disagree with a design model we didn't know about yet?

> If joining QA team means you get to dictate, alone, how others do
> their work, even when they are not breaking anything while doing so,

That is also a part of quality assurance.

> without the rest of the team, we'd be setting a bad precedence.

Per the GLEP; when there is disagreement, the rest can vote on it;
beyond that, there's also the Council.

> The QA membership is not a large trout you get to bash others with
> when you feel like it.

Of course; but this isn't what is happening, is it?

> Otherwise everyone would be lining up the QA team membership just to
> protect their work from others.

Projects like the Council, ComRel and QA are there to protect Gentoo;
and yes, people are (or should be) lining up to protect Gentoo.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Anthony G. Basile]

On 04/01/2014 11:55 AM, Samuli Suominen wrote:
> On 01/04/14 18:28, Tom Wijsman wrote:
>> On Tue, 01 Apr 2014 12:23:43 +0000
>> hasufell <hasufell@gentoo.org> wrote:
>>
>>> And this is going to get worse if people don't trust them. Currently
>>> it looks more like a loose club, instead of a team with strong
>>> hierarchical structure, which is the only thing that enables a quick
>>> line of action if needed. And that is one of its purposes, afaiu.
>> There is a strong structure present; for policy enforcement and
>> breakage prevention, we have the ability to 1) act until there is
> And let's be perfectly clear here, nothing was, or is broken.

Mar 27 18:07:51 <ssuominen>     i wouldn't mind going for 
=virtual/{udev,libudev,libgudev}-212
Mar 27 18:08:09 <ssuominen>     ...and leaving eudev out... :P

Mar 28 10:10:11 <ulm>   so who will fix the mess resulting from 
virtual/libgudev?
Mar 28 10:10:44 <ulm>   such things should be package masked, instead of 
breaking the tree

Mar 28 10:33:01 <ulm>   blueness: eudev-1.5.3-r1 depends on virtual/udev 
depends on virtual/libgudev depends on >=eudev-9999
Mar 28 10:33:02 <ulm>   ???
Mar 28 10:33:12 <ulm>   that doesn't make any sense

[Aside: At this point i was still trying to make sense of what was going on]

Mar 28 11:24:17 <blueness>      ssuominen, again, can i ask you to 
please take a look at eudev-9999 and see if everything is okay?
Mar 28 11:24:18 <Zero_Chaos>    ssuominen: actually I don't believe 
subslots are supposed to work with virtuals at all, that really wasn't 
considered when subslots was designed.
Mar 28 11:25:04 <ssuominen>     blueness: no changes in cvs...

I have the entire log in case the next emails says stuff was taken out 
of context.

> Futher,
> no policy was violated, none, whatsoever.
> This is an individual, albeit a QA member, disagreeing with a design model.
>
> If joining QA team means you get to dictate, alone, how others do their
> work,
> even when they are not breaking anything while doing so, without the
> rest of the
> team, we'd be setting a bad precedence.
> The QA membership is not a large trout you get to bash others with when you
> feel like it.
> Otherwise everyone would be lining up the QA team membership just to protect
> their work from others.
>
> - Samuli
>


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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 01/04/14 19:38, Tom Wijsman wrote:
> On Tue, 01 Apr 2014 18:55:40 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>
>> Futher, no policy was violated, none, whatsoever.
> The "appeal to ..." policy was, but it was a first time event; this

I don't (completely) agree with that, see below:

> can serve as a reminder how people can respond to such a QA action,
> that is to talk to the 1) QA person, 2) QA team and then 3) Council.

That is what was done, with the members online at #gentoo-qa, where
some of the members did not exactly agree with the act of masking
at the stage we were in.

Still, I see many points where this could have been handled differently,
better,
and I certainly see how you could interpret that bulletin point of the GLEP
differently.

>
>> This is an individual, albeit a QA member, disagreeing with a design
>> model.
> How can we disagree with a design model we didn't know about yet?

I get your point, however, I still believe the related people were
involved by other communication channels.
If use of those other communication channels is so unpreferred over the
mailing list, I believe the QA/council/comrel
whoever is in charge of the policy dictating gentoo-dev being a optional
ML, should review that policy and
make it a mandatory one, if it really is.
It would have certainly made me see things differently right from the
start, that is, what some seem to be after here?
I believe by that, we would have avoided our (you, and me) earlier
"problem" (you know what I'm talking about, no need
to refresh it here.)

>
>> If joining QA team means you get to dictate, alone, how others do
>> their work, even when they are not breaking anything while doing so,
> That is also a part of quality assurance.

I suspect we have a slight language barrier here. If you mean if QA should
be monitoring every commit that goes in to the tree and monitor the tree
as whole,
then you would be right. That's what I do daily basis, and I suspect many
others do as well -- being subscribed to the gentoo-commits ML and informing
others of possible mishaps. You don't need to be part of the QA team for
that.
However, that's not what I meant, by 'dictate how others do their work',
I meant
that one literally, let me demostrate with completely made-up example
from the
on-going multilib thread on the ML where yngwin doesn't agree with the
multilib design
model, if he were a QA member and wanted to revert the tree to a state it
was before the conversions, he'd have powers to do that alone.
Note, I do not leverage the use of subslots in tree to the multilib
issue, at all, and I realize
the example wasn't perfect, but it was the best I could come up with
such short notice.

>
>> without the rest of the team, we'd be setting a bad precedence.
> Per the GLEP; when there is disagreement, the rest can vote on it;
> beyond that, there's also the Council.

I suspect we agree, but have different understanding of 'disagreement'

>
>> The QA membership is not a large trout you get to bash others with
>> when you feel like it.
> Of course; but this isn't what is happening, is it?

Maybe not anymore, but that's certainly what it looked to be earlier.

>
>> Otherwise everyone would be lining up the QA team membership just to
>> protect their work from others.
> Projects like the Council, ComRel and QA are there to protect Gentoo;
> and yes, people are (or should be) lining up to protect Gentoo.
>

You are right, but that's not what I said.

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 01/04/14 20:16, Anthony G. Basile wrote:
> On 04/01/2014 11:55 AM, Samuli Suominen wrote:
>> On 01/04/14 18:28, Tom Wijsman wrote:
>>> On Tue, 01 Apr 2014 12:23:43 +0000
>>> hasufell <hasufell@gentoo.org> wrote:
>>>
>>>> And this is going to get worse if people don't trust them. Currently
>>>> it looks more like a loose club, instead of a team with strong
>>>> hierarchical structure, which is the only thing that enables a quick
>>>> line of action if needed. And that is one of its purposes, afaiu.
>>> There is a strong structure present; for policy enforcement and
>>> breakage prevention, we have the ability to 1) act until there is
>> And let's be perfectly clear here, nothing was, or is broken.
>
> Mar 27 18:07:51 <ssuominen>     i wouldn't mind going for
> =virtual/{udev,libudev,libgudev}-212
> Mar 27 18:08:09 <ssuominen>     ...and leaving eudev out... :P

By "leaving eudev out", I meant it literally, dropping whole eudev from
the old and new virtuals. It was meant
as a bad joke, as I was in one-on-one discussion with the systemd
maintainer.
A joke, nothing more. As you know, I involved *you* before anything like
that was even going to
happen, read below:

>
> Mar 28 10:10:11 <ulm>   so who will fix the mess resulting from
> virtual/libgudev?
> Mar 28 10:10:44 <ulm>   such things should be package masked, instead
> of breaking the tree
>
> Mar 28 10:33:01 <ulm>   blueness: eudev-1.5.3-r1 depends on
> virtual/udev depends on virtual/libgudev depends on >=eudev-9999
> Mar 28 10:33:02 <ulm>   ???
> Mar 28 10:33:12 <ulm>   that doesn't make any sense

At this time, the compability =virtual/udev-208-r2 was not in Portage
yet and nothing depended on those two new virtuals.
So ulm made an observation, that there is an unfinished work in the tree.
And indeed, there was, you know, we handle packages in a monolithic way
in tree, not everything can go in at the same time
like in git.

First, the 2 virtuals were committed to tree, then eudev-1.5.3-r1 was
converted to multilib, then the libgudev was converted for the 1.5.3-r1,
and then the compability virtual was committed to Portage.
So not, at any time, eudev users saw their implementation being replaced
by another by the PM.

>
> [Aside: At this point i was still trying to make sense of what was
> going on]
>
> Mar 28 11:24:17 <blueness>      ssuominen, again, can i ask you to
> please take a look at eudev-9999 and see if everything is okay?
> Mar 28 11:24:18 <Zero_Chaos>    ssuominen: actually I don't believe
> subslots are supposed to work with virtuals at all, that really wasn't
> considered when subslots was designed.
> Mar 28 11:25:04 <ssuominen>     blueness: no changes in cvs...

Here I pointed out that whatever you wanted me to review for 9999, was
not committed yet, so I could review it as per request.
You can't review what you can't see.

>
> I have the entire log in case the next emails says stuff was taken out
> of context.

Yes, completely out of context, but you'd have to post timelines from
the commits as well, for the log to mean anything.
I'm sorry, but you are making a big mistake now, as fun as it would have
been if things would have been as you presented them now.

- Samuli

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 01/04/14 20:46, Anthony G. Basile wrote:
> On 04/01/2014 01:34 PM, Samuli Suominen wrote:
>> So not, at any time, eudev users saw their implementation being replaced
>> by another by the PM.
>
> This is reassuring.  If I can get reassurances that eudev and udev
> will proceed forward on equal footing in the tree then I will feel
> much better about the situation.
>
> Can I get that reassurance from you?
>

Yes, you can.

I did not try to push eudev out from the users systems, or from the
tree, in any backdoored fashion, nor I ever will.

My full intention has always been to inform eudev maintainers if there
will be changes that will require them to take action,
and I believe I did it this time, and have done so, many times before this.

If you believed something like that was going on, I surely understand
where you have been coming from the whole time,
let me just assure you that was not it.

- Samuli

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Anthony G. Basile]

On 04/01/2014 01:34 PM, Samuli Suominen wrote:
> So not, at any time, eudev users saw their implementation being replaced
> by another by the PM.

This is reassuring.  If I can get reassurances that eudev and udev will 
proceed forward on equal footing in the tree then I will feel much 
better about the situation.

Can I get that reassurance from you?

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Rich Freeman]

On Tue, Apr 1, 2014 at 11:28 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> There is a strong structure present; for policy enforcement and
> breakage prevention, we have the ability to 1) act until there is
> disagreement, 2) vote by majority, 3) elevate to deputy and/or lead.

So, rather than making statements of blame at this time, maybe I'll
just focus on general principles.

I'm sure there are opportunities for improvement in QA - there
certainly were when we reconstituted it back in the fall, and it
sounds like there has been progress which is great to hear.  I think
most if not all of us in the Council wanted to let the team recommend
its own policies (subject to Council approval where the GLEP is
concerned).  It would be great if these were posted/explained/etc, to
whatever degree they're complete.

If somebody feels they are the victim of a QA decision, contact
QA/Comrel/Council.  If somebody feels that they are the victim of a
decision being made in the name of QA which isn't really a QA
decision, contact QA/Comrel/Council.  If you just unilaterally
override a decision made in the name of QA, you had better have a
REALLY good reason for it, and I'm talking "QA accidentally introduced
an rm -rf /* command in pkg_postinst on an openrc bump and nobody
responded to my ping."  Making a mistake that is caught by QA is no
big deal - we live and learn.  QA making a mistake is a bigger deal,
but again we can live and learn.

There are probably lessons to be learned here all around, and I'm sure
the Council will be following up on all of them.  However, when there
is disagreement there are right and wrong ways to handle it.  Venting
on the list is understandable, even if we should be mindful of the
CoC.  Venting with "cvs commit" is dangerous - our users trust us to
exercise good judgement with anything that goes into the tree.  Revert
wars are simply unacceptable.

Members of QA/Council/etc are accountable to the developer community
collectively.  None of us get to exercise a personal veto on their
decisions.  If there is abuse, there is a right way to handle it.  If
you disagree with the powers QA is entrusted with, by all means
express this, but you must abide by QA decisions until appealed.
Nobody is going to get "disciplined" for making a mistake, real or
otherwise.

So, take all of that in general, and to the degree that you think it
applies, apply it to yourself.  If you do a particularly poor job of
applying it to yourself somebody in Comrel might do it for you. I
don't know all of what happened, so I won't directly cast blame here -
I don't know what exonerating circumstances might exist or what was
said to who privately in IRC.  However, this whole mess is definitely
going to be on the next Council agenda...

Rich

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Anthony G. Basile]

On 04/01/2014 01:45 PM, Samuli Suominen wrote:
> On 01/04/14 20:46, Anthony G. Basile wrote:
>> On 04/01/2014 01:34 PM, Samuli Suominen wrote:
>>> So not, at any time, eudev users saw their implementation being replaced
>>> by another by the PM.
>> This is reassuring.  If I can get reassurances that eudev and udev
>> will proceed forward on equal footing in the tree then I will feel
>> much better about the situation.
>>
>> Can I get that reassurance from you?
>>
> Yes, you can.
>
> I did not try to push eudev out from the users systems, or from the
> tree, in any backdoored fashion, nor I ever will.
>
> My full intention has always been to inform eudev maintainers if there
> will be changes that will require them to take action,
> and I believe I did it this time, and have done so, many times before this.
>
> If you believed something like that was going on, I surely understand
> where you have been coming from the whole time,
> let me just assure you that was not it.
>
> - Samuli
>
Thank you.  Let's put an end to the bickering.

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Ulrich Mueller]

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

>>>>> On Tue, 01 Apr 2014, Samuli Suominen wrote:

>> Mar 28 10:10:11 <ulm>   so who will fix the mess resulting from
>> virtual/libgudev?
>> Mar 28 10:10:44 <ulm>   such things should be package masked, instead
>> of breaking the tree
>> 
>> Mar 28 10:33:01 <ulm>   blueness: eudev-1.5.3-r1 depends on
>> virtual/udev depends on virtual/libgudev depends on >=eudev-9999
>> Mar 28 10:33:02 <ulm>   ???
>> Mar 28 10:33:12 <ulm>   that doesn't make any sense

> At this time, the compability =virtual/udev-208-r2 was not in
> Portage yet and nothing depended on those two new virtuals.
> So ulm made an observation, that there is an unfinished work in the
> tree. And indeed, there was, you know, we handle packages in a
> monolithic way in tree, not everything can go in at the same time
> like in git.
> First, the 2 virtuals were committed to tree, then eudev-1.5.3-r1
> was converted to multilib, then the libgudev was converted for the
> 1.5.3-r1, and then the compability virtual was committed to Portage.
> So not, at any time, eudev users saw their implementation being
> replaced by another by the PM.

Sorry, but this is not entirely accurate. I have eudev installed on my
system. After syncing, emerge reported blockers and something was
trying to pull in udev. In fact, that was how I noticed the issue, in
the first place.

Latest unstable virtual/udev definitely depended on virtual/libgudev
at that point.

Ulrich

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 01/04/14 21:08, Ulrich Mueller wrote:
>>>>>> On Tue, 01 Apr 2014, Samuli Suominen wrote:
>>> Mar 28 10:10:11 <ulm>   so who will fix the mess resulting from
>>> virtual/libgudev?
>>> Mar 28 10:10:44 <ulm>   such things should be package masked, instead
>>> of breaking the tree
>>>
>>> Mar 28 10:33:01 <ulm>   blueness: eudev-1.5.3-r1 depends on
>>> virtual/udev depends on virtual/libgudev depends on >=eudev-9999
>>> Mar 28 10:33:02 <ulm>   ???
>>> Mar 28 10:33:12 <ulm>   that doesn't make any sense
>> At this time, the compability =virtual/udev-208-r2 was not in
>> Portage yet and nothing depended on those two new virtuals.
>> So ulm made an observation, that there is an unfinished work in the
>> tree. And indeed, there was, you know, we handle packages in a
>> monolithic way in tree, not everything can go in at the same time
>> like in git.
>> First, the 2 virtuals were committed to tree, then eudev-1.5.3-r1
>> was converted to multilib, then the libgudev was converted for the
>> 1.5.3-r1, and then the compability virtual was committed to Portage.
>> So not, at any time, eudev users saw their implementation being
>> replaced by another by the PM.
> Sorry, but this is not entirely accurate. I have eudev installed on my
> system. After syncing, emerge reported blockers and something was
> trying to pull in udev. In fact, that was how I noticed the issue, in
> the first place.
>
> Latest unstable virtual/udev definitely depended on virtual/libgudev
> at that point.
>
>

Are you sure? Then it was an accident, caused by too early commit of the
virtual from mgorny
It couldn't have been more, than few minutes, but mirrors managed to
sync in between?
I surely apologize I didn't communicate it clearly enough to him, that
was not something that was
supposed to be happening at all

But hey, we are all humans, accidents happen, and it was only ~arch, for
one mirror sync :/

- Samuli

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Ulrich Mueller]

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

>>>>> On Tue, 1 Apr 2014, Ulrich Mueller wrote:

>>>>> On Tue, 01 Apr 2014, Samuli Suominen wrote:
>>> Mar 28 10:10:11 <ulm>   so who will fix the mess resulting from
>>> virtual/libgudev?
>>> Mar 28 10:10:44 <ulm>   such things should be package masked, instead
>>> of breaking the tree
>>> 
>>> Mar 28 10:33:01 <ulm>   blueness: eudev-1.5.3-r1 depends on
>>> virtual/udev depends on virtual/libgudev depends on >=eudev-9999
>>> Mar 28 10:33:02 <ulm>   ???
>>> Mar 28 10:33:12 <ulm>   that doesn't make any sense

>> At this time, the compability =virtual/udev-208-r2 was not in
>> Portage yet [...]

It was: udev-208-r2.ebuild committed at Fri Mar 28 11:16:16 2014 UTC.
Above log starts at 14:10 UTC on the same day.

Ulrich

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Tom Wijsman]

On Tue, 01 Apr 2014 20:21:23 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 01/04/14 19:38, Tom Wijsman wrote:
> 
> > can serve as a reminder how people can respond to such a QA action,
> > that is to talk to the 1) QA person, 2) QA team and then 3) Council.
> 
> That is what was done, with the members online at #gentoo-qa, where
> some of the members did not exactly agree with the act of masking
> at the stage we were in.

Which were only ~2 people at the time the mask happened, I was only
contacted by WilliamH whom changed mind; a mail to the alias works much
better, as you reach everyone and it is not lost in a too long backlog.

> Still, I see many points where this could have been handled
> differently, better, and I certainly see how you could interpret that
> bulletin point of the GLEP differently.

Which points? How? The GLEP can be updated to avoid misinterpretations.

> >> This is an individual, albeit a QA member, disagreeing with a
> >> design model.
> > How can we disagree with a design model we didn't know about yet?
> 
> I get your point, however, I still believe the related people were
> involved by other communication channels.
> If use of those other communication channels is so unpreferred over
> the mailing list, I believe the QA/council/comrel
> whoever is in charge of the policy dictating gentoo-dev being a
> optional ML,

It "should" be [1]; it acts as a recommendation, which is stronger than
"optional". While on its own this sentence doesn't mean much and you can
ignore it; it should be noted that quite some changes pass by there, as
well as some decisions on a lower level. In which case people "should"
be aware that if they aren't subscribed that they might miss out on it.

 [1] Gentoo Developer Handbook
 https://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=3#doc_chap8

> should review that policy and make it a mandatory one, if it really
> is. It would have certainly made me see things differently right from
> the start, that is, what some seem to be after here?

The thing we need to do is get more changes and decisions, even if it's
just a digest of the last week, pass by gentoo-dev-announce; earlier in
#gentoo-qa I've mentioned something like that, in which we can summarize
that and additionally highlight eclass, virtual, profiles changes,
meeting decisions, the list goes on...

> I believe by that, we would have avoided our (you, and me) earlier
> "problem" (you know what I'm talking about, no need
> to refresh it here.)

Well, I've asked you several times to bring this up to the general
public; and even in absence of those, also the Gentoo Council. This is
a similar "appeal to ..." approach. The other part of our "problem" is
based on that the "do not touch other maintainer's packages" doesn't
cover how this policy takes into account reverse dependencies changes.

Currently I make an exception for those three packages that were
mentioned; because well, I don't want such a "problem", but rather
have it constructively discussed somewhere in the near or far future.

> >> If joining QA team means you get to dictate, alone, how others do
> >> their work, even when they are not breaking anything while doing
> >> so,
> > That is also a part of quality assurance.
> 
> I suspect we have a slight language barrier here. If you mean if QA
> should be monitoring every commit that goes in to the tree and
> monitor the tree as whole, then you would be right. That's what I do
> daily basis, and I suspect many others do as well -- being subscribed
> to the gentoo-commits ML and informing others of possible mishaps.
> You don't need to be part of the QA team for that.

+1

> However, that's not what I meant, by 'dictate how others do their
> work', I meant that one literally, let me demostrate with completely
> made-up example from the on-going multilib thread on the ML where
> yngwin doesn't agree with the multilib design model, if he were a QA
> member and wanted to revert the tree to a state it was before the
> conversions, he'd have powers to do that alone.

Let's assume that leads to disagreement, his power would stop there;
and if he would revert that large part of a tree, it might have other
consequences for not discussing such large scale changes in advance.

> Note, I do not leverage the use of subslots in tree to the multilib
> issue, at all, and I realize the example wasn't perfect, but it was
> the best I could come up with such short notice.

My above answer translated to the virtual subslots would only apply if
you were to change reverse dependencies (note, our "problem" above)
yourself without discussion and it would lead to breakage; regressions
like these, were people are unaware, aren't well received.

Okay, but this isn't what happened yet; because your plan was to send
out a mail after stabilization for everyone to adapt the reverse
dependencies, and I predict that that in its own would have lead to a
discussion. At which point I think a discussion in advance would be
better than one when you've already started the migration; otherwise,
you might meet resistance halfway in the migration. An unintended
delay; and who knows, perhaps more than that in the form of breakage.

> >> without the rest of the team, we'd be setting a bad precedence.
> > Per the GLEP; when there is disagreement, the rest can vote on it;
> > beyond that, there's also the Council.
> 
> I suspect we agree, but have different understanding of 'disagreement'

(Dis)agreement that is based on reasoning and not on "that way".

> >> The QA membership is not a large trout you get to bash others with
> >> when you feel like it.
> > Of course; but this isn't what is happening, is it?
> 
> Maybe not anymore, but that's certainly what it looked to be earlier.
>
> >> Otherwise everyone would be lining up the QA team membership just
> >> to protect their work from others.
> > Projects like the Council, ComRel and QA are there to protect
> > Gentoo; and yes, people are (or should be) lining up to protect
> > Gentoo.
> >
> 
> You are right, but that's not what I said.

Examples of how things would be in reality are brought up to demonstrate
that what you speak of is hypothetical; in other words, "bashing when
we feel like it" or "protecting our work" hasn't taken place, as it is
done to protect Gentoo. But as said earlier, maybe it is a bit too fast.

That said, I agree with your points in the general way; I just don't see
them as having happened intentionally here, or reflecting what happened.

Anyhow, the later part of this conversation is for ComRel to decide on;
so, let's not go back-and-forth. In response to hasufell, I just wanted
to make clear how relevant parts of QA and appealing work as well as
why things were done the way they are. Apart from its speed...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 01/04/14 21:33, Tom Wijsman wrote:
> Okay, but this isn't what happened yet; because your plan was to send
> out a mail after stabilization for everyone to adapt the reverse
> dependencies, and I predict that that in its own would have lead to a
> discussion.

Exactly.

Re: [gentoo-dev] New virtuals for libudev and libgudev

[hasufell]

Tom Wijsman:
> On Tue, 01 Apr 2014 20:21:23 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
> 
>> On 01/04/14 19:38, Tom Wijsman wrote:
>>
>>> can serve as a reminder how people can respond to such a QA action,
>>> that is to talk to the 1) QA person, 2) QA team and then 3) Council.
>>
>> That is what was done, with the members online at #gentoo-qa, where
>> some of the members did not exactly agree with the act of masking
>> at the stage we were in.
> 
> Which were only ~2 people at the time the mask happened, I was only
> contacted by WilliamH whom changed mind; a mail to the alias works much
> better, as you reach everyone and it is not lost in a too long backlog.
> 
>> Still, I see many points where this could have been handled
>> differently, better, and I certainly see how you could interpret that
>> bulletin point of the GLEP differently.
> 
> Which points? How? The GLEP can be updated to avoid misinterpretations.
> 
>>>> This is an individual, albeit a QA member, disagreeing with a
>>>> design model.
>>> How can we disagree with a design model we didn't know about yet?
>>
>> I get your point, however, I still believe the related people were
>> involved by other communication channels.
>> If use of those other communication channels is so unpreferred over
>> the mailing list, I believe the QA/council/comrel
>> whoever is in charge of the policy dictating gentoo-dev being a
>> optional ML,
> 
> It "should" be [1]; it acts as a recommendation, which is stronger than
> "optional". While on its own this sentence doesn't mean much and you can
> ignore it; it should be noted that quite some changes pass by there, as
> well as some decisions on a lower level. In which case people "should"
> be aware that if they aren't subscribed that they might miss out on it.
> 
>  [1] Gentoo Developer Handbook
>  https://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=3#doc_chap8
> 
>> should review that policy and make it a mandatory one, if it really
>> is. It would have certainly made me see things differently right from
>> the start, that is, what some seem to be after here?
> 
> The thing we need to do is get more changes and decisions, even if it's
> just a digest of the last week, pass by gentoo-dev-announce; earlier in
> #gentoo-qa I've mentioned something like that, in which we can summarize
> that and additionally highlight eclass, virtual, profiles changes,
> meeting decisions, the list goes on...
> 
>> I believe by that, we would have avoided our (you, and me) earlier
>> "problem" (you know what I'm talking about, no need
>> to refresh it here.)
> 
> Well, I've asked you several times to bring this up to the general
> public; and even in absence of those, also the Gentoo Council. This is
> a similar "appeal to ..." approach. The other part of our "problem" is
> based on that the "do not touch other maintainer's packages" doesn't
> cover how this policy takes into account reverse dependencies changes.
> 
> Currently I make an exception for those three packages that were
> mentioned; because well, I don't want such a "problem", but rather
> have it constructively discussed somewhere in the near or far future.
> 
>>>> If joining QA team means you get to dictate, alone, how others do
>>>> their work, even when they are not breaking anything while doing
>>>> so,
>>> That is also a part of quality assurance.
>>
>> I suspect we have a slight language barrier here. If you mean if QA
>> should be monitoring every commit that goes in to the tree and
>> monitor the tree as whole, then you would be right. That's what I do
>> daily basis, and I suspect many others do as well -- being subscribed
>> to the gentoo-commits ML and informing others of possible mishaps.
>> You don't need to be part of the QA team for that.
> 
> +1
> 
>> However, that's not what I meant, by 'dictate how others do their
>> work', I meant that one literally, let me demostrate with completely
>> made-up example from the on-going multilib thread on the ML where
>> yngwin doesn't agree with the multilib design model, if he were a QA
>> member and wanted to revert the tree to a state it was before the
>> conversions, he'd have powers to do that alone.
> 
> Let's assume that leads to disagreement, his power would stop there;
> and if he would revert that large part of a tree, it might have other
> consequences for not discussing such large scale changes in advance.
> 
>> Note, I do not leverage the use of subslots in tree to the multilib
>> issue, at all, and I realize the example wasn't perfect, but it was
>> the best I could come up with such short notice.
> 
> My above answer translated to the virtual subslots would only apply if
> you were to change reverse dependencies (note, our "problem" above)
> yourself without discussion and it would lead to breakage; regressions
> like these, were people are unaware, aren't well received.
> 
> Okay, but this isn't what happened yet; because your plan was to send
> out a mail after stabilization for everyone to adapt the reverse
> dependencies, and I predict that that in its own would have lead to a
> discussion. At which point I think a discussion in advance would be
> better than one when you've already started the migration; otherwise,
> you might meet resistance halfway in the migration. An unintended
> delay; and who knows, perhaps more than that in the form of breakage.
> 
>>>> without the rest of the team, we'd be setting a bad precedence.
>>> Per the GLEP; when there is disagreement, the rest can vote on it;
>>> beyond that, there's also the Council.
>>
>> I suspect we agree, but have different understanding of 'disagreement'
> 
> (Dis)agreement that is based on reasoning and not on "that way".
> 
>>>> The QA membership is not a large trout you get to bash others with
>>>> when you feel like it.
>>> Of course; but this isn't what is happening, is it?
>>
>> Maybe not anymore, but that's certainly what it looked to be earlier.
>>
>>>> Otherwise everyone would be lining up the QA team membership just
>>>> to protect their work from others.
>>> Projects like the Council, ComRel and QA are there to protect
>>> Gentoo; and yes, people are (or should be) lining up to protect
>>> Gentoo.
>>>
>>
>> You are right, but that's not what I said.
> 
> Examples of how things would be in reality are brought up to demonstrate
> that what you speak of is hypothetical; in other words, "bashing when
> we feel like it" or "protecting our work" hasn't taken place, as it is
> done to protect Gentoo. But as said earlier, maybe it is a bit too fast.
> 
> That said, I agree with your points in the general way; I just don't see
> them as having happened intentionally here, or reflecting what happened.
> 
> Anyhow, the later part of this conversation is for ComRel to decide on;
> so, let's not go back-and-forth. In response to hasufell, I just wanted
> to make clear how relevant parts of QA and appealing work as well as
> why things were done the way they are. Apart from its speed...
> 

Tom... I am not sure if you know that, but your posts are difficult to
read. You split up posts horribly and I am often unable to follow what
you mean... at all.

If I am the only one, then it's probably my fault.

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Tom Wijsman]

On Tue, 01 Apr 2014 19:18:44 +0000
hasufell <hasufell@gentoo.org> wrote:

> Tom... I am not sure if you know that, but your posts are difficult to
> read. You split up posts horribly and I am often unable to follow what
> you mean... at all.
> 
> If I am the only one, then it's probably my fault.

When the post responded to is too long, the only way to give a detailed
response is to split it and respond to the individual parts; otherwise
you get a wall of quote and a wall of text, not knowing which details
of the wall of text match with which parts of the wall of quote.

Could it be that your e-mail reader shows quotes in the same color?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[hasufell]

Tom Wijsman:
> 
> Could it be that your e-mail reader shows quotes in the same color?
> 

No.

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Jeroen Roovers]

On Tue, 01 Apr 2014 19:18:44 +0000
hasufell <hasufell@gentoo.org> wrote:

> Tom... I am not sure if you know that, but your posts are difficult to
> read. You split up posts horribly and I am often unable to follow what
> you mean... at all.
> 
> If I am the only one, then it's probably my fault.

It's a good thing you quoted Tom's _entire_ e-mail. I mean, how else
would we have known what you were referring to? It's not like this is a
public mailing l... oh, wait.


     jer

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Matt Turner]

On Tue, Apr 1, 2014 at 9:38 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> Projects like the Council, ComRel and QA are there to protect Gentoo;
> and yes, people are (or should be) lining up to protect Gentoo.

... from QA.

You don't seem to understand what Samuli is saying. QA is being used
as an offensive weapon. It's a stick to bludgeon others with.

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Matt Turner]

On Tue, Apr 1, 2014 at 12:18 PM, hasufell <hasufell@gentoo.org> wrote:
> Tom... I am not sure if you know that, but your posts are difficult to
> read. You split up posts horribly and I am often unable to follow what
> you mean... at all.
>
> If I am the only one, then it's probably my fault.

Definitely not the only one.

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Greg KH]

On Sat, Mar 29, 2014 at 09:27:18PM +0100, Francisco Blas Izquierdo Riera (klondike) wrote:
> Hi!
> 
> El 29/03/14 05:13, Samuli Suominen escribió:
> > I took the liberty to unbreak the tree for you. Don't ever touch my
> > packages again unless
> > they are broken.
> Udev is broken:
> * They have known off by one string handling errors on their libraries,
> the developers were warned of that but have chosen to ignore the issue.
> The issue is still on
> http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/strxcpyx.c
> on the function size_t strpcpyf(char **dest, size_t size, const char
> *src, ...) which can overflow the string boundaries in some case. This
> issue keeps coming up from time to time thanks to their "nice" efforts
> for cahnging the whole thing instead of fixing bugs. Also after a year
> nothing has been done.

I must have missed it, where was this reported?

And where is the off-by-one issue here?  What am I missing in the code?

> * They keep losing cohesion
> (http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29) by
> inserting more and more unrelated software into Udev/systemd. This helps
> things like the above happen again.

That has nothing to do with a logic bug.

> * They have the bad habit of recoding functions that are already
> provided by their only supported c library. This helps things like the
> above happen.ç

Where are these functions in glibc that should have been used instead?

greg k-h

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 02/04/14 05:02, Matt Turner wrote:
> On Tue, Apr 1, 2014 at 9:38 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
>> Projects like the Council, ComRel and QA are there to protect Gentoo;
>> and yes, people are (or should be) lining up to protect Gentoo.
> ... from QA.
>
> You don't seem to understand what Samuli is saying. QA is being used
> as an offensive weapon. It's a stick to bludgeon others with.
>

Exactly.

Anyone remembers what happened the last time this was tried?

The "QA" attempted to force developers who didn't care if removed
ebuilds are recorded in the ChangeLog or
not, even while there was no policy in place that said they should be
recorded there, and nothing was ever broken.
People simply had different workflows.

The whole existing team died with that debacle. I don't expect it to go
exactly like that, this time, as the issue and
people involved are different, but the point is, nothing good came out
of it.
If the people who insisted they should be recorded there had been in a
productive fashion drive repoman to be
patched for --echangelog, or discuss other solutions, we could have
skipped the useless mudslinging.

Force is not hardly ever the correct answer. It might work in a
workplace, but not when people are contributing
for free.

- Samuli

[OT] Re: [gentoo-dev] New virtuals for libudev and libgudev

[Tom Wijsman]

On Tue, 1 Apr 2014 19:47:07 -0700
Matt Turner <mattst88@gentoo.org> wrote:

> On Tue, Apr 1, 2014 at 12:18 PM, hasufell <hasufell@gentoo.org> wrote:
> > Tom... I am not sure if you know that, but your posts are difficult
> > to read. You split up posts horribly and I am often unable to
> > follow what you mean... at all.
> >
> > If I am the only one, then it's probably my fault.
> 
> Definitely not the only one.

To me, it's easier to read than having to scroll down to the end; only
to figure out someone might have been top posting and scroll up again.

You see similar effects happen in exams; some teachers write all the
questions at once and expect students to answer them at the end, other
teachers write the questions one-by-one and leave room in between the
question to answer. Each approach with its own (dis)advantages.

Besides that, some e-mail clients can hide quotes down a certain level.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Tom Wijsman]

On Tue, 1 Apr 2014 19:02:08 -0700
Matt Turner <mattst88@gentoo.org> wrote:

> On Tue, Apr 1, 2014 at 9:38 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> You don't seem to understand what Samuli is saying. QA is being used
> as an offensive weapon. It's a stick to bludgeon others with.

Yes, I understood; but I don't see how that describes a temporary mask
that has been put there as a protective measure by an QA individual.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Tom Wijsman]

On Wed, 02 Apr 2014 09:00:19 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> 
> On 02/04/14 05:02, Matt Turner wrote:
> > You don't seem to understand what Samuli is saying. QA is being used
> > as an offensive weapon. It's a stick to bludgeon others with.
> 
> Exactly. Anyone remembers what happened the last time this was tried?
> 
> [...]

What does the previous QA team's actions have to do with this topic?

> Force is not hardly ever the correct answer. It might work in a
> workplace, but not when people are contributing for free.

In the workplace; people say "no", stand up and leave the room.

Where we are; that's no different, some people are sitting on the
edge of their chair considering to give up trying to be convinced.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 02/04/14 11:28, Tom Wijsman wrote:
> On Wed, 02 Apr 2014 09:00:19 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>
>> On 02/04/14 05:02, Matt Turner wrote:
>>> You don't seem to understand what Samuli is saying. QA is being used
>>> as an offensive weapon. It's a stick to bludgeon others with.
>> Exactly. Anyone remembers what happened the last time this was tried?
>>
>> [...]
> What does the previous QA team's actions have to do with this topic?

It's the previous QA team's actions and mistakes we can learn from.
You know, to avoid repeating them.

>
>> Force is not hardly ever the correct answer. It might work in a
>> workplace, but not when people are contributing for free.
> In the workplace; people say "no", stand up and leave the room.

That's reality only for small percentage of working people.
The majority will do as they are told, and don't even consider saying
"no" as that
would risk their job, and thus, salary, and the way you pay your
mortgage, your house,
and feed your family.

- Samuli

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Tom Wijsman]

On Wed, 02 Apr 2014 11:29:28 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 02/04/14 11:28, Tom Wijsman wrote:
> > On Wed, 02 Apr 2014 09:00:19 +0300
> > Samuli Suominen <ssuominen@gentoo.org> wrote:
> >
> >> On 02/04/14 05:02, Matt Turner wrote:
> >>> You don't seem to understand what Samuli is saying. QA is being
> >>> used as an offensive weapon. It's a stick to bludgeon others with.
> >> Exactly. Anyone remembers what happened the last time this was
> >> tried?
> >>
> >> [...]
> > What does the previous QA team's actions have to do with this topic?
> 
> It's the previous QA team's actions and mistakes we can learn from.
> You know, to avoid repeating them.

Indeed; though, to avoid repeating them we need knowledge codification,
random mentions in one or another thread in an optional ML won't stick.

The knowledge codification is already there, GLEP 48 covers this; in
particular, "The QA team will also do their best to ensure all
developer tools are in line with the current QA standards." applies.

> >> Force is not hardly ever the correct answer. It might work in a
> >> workplace, but not when people are contributing for free.
> > In the workplace; people say "no", stand up and leave the room.
> 
> That's reality only for small percentage of working people.
> The majority will do as they are told, and don't even consider saying
> "no" as that
> would risk their job, and thus, salary, and the way you pay your
> mortgage, your house,
> and feed your family.

If you say "yes" too often, you'll make a lot of deals that are in your
disfavor; up to the point that the same would happen due to bankruptcy.

And that's why people sometimes go sit on the edge of their chair...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Andreas K. Huettel]

Am Mittwoch, 2. April 2014, 10:29:28 schrieb Samuli Suominen:
> On 02/04/14 11:28, Tom Wijsman wrote:
> > On Wed, 02 Apr 2014 09:00:19 +0300
> > 
> > Samuli Suominen <ssuominen@gentoo.org> wrote:
> >> On 02/04/14 05:02, Matt Turner wrote:
> >>> You don't seem to understand what Samuli is saying. QA is being used
> >>> as an offensive weapon. It's a stick to bludgeon others with.
> >> 
> >> Exactly. Anyone remembers what happened the last time this was tried?
> >> 
> >> [...]
> > 
> > What does the previous QA team's actions have to do with this topic?
> 
> It's the previous QA team's actions and mistakes we can learn from.
> You know, to avoid repeating them.
> 

Correct me if I'm wrong, but weren't you one of these QA team members, Samuli?

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

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 02/04/14 13:45, Andreas K. Huettel wrote:
> Am Mittwoch, 2. April 2014, 10:29:28 schrieb Samuli Suominen:
>> On 02/04/14 11:28, Tom Wijsman wrote:
>>> On Wed, 02 Apr 2014 09:00:19 +0300
>>>
>>> Samuli Suominen <ssuominen@gentoo.org> wrote:
>>>> On 02/04/14 05:02, Matt Turner wrote:
>>>>> You don't seem to understand what Samuli is saying. QA is being used
>>>>> as an offensive weapon. It's a stick to bludgeon others with.
>>>> Exactly. Anyone remembers what happened the last time this was tried?
>>>>
>>>> [...]
>>> What does the previous QA team's actions have to do with this topic?
>> It's the previous QA team's actions and mistakes we can learn from.
>> You know, to avoid repeating them.
>>
> Correct me if I'm wrong, but weren't you one of these QA team members, Samuli?
>

Yes, the situation was different in a sense that QA members themself
disagreed back then,
which lead to the back then lead removing members (not only me) without
even notifying them
from the membership list.
So, I have pretty good insight how bad things could go...

- Samuli

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Rick "Zero_Chaos" Farina]

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

On 04/01/2014 11:55 AM, Samuli Suominen wrote:
> 
> On 01/04/14 18:28, Tom Wijsman wrote:
>> On Tue, 01 Apr 2014 12:23:43 +0000
>> hasufell <hasufell@gentoo.org> wrote:
>>
>>> And this is going to get worse if people don't trust them. Currently
>>> it looks more like a loose club, instead of a team with strong
>>> hierarchical structure, which is the only thing that enables a quick
>>> line of action if needed. And that is one of its purposes, afaiu.
>> There is a strong structure present; for policy enforcement and
>> breakage prevention, we have the ability to 1) act until there is
> 
> And let's be perfectly clear here, nothing was, or is broken. Futher,
> no policy was violated, none, whatsoever.
> This is an individual, albeit a QA member, disagreeing with a design model.
> 
> If joining QA team means you get to dictate, alone, how others do their
> work,
> even when they are not breaking anything while doing so, without the
> rest of the
> team, we'd be setting a bad precedence.
> The QA membership is not a large trout you get to bash others with when you
> feel like it.
> Otherwise everyone would be lining up the QA team membership just to protect
> their work from others.
> 
Good one, 10 hours and 7 minutes of taking the good advice of comrel,
then right back at it.  I'm honestly a little impressed you made it that
long.

- -Zero
> - Samuli
> 
> 

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

iQIcBAEBAgAGBQJTPGubAAoJEKXdFCfdEflK/XcP/RYca+zxRMqjjJOUrW3VNkRn
lrfpRFdtPtxmoS4oU45TKwYNQRctJeARW+cBrr7yfKoge0v514FPwxg2GYQY1LuO
x6nVS9UW7N6X2ytZGBAX07kLOqAD1xVAxUccSyQxuibOJO6RcdHOwHNGDdplQiIQ
sLXc9xISNHlw4LsuonZdryGIV5abiOOa4sl3hfO5NPFblc+RixmsjN6VQjTYc/xY
GyPYuTuMTWtRMfSeiqQQFFGA80XhKHuQ0CSMiSbnO88OQqQUTDV/Sn2rBRJPGnF2
3xscRztudUOG97fJe4EnHzcVjI99sRn1GnWMrYFdvw6NJCo+VbRfYp9Jw4MZ60ZN
AcbnqvDLXjOHNPrQHOrCUlToXsc/Eqrhum3o4Jlh/XgPA4ObZz0B2tCamABrTaJv
WGlWcHc5pB54Ll8oQej2eM9rOTm3A4Af/N1CDRf5U0PCgDFw4Xb0Y1KEkdqKM0RD
4hbH4TnnuLdoJYfKwvpE3Cb0NqQcqdGTFhxyP5hsLH1+P7ppz1c0NfIdWfAou9EN
9kWsiyQARTdiBPTN6E7aoFeQPyDv1xqcaMUvjrvhjtzb9TKjjCJqLmmE8O4YdVpt
ENukW7ibtplbfQk8GALvXlfckJ1Gs871GJd1OgPlj6xnj8p5CLfGvLtc0/MppIDF
2ufWg5NdU43wm1inflgj
=wJH8
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Rick "Zero_Chaos" Farina]

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

On 04/01/2014 02:41 PM, Samuli Suominen wrote:
> 
> On 01/04/14 21:33, Tom Wijsman wrote:
>> Okay, but this isn't what happened yet; because your plan was to send
>> out a mail after stabilization for everyone to adapt the reverse
>> dependencies, and I predict that that in its own would have lead to a
>> discussion.
> 
> Exactly.
> 
> 
Discussion happens BEFORE a change.  To stabilize something, and adjust
rdeps all on your own and then "announcing" the changes is ramming a
change down people's throat with now room for negotiation... that sounds
vaguely similar to the kind of "abuse of power" you are accusing me of.

This issue clearly isn't limited to udev, and sadly, until developers
show each other some more respect, I don't see how this ends well.
Making large changes to the tree and "announcing" them shows a complete
lack of respect for the developer community, and I can't believe I'm the
only one who feels that way.

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

iQIcBAEBAgAGBQJTPGz2AAoJEKXdFCfdEflKalgP/R8WlYTvlqXaaYzk0MMiXaJa
QWBIaFka/AlYrOgTd0ktK0zow8x/cchD731cJ9qrtycUseB7M7c0sVM5Yc1FsfcY
G8653AxaS2A6mIxB5zBQIm3BS97ze7GQjqN+o9XMhGC1hCt2KdJ0Fhz9EUQJhgTi
mW1C7gYsB9T8fzo5nYJP8vn2+mTwGmz7TARNK2auCwlFsiT8VoapgaD86C4XXEO7
9gc2C209zipJTVEghXNlrzyzu8Wt60rXuN+Yce2rEOretJKkUxBT60R5aFOB9+/O
hRXn4scYn1etB3hV7NeWF+Hjxf9T16ixBsrY0qz5raHz68KZ6PVLyvyca6TGtDZW
KMlbwq5rHOr5zWgBi53ET3Xra2FeJyiOguQfBf3TivWmgXeoBldeb8aucNhjrDm8
6tjf2226uBXlE64em/p7wZ6dL6hbNMEUa1YmzMpXxjAhG1qafOrL+Wapq/iYilMc
0lJ7i2ZCXwaNaReGZV5T8wo0nI/iFXrcjlpqlXPmvfw4V4nd+Puobit/gie9pOio
JxNigQUtwu2BlxF/aJjE/1TCEbcNuTt8ZhvWO8Rp0X+mWEtUZBAxrqopSvY/eIM/
gnDvk9oyAKtYKR74fivI7pKIJyy/e7VkC+TQHEdQtJEz6EYSSSWiCI1WoZfDSEKS
NlkOIKUdq3fYCC9UQwR8
=tFuX
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Rick "Zero_Chaos" Farina]

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

On 04/02/2014 02:00 AM, Samuli Suominen wrote:
> 
> On 02/04/14 05:02, Matt Turner wrote:
>> On Tue, Apr 1, 2014 at 9:38 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
>>> Projects like the Council, ComRel and QA are there to protect Gentoo;
>>> and yes, people are (or should be) lining up to protect Gentoo.
>> ... from QA.
>>
>> You don't seem to understand what Samuli is saying. QA is being used
>> as an offensive weapon. It's a stick to bludgeon others with.
>>
> 
> Exactly.
> 
> Anyone remembers what happened the last time this was tried?
> 
> The "QA" attempted to force developers who didn't care if removed
> ebuilds are recorded in the ChangeLog or
> not, even while there was no policy in place that said they should be
> recorded there, and nothing was ever broken.
> People simply had different workflows.
> 
> The whole existing team died with that debacle. I don't expect it to go
> exactly like that, this time, as the issue and
> people involved are different, but the point is, nothing good came out
> of it.
> If the people who insisted they should be recorded there had been in a
> productive fashion drive repoman to be
> patched for --echangelog, or discuss other solutions, we could have
> skipped the useless mudslinging.
> 
> Force is not hardly ever the correct answer. It might work in a
> workplace, but not when people are contributing
> for free.
> 
So forcing changes into the tree by stabilizing a bunch of new virtuals
and adjusting all the rdeps to use them is fine, but forcing discussion
is completely inappropriate?

Wow, now that I can see it your way I agree, I'm a horrible person.
I'll stick to randomly changing the tree as I see fit with no discussion
since forced discussion is so wrong.

- -Zero

> - Samuli
> 
> 

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

iQIcBAEBAgAGBQJTPG34AAoJEKXdFCfdEflKYpUP/1ULS1KEdi2756pxr5Ay8k/G
NZJ4LKfXzlAbVOlbhf3splq5NvWEDrItlexXp2rt2QhGUQoNl+4p5gtwPp9j9QBW
8h2OKpveeIF3mxvUnnOyapbeA9PBVoSd5cnRyvATv1g7QqvtFps0+5D61Pl/F9ii
PYVbVuWt/FD4kCmNDCNVuwBt9ZR0eBk70cy482JNzJuH9TTFh/c3kU0PqA2CTkNy
VVGX62/dWPLjKrJjKLaiRaVEtN7DDFC5yKJJn0wxa2TSg5SvwzZVlotcOE/DTwJv
qu0tkBnoPiMnWIV5OWxTBPIOXGRKRXUD6zB3YzPdBISyHGMFsa2KDaDy4/DxsQPX
brRg3Rr7D3l/vApFezYyTIC/SGmpGes4muZpI64WlMJf0LciUjocEJSqdxO3SMzo
0umuNi5FymPHnNrRjZV6MEQ6ft1J8QS1r6OPlKefzYV808D/hPV66F15m4CtvraQ
DvTWCIAMtKpiLwuvCYSy77u//cLX3F+iLep7U6ciDXRTS7ccLLIW2dZV3C8e8aCA
2fvefbd90AzWG3YByNxMSNvE9GsgKyCWfNe9ndnlpE3Wra/4ROy+dV1MdpOTbfmW
595yRKSlLxqtg4cBFy9kaaHr5fQG+YA0QisnR2Z894VMwYt2+HGa55raGnCJw+Zv
oEguJmsrxTKkLOXliLma
=rTHl
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Rich Freeman]

(picking this email to reply to, but it isn't mean to single anybody out)

On Wed, Apr 2, 2014 at 4:07 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> Wow, now that I can see it your way I agree, I'm a horrible person.
> I'll stick to randomly changing the tree as I see fit with no discussion
> since forced discussion is so wrong.

This kind of bickering isn't going to solve anything.  Unfortunately
somebody is going to have to let somebody else have the last word...

The situation is apparently with Comrel and they can deal with the
specifics.  Issues involving specific people are rarely best handled
on public lists.

Clarifying some of the policies involved is already on the radar of
the Council and QA, and I expect there to be progress on both fronts.

I don't want to rehash everything else again, so...

Rich

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 02/04/14 23:07, Rick "Zero_Chaos" Farina wrote:
> On 04/02/2014 02:00 AM, Samuli Suominen wrote:
>
> > On 02/04/14 05:02, Matt Turner wrote:
> >> On Tue, Apr 1, 2014 at 9:38 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> >>> Projects like the Council, ComRel and QA are there to protect Gentoo;
> >>> and yes, people are (or should be) lining up to protect Gentoo.
> >> ... from QA.
> >>
> >> You don't seem to understand what Samuli is saying. QA is being used
> >> as an offensive weapon. It's a stick to bludgeon others with.
> >>
>
> > Exactly.
>
> > Anyone remembers what happened the last time this was tried?
>
> > The "QA" attempted to force developers who didn't care if removed
> > ebuilds are recorded in the ChangeLog or
> > not, even while there was no policy in place that said they should be
> > recorded there, and nothing was ever broken.
> > People simply had different workflows.
>
> > The whole existing team died with that debacle. I don't expect it to go
> > exactly like that, this time, as the issue and
> > people involved are different, but the point is, nothing good came out
> > of it.
> > If the people who insisted they should be recorded there had been in a
> > productive fashion drive repoman to be
> > patched for --echangelog, or discuss other solutions, we could have
> > skipped the useless mudslinging.
>
> > Force is not hardly ever the correct answer. It might work in a
> > workplace, but not when people are contributing
> > for free.
>
> So forcing changes into the tree by stabilizing a bunch of new virtuals
> and adjusting all the rdeps to use them is fine, but forcing discussion
> is completely inappropriate?
>
> Wow, now that I can see it your way I agree, I'm a horrible person.
> I'll stick to randomly changing the tree as I see fit with no discussion
> since forced discussion is so wrong.

I've been constantly maintaining this has been discussed many times
earlier, and it
was in fact part of what council voted upon when they agreed subslot use
in gentoo-x86
What you tried to do, is force me to open a new thread about it, and I
told you,
you should be opening the thread yourself if you see the discussion
being useful,
because I didn't.

Part of the discussion done in #gentoo-dev, from yesterday:

20:51 <@_AxS_> Zero_Chaos: ping, re subslots and virtuals
20:53 <@_AxS_> Zero_Chaos: before EAPI5, I did a fair bit of testing
with virtuals and subslots, specifically in this case to manage the
split-up between the
three ABIs in xorg-server.  It works fine, the way it's being used by
lib{,g}udev.  Where it doesn't work is in the general case -- when
RDEPEND in
a virtual/* package depends on other libs without specific subslot or
version info, and those other libs bump subslot, then this doesn't
propagate
through to the rdeps of the virtual.
20:55 <@_AxS_> So long as the maintainers of a virtual's deps want to
bump the virtual and ensure its RDEPEND is explicitly linked to the
dep's subslot, this'll
work fine.  It's just a lot of work to do that, is all.
21:11 <@ssuominen> _AxS_: Didn't you blog about the virtuals and
subslots? I remember someone did, and I remember what's where I picked
up the whole idea in the first place.
21:12 <@_AxS_> ssuominen: the subslot section of the wiki, iirc, yes
21:13 <@_AxS_> Also mentioned it in here a few times over, a year or
more ago
21:13 <@ssuominen> There we go then, and the link to the wiki...? was
posted in the threads when the subslots were introduced
21:14 <@ssuominen> Just saying, I've consistently maintained this was
not some new idea, and part of my reasoning was that it was talked
about, and I considered
that part of the subslot use to be part of what council agreed on, when
they allowed the subslots in gentoo-x86
21:17 <@_AxS_> ssuominen: i'm with you on that..  The one thing I don't
follow with this thread is that virtual/lib*udev is still a proper
virtual -- that is,
it's providing choice between multiple packages.  it's not like it's
-only there- to represent the elements of a single package.

See, http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators#Use_Virtuals

Also, I don't think you are a horrible person, and I can surely put this
all past us, but can you?

- Samuli