public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Stuart Herbert" <stuart@myrddraal.demon.co.uk>
To: "'John Davis'" <zhen@gentoo.org>, <gentoo-core@gentoo.org>
Cc: <gentoo-dev@gentoo.org>
Subject: RE: [gentoo-dev] Gentoo part II.
Date: Tue, 15 Jul 2003 11:19:45 +0100	[thread overview]
Message-ID: <03af01c34aba$9ce06530$c200a8c0@Churchill> (raw)
In-Reply-To: <20030714214621.33b75fbd.zhen@gentoo.org>

John,

> By creating this document, I hope to help fix the problems 
> that I see with Gentoo Linux.

Mmm ... the problems I see with Gentoo Linux seem to be a little different:

a) ebuilds marked stable w/ no robust QA procedures
b) unmaintained ebuilds
c) too many packages that Gentoo has no ebuilds for (yet ;-)
d) bugs not addressed quickly enough

Basically, I want STABLE to *mean* STABLE, I want ebuilds for new releases
on the day the releases come out, and I want to be able to install all the
applications that I want to use.  I'm a consumer in that respect, and my
concerns are anything that makes my consumer experience worse.  And that
includes death-by-committee(TM).

I don't see how any of your proposals are going to improve that situation.

1). Constitution

If people don't understand the spirit behind such rules, then the rules
themselves are no protection.  You'll get people nit-picking over the
written word, rather than over the intention behind those words.  This
happens everywhere, and is (unfortunately) human nature.  Something like the
Social Contract is much better, because it tries to capture the spirit that
is Gentoo.

I've actually made this mistake with an organisation once, and as you can
probably tell, I regret it quite deeply ;-)

2). Open Voting

This one's a close call for me.  There is a real danger in all groups of
them becoming inward-looking - a clique.  And when that happens, things tend
to go downhill very quickly.  Having anyone able to stand for a position,
and publically be judged for the role, might be able to offset that.

Problem is - that's exactly how useless good-for-nothing can't-code-for-shit
f**kers end up way over their heads in positions of authority.  They can't
do the technical job themselves, so they decide to tell others how it should
be done.  Politics is the passion of the parasite.

The Linux kernel thrives precisely because it's led by technically-competent
people.  Linus, Andrew, Alan et al are engineers first and foremost.  Right
now, the 'senior' people I've delt with in Gentoo appear to be of a similar
mould.  They've already survived the first hurdle - the threat of a fork -
and rather than circle the wagons, they've responded proactively and
positively to the *perception* that others have about Gentoo.  I'm
personally encouraged by what I've seen, and have more confidence in Gentoo
than I did two months ago.

3). Defined Terms For Managers

Preserve the balance of *power*?  If all this is about *power*, then I think
it's coming from completely the wrong direction.  The pursuit of power of
some, and the fear of giving up power by others, is the politics of the
insecure and the paranoid.  One lot believe the only way to survive is to
live off of the efforts of others, and the other lot live in fear of the
first lot because they know that they're too easy to push around.  Very
unhealthy ;-)

Why not do something more useful, and capture their *responsibilities*
instead?  The function of management should be to ensure that key
*responsibilities* are met; and Gentoo should be no exception.  This
healthier mindset would support the draft QA proposals that are kicking
around.  Never give power to anyone - just give them more work ;-)  And if
they don't meet their responsibilities, well - think of it as turkeys voting
for Christmas.

4). Meeting Procedure

I haven't been to any Gentoo meetings, so I can't comment on this.

--

I just want to add my small voice to those calling for Gentoo to remain true
to its original nature.  It's light, it's fast, and it's fun.  And it
results in a distro that is fresh, exciting, and constantly improving.
Debian, RedHat, Mandrake, <insert distro here> - none of these were
original.  They all arose from people who became unhappy with earlier
distributions - SLS, Slackware, Ygdrassil(sp?) and so on.  At first, they
were all different too.  But either politics, or money (or both) have
changed them, and not for the better.

As organisations increase in size, some structure is inevitable.  But it
seems the public debate is all about who gets into that structure and who
gets left out, rather than being about identifying clear goals for Gentoo
and then putting in a structure to meet those goals.  If the goals aren't
clear, then the structure becomes self-serving.

So I'm calling for the debate to shift away from politics, and onto
practicalities.  Where are the *procedural* problems with Gentoo?  What can
be done to get more ebuilds into portage, make it easier to keep ebuilds up
to date with current releases, and all whilst improving the quality of the
(dare I say it) 'customer experience'?  Damnit - *these* are the things that
should matter.

Best regards,
Stu
--



--
gentoo-dev@gentoo.org mailing list


  parent reply	other threads:[~2003-07-15 10:20 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-15  1:46 [gentoo-dev] Gentoo part II John Davis
2003-07-15  3:02 ` splite
2003-07-15  3:08   ` John Davis
2003-07-15  4:15     ` splite
2003-07-15  4:55       ` Kumba
2003-07-15  5:29         ` splite
2003-07-15  9:06           ` Paul de Vrieze
2003-07-15 10:05             ` Stroller
2003-07-15 10:37             ` splite
2003-07-15 10:50               ` Daniel Jaeggi
2003-07-15 18:04                 ` Jon Portnoy
2003-07-15 18:17                   ` John Davis
2003-07-15 18:28                     ` Jon Portnoy
2003-07-15 18:37                       ` Todd Berman
2003-07-15 19:13                         ` John Davis
2003-07-15 19:12                       ` John Davis
2003-07-15 11:40               ` Paul de Vrieze
2003-07-15 15:13                 ` oford
2003-07-15 17:32                   ` John Davis
2003-07-15 18:12                 ` Jon Portnoy
2003-07-15 13:20       ` cal
2003-03-17 13:42         ` Patrick Lauer
2003-07-15 13:47         ` John Davis
2003-07-15  3:40   ` Brad Cowan
2003-07-15  4:36     ` Ralph F. De Witt
2003-07-15  5:01       ` Brad Cowan
2003-07-15  6:31         ` splite
2003-07-15  4:50     ` splite
2003-07-15  4:38   ` Stewart Honsberger
2003-07-15 10:04     ` Paul de Vrieze
2003-07-15  5:53 ` William McArthur
2003-07-15  6:16 ` Brandon Low
2003-07-15  7:21   ` Ralph F. De Witt
2003-07-15 10:14     ` Paul de Vrieze
2003-07-15 10:31       ` Stuart Herbert
2003-07-15 14:03       ` Grant Goodyear
2003-07-15  8:56   ` Brad Laue
2003-07-15  7:01 ` [gentoo-dev] " Martin Gramatke
2003-07-15 10:28   ` Paul de Vrieze
2003-07-15 10:19 ` Stuart Herbert [this message]
2003-07-15 11:19   ` [gentoo-dev] " Paul de Vrieze
2003-07-15 11:39     ` Stuart Herbert
2003-07-15 12:01       ` Paul de Vrieze
2003-07-15 12:23       ` Spider
2003-07-15 18:08       ` Jon Portnoy
2003-07-15 20:27         ` Paul de Vrieze
2003-07-15 11:51 ` Spider
2003-07-16  1:44 ` Brett I. Holcomb
2003-07-16  4:25   ` Owen Gunden

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='03af01c34aba$9ce06530$c200a8c0@Churchill' \
    --to=stuart@myrddraal.demon.co.uk \
    --cc=gentoo-core@gentoo.org \
    --cc=gentoo-dev@gentoo.org \
    --cc=zhen@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