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

Reply via email to