From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: Two-level portage tree is irrelevant.
Date: Mon, 24 Aug 2009 17:24:30 +0000 (UTC) [thread overview]
Message-ID: <pan.2009.08.24.17.24.30@cox.net> (raw)
In-Reply-To: 4A92BC80.20109@trelane.net
Andrew D Kirch posted on Mon, 24 Aug 2009 12:14:56 -0400 as excerpted:
> Dmitry Grigoriev wrote:
>> http://bugs.gentoo.org/show_bug.cgi?id=282491
>>
>> The idea is that package tree physical structure must correspond to
>> logical structure. E.g. package kde/games/tactics-and-strategy/knetwalk
>> instead of kde-base/knetwalk, and kde/games/all instead of manually
>> managed meta-package or set @kde-games (kde/all == @kde,
>> kde/games/arcade/all == @kde-games-arcade, ...).
>>
> I don't see a problem with this per-se other than that the massive
> amount of re-organization which would be required, which could otherwise
> be spent on fixing bugs, adding enhancements, and other cool stuff. I
> think the price is too high in the manpower catagory.
General observation: In the FLOSS community it is often said (correctly)
that for something to be done, it normally must scratch an itch that
someone with the skills to do it has, an itch bad enough to motivate the
dedication of the necessary time and intellectual energy.
It's thus that there are all sorts of otherwise impractical little
projects going on, some to eventual usability, some to eventual full
maturity, some dying on the vine, as it were. It's the incredible
broadness of the community, and thus the incredible broadness of
selection of all those little projects, that continues to drive FLOSS,
generally far more broadly and effectively than it could ever be driven
in an unshared or charge-to-share primarily cost/payment driven
proprietary system.
You see this put to great effect in the firefox extensions setup.
There's dozens of browser choices, but really only one with the
extensibility of firefox, an extensibility that many users quickly find
indispensable, thus making firefox itself indispensable for those users.
The same applies to some Gentoo projects. Realistically, how many of
those exotic archs we support, if only in -prefix or experimental form,
would even exist at all, if they had to be cost and time justified? But
they are someone's hobby, Gentoo is a volunteer organization, and those
devs have volunteered to make their hobby yet another Gentoo project.
Thus we get to the point. I agree that it's not particularly practical
to think about how the Gentoo tree might be better organized if we were
to do it today. However, if someone with the skills and the drive to
make it so can be found, that either has that itch bad enough, or can be
/given/ that itch bad enough, to actually /make/ it so, well then, it's
likely to happen. Otherwise, no, it's not, as however nice it might be
in theory, there's always higher priority more effective ways for those
with the skills and the access to make it happen, to spend their time.
Thus, the OP's mission, should he choose to accept it, is to either
develop the skills and become a Gentoo developer himself, thus giving
himself access to do it, or to effectively enough spread that itch to
someone who has the skills and the access, thus giving them the
motivation necessary as well.
Otherwise, I agree, it's simply very unlikely to ever happen, because the
solution we have now is "good enough" and the cost of changing it and
taking care of all those loose ends to make it work is high enough, that
there are always better ways to spend that time and energy.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2009-08-24 17:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-24 16:01 [gentoo-dev] Two-level portage tree is irrelevant Dmitry Grigoriev
2009-08-24 16:14 ` Andrew D Kirch
2009-08-24 17:24 ` Duncan [this message]
2009-08-24 18:11 ` [gentoo-dev] " Christian Faulhammer
2009-08-24 19:37 ` Richard Freeman
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=pan.2009.08.24.17.24.30@cox.net \
--to=1i5t5.duncan@cox.net \
--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