From: Samuli Suominen <ssuominen@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] New virtuals for libudev and libgudev
Date: Wed, 02 Apr 2014 23:36:25 +0300 [thread overview]
Message-ID: <533C74C9.5030004@gentoo.org> (raw)
In-Reply-To: <533C6DF8.4060301@gentoo.org>
On 02/04/14 23:07, Rick "Zero_Chaos" Farina wrote:
> On 04/02/2014 02:00 AM, Samuli Suominen wrote:
>
> > On 02/04/14 05:02, Matt Turner wrote:
> >> On Tue, Apr 1, 2014 at 9:38 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> >>> Projects like the Council, ComRel and QA are there to protect Gentoo;
> >>> and yes, people are (or should be) lining up to protect Gentoo.
> >> ... from QA.
> >>
> >> You don't seem to understand what Samuli is saying. QA is being used
> >> as an offensive weapon. It's a stick to bludgeon others with.
> >>
>
> > Exactly.
>
> > Anyone remembers what happened the last time this was tried?
>
> > The "QA" attempted to force developers who didn't care if removed
> > ebuilds are recorded in the ChangeLog or
> > not, even while there was no policy in place that said they should be
> > recorded there, and nothing was ever broken.
> > People simply had different workflows.
>
> > The whole existing team died with that debacle. I don't expect it to go
> > exactly like that, this time, as the issue and
> > people involved are different, but the point is, nothing good came out
> > of it.
> > If the people who insisted they should be recorded there had been in a
> > productive fashion drive repoman to be
> > patched for --echangelog, or discuss other solutions, we could have
> > skipped the useless mudslinging.
>
> > Force is not hardly ever the correct answer. It might work in a
> > workplace, but not when people are contributing
> > for free.
>
> So forcing changes into the tree by stabilizing a bunch of new virtuals
> and adjusting all the rdeps to use them is fine, but forcing discussion
> is completely inappropriate?
>
> Wow, now that I can see it your way I agree, I'm a horrible person.
> I'll stick to randomly changing the tree as I see fit with no discussion
> since forced discussion is so wrong.
I've been constantly maintaining this has been discussed many times
earlier, and it
was in fact part of what council voted upon when they agreed subslot use
in gentoo-x86
What you tried to do, is force me to open a new thread about it, and I
told you,
you should be opening the thread yourself if you see the discussion
being useful,
because I didn't.
Part of the discussion done in #gentoo-dev, from yesterday:
20:51 <@_AxS_> Zero_Chaos: ping, re subslots and virtuals
20:53 <@_AxS_> Zero_Chaos: before EAPI5, I did a fair bit of testing
with virtuals and subslots, specifically in this case to manage the
split-up between the
three ABIs in xorg-server. It works fine, the way it's being used by
lib{,g}udev. Where it doesn't work is in the general case -- when
RDEPEND in
a virtual/* package depends on other libs without specific subslot or
version info, and those other libs bump subslot, then this doesn't
propagate
through to the rdeps of the virtual.
20:55 <@_AxS_> So long as the maintainers of a virtual's deps want to
bump the virtual and ensure its RDEPEND is explicitly linked to the
dep's subslot, this'll
work fine. It's just a lot of work to do that, is all.
21:11 <@ssuominen> _AxS_: Didn't you blog about the virtuals and
subslots? I remember someone did, and I remember what's where I picked
up the whole idea in the first place.
21:12 <@_AxS_> ssuominen: the subslot section of the wiki, iirc, yes
21:13 <@_AxS_> Also mentioned it in here a few times over, a year or
more ago
21:13 <@ssuominen> There we go then, and the link to the wiki...? was
posted in the threads when the subslots were introduced
21:14 <@ssuominen> Just saying, I've consistently maintained this was
not some new idea, and part of my reasoning was that it was talked
about, and I considered
that part of the subslot use to be part of what council agreed on, when
they allowed the subslots in gentoo-x86
21:17 <@_AxS_> ssuominen: i'm with you on that.. The one thing I don't
follow with this thread is that virtual/lib*udev is still a proper
virtual -- that is,
it's providing choice between multiple packages. it's not like it's
-only there- to represent the elements of a single package.
See, http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators#Use_Virtuals
Also, I don't think you are a horrible person, and I can surely put this
all past us, but can you?
- Samuli
next prev parent reply other threads:[~2014-04-02 20:42 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-28 21:48 [gentoo-dev] New virtuals for libudev and libgudev Rick "Zero_Chaos" Farina
2014-03-28 23:53 ` Rich Freeman
2014-03-29 8:34 ` Michał Górny
2014-03-29 12:31 ` Rich Freeman
2014-03-29 12:30 ` Anthony G. Basile
2014-03-29 12:58 ` Samuli Suominen
2014-03-29 13:23 ` Anthony G. Basile
2014-03-29 13:24 ` Anthony G. Basile
2014-03-29 13:33 ` Samuli Suominen
2014-03-29 13:51 ` Anthony G. Basile
2014-03-29 4:13 ` Samuli Suominen
2014-03-29 20:27 ` Francisco Blas Izquierdo Riera (klondike)
2014-03-30 5:30 ` Samuli Suominen
2014-04-02 5:33 ` Greg KH
2014-03-30 20:45 ` Rick "Zero_Chaos" Farina
2014-03-31 5:50 ` Samuli Suominen
2014-03-31 20:35 ` Rick "Zero_Chaos" Farina
2014-04-01 5:48 ` Samuli Suominen
2014-04-01 12:23 ` hasufell
2014-04-01 15:28 ` Tom Wijsman
2014-04-01 15:55 ` Samuli Suominen
2014-04-01 15:56 ` Samuli Suominen
2014-04-01 16:38 ` Tom Wijsman
2014-04-01 17:21 ` Samuli Suominen
2014-04-01 18:33 ` Tom Wijsman
2014-04-01 18:41 ` Samuli Suominen
2014-04-02 20:03 ` Rick "Zero_Chaos" Farina
2014-04-01 19:18 ` hasufell
2014-04-01 19:58 ` Tom Wijsman
2014-04-01 20:24 ` hasufell
2014-04-01 23:05 ` Jeroen Roovers
2014-04-02 2:47 ` Matt Turner
2014-04-02 8:16 ` [OT] " Tom Wijsman
2014-04-02 2:02 ` Matt Turner
2014-04-02 6:00 ` Samuli Suominen
2014-04-02 8:28 ` Tom Wijsman
2014-04-02 8:29 ` Samuli Suominen
2014-04-02 10:25 ` Tom Wijsman
2014-04-02 10:45 ` Andreas K. Huettel
2014-04-02 11:41 ` Samuli Suominen
2014-04-02 20:07 ` Rick "Zero_Chaos" Farina
2014-04-02 20:34 ` Rich Freeman
2014-04-02 20:36 ` Samuli Suominen [this message]
2014-04-02 8:22 ` Tom Wijsman
2014-04-01 17:16 ` Anthony G. Basile
2014-04-01 17:34 ` Samuli Suominen
2014-04-01 17:46 ` Anthony G. Basile
2014-04-01 17:45 ` Samuli Suominen
2014-04-01 17:53 ` Anthony G. Basile
2014-04-01 18:08 ` Ulrich Mueller
2014-04-01 18:10 ` Samuli Suominen
2014-04-01 18:16 ` Ulrich Mueller
2014-04-02 19:57 ` Rick "Zero_Chaos" Farina
2014-04-01 17:50 ` Rich Freeman
2014-04-01 15:08 ` Tom Wijsman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=533C74C9.5030004@gentoo.org \
--to=ssuominen@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox