Re: [gentoo-dev] New virtuals for libudev and libgudev
On 02/04/14 05:02, Matt Turner wrote: On Tue, Apr 1, 2014 at 9:38 AM, Tom Wijsman tom...@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
On Tue, 1 Apr 2014 19:47:07 -0700 Matt Turner matts...@gentoo.org wrote: On Tue, Apr 1, 2014 at 12:18 PM, hasufell hasuf...@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 : tom...@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
On Tue, 1 Apr 2014 19:02:08 -0700 Matt Turner matts...@gentoo.org wrote: On Tue, Apr 1, 2014 at 9:38 AM, Tom Wijsman tom...@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 : tom...@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
On Wed, 02 Apr 2014 09:00:19 +0300 Samuli Suominen ssuomi...@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 : tom...@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
On 02/04/14 11:28, Tom Wijsman wrote: On Wed, 02 Apr 2014 09:00:19 +0300 Samuli Suominen ssuomi...@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
On Wed, 02 Apr 2014 11:29:28 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 02/04/14 11:28, Tom Wijsman wrote: On Wed, 02 Apr 2014 09:00:19 +0300 Samuli Suominen ssuomi...@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 : tom...@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
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 ssuomi...@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) dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] New virtuals for libudev and libgudev
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 ssuomi...@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
-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 + hasufell hasuf...@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
-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
-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 tom...@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
(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 zeroch...@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
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 tom...@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
Re: [gentoo-dev] New virtuals for libudev and libgudev
-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/OXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w 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
On Tue, 01 Apr 2014 08:48:24 +0300 Samuli Suominen ssuomi...@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 : tom...@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
On Tue, 01 Apr 2014 12:23:43 +
hasufell hasuf...@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 : tom...@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
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
On 01/04/14 18:28, Tom Wijsman wrote: On Tue, 01 Apr 2014 12:23:43 + hasufell hasuf...@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
On Tue, 01 Apr 2014 18:55:40 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 01/04/14 18:28, Tom Wijsman wrote: On Tue, 01 Apr 2014 12:23:43 + hasufell hasuf...@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 : tom...@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
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 +
hasufell hasuf...@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-
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- and see if everything is okay?
Mar 28 11:24:18 Zero_Chaosssuominen: 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: bluen...@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
On 01/04/14 19:38, Tom Wijsman wrote: On Tue, 01 Apr 2014 18:55:40 +0300 Samuli Suominen ssuomi...@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
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 +
hasufell hasuf...@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-
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- and see if everything is okay?
Mar 28 11:24:18 Zero_Chaosssuominen: 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 , 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
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: bluen...@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
On Tue, Apr 1, 2014 at 11:28 AM, Tom Wijsman tom...@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
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
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: bluen...@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
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- 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
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- 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 pgpqFQ4lq6ipo.pgp Description: PGP signature
Re: [gentoo-dev] New virtuals for libudev and libgudev
On Tue, 01 Apr 2014 20:21:23 +0300 Samuli Suominen ssuomi...@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=1chap=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
Re: [gentoo-dev] New virtuals for libudev and libgudev
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
Tom Wijsman: On Tue, 01 Apr 2014 20:21:23 +0300 Samuli Suominen ssuomi...@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=1chap=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
Re: [gentoo-dev] New virtuals for libudev and libgudev
On Tue, 01 Apr 2014 19:18:44 + hasufell hasuf...@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 : tom...@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: Could it be that your e-mail reader shows quotes in the same color? No.
Re: [gentoo-dev] New virtuals for libudev and libgudev
On Tue, 01 Apr 2014 19:18:44 + hasufell hasuf...@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
On Tue, Apr 1, 2014 at 9:38 AM, Tom Wijsman tom...@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
On Tue, Apr 1, 2014 at 12:18 PM, hasufell hasuf...@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
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
-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
Re: [gentoo-dev] New virtuals for libudev and libgudev
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
-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
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
Dnia 2014-03-28, o godz. 19:53:07
Rich Freeman ri...@gentoo.org napisał(a):
On Fri, Mar 28, 2014 at 5:48 PM, Rick Zero_Chaos Farina
zeroch...@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
signature.asc
Description: PGP signature
Re: [gentoo-dev] New virtuals for libudev and libgudev
On 03/28/2014 07:53 PM, Rich Freeman wrote: On Fri, Mar 28, 2014 at 5:48 PM, Rick Zero_Chaos Farina zeroch...@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: bluen...@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
On Sat, Mar 29, 2014 at 4:34 AM, Michał Górny mgo...@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
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 zeroch...@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
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 zeroch...@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: bluen...@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
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 zeroch...@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: bluen...@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
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 zeroch...@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 eu...@gentoo.org and syst...@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
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 zeroch...@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 eu...@gentoo.org and syst...@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: bluen...@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
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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New virtuals for libudev and libgudev
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.
[gentoo-dev] New virtuals for libudev and libgudev
-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
On Fri, Mar 28, 2014 at 5:48 PM, Rick Zero_Chaos Farina
zeroch...@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
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
