public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Zach Welch <zwelch@gentoo.org>
To: David Nielsen <Lovechild@foolclan.com>
Cc: gentoo-dev@gentoo.org, Sean West <swest1@loyola.edu>, genone@homeip.net
Subject: [gentoo-dev] Re: culture clash (was: Ebuild Janitor Project)
Date: Tue, 13 May 2003 16:31:07 -0700	[thread overview]
Message-ID: <3EC1803B.7010803@gentoo.org> (raw)
In-Reply-To: 1052689316.21595.105.camel@pilot.stavtrup-st.dk

David Nielsen wrote:
 > I announce a project and suddenly I'm the antichrist.

Your not discussing it with any developers makes it an issue. You and
everyone else that would come along and say "we're doing it this way"
without having so much as consulted with the existing developers makes
that label not so undeserving. Your project itself is not at fault.

I deservedly wore that same label once for these exact same reasons.

 > I did not treated to fork portage anywhere - I can't even code python
 >  for crying out loud.

That's not the point -- the initial reaction to your side-stepping the
development team tends to be, like most human reactions, fairly
predictable: fight or flight. More generally and narcissticly: if you're
not with us, then you're against us.

This is not technical reality I am talking about. This is all about
political and social perceptions - a reality that you will eventually
acknowledge even if simply by failing to over time.

 > Okay, the main issue seems to be getting along with developers.

The developers come and go -- you must fit with the culture. There is a
big difference, and only the daily interactions make it seem otherwise.
Have no doubt -- no single individual within the Gentoo Linux community
is so important that the project can't survive without them, myself
fully included.

 > Here's a little background, I have Tourette' syndrome and I'm on
 > antidepressants following an attempt at taking my life, bare with me
 > I have a short fuse - I take shit all day.

You are not the only person involved with this project that can make a
similar claim. I am very sympathetic to such circumstances, and
certainly it helps frame my interactions with individuals. However, in
the end: it does not matter. Disruptive behaviour eventually leads to
individuals being driven out of a social group because of its impact on
others, not the reasons that may or may not motivate it.

These are problems that each of us must control; if you are 'off' on a
given day, then don't turn the computer on. I have learned firsthand
that if you can't control your interactions, you are signing your own
pink slip in this organization.

Having suffered this briefly, I can imagine no greater social punishment
that can be leveled against its individuals than to permanently cast
them out from a group to which they want to belong. For extreme cases,
we call that "prison", and there can be no worse place for a person that
still feels the human need to be part of the surrounding society.

If you want to be a member of any society, you simply cannot egregiously
or continually behave outside established cultural norms - or you will
go to jail, you will not pass GO, and you will not collect $200.00.

 > Here's what makes me happy, getting good ideas, and this project
 > seemed like a good idea - So I took a chance, I never expected the
 > project to take off the way it did, I figured I would fix up a few
 > critical ebuilds a week and submit them to Bugzilla. It seems we need
 >  a quicker solution without compromising the stability of portage as
 > a whole - we don't want broken shit in there do we?

What "critical" ebuilds are not already in portage? Adding more packages
to the tree is not my idea of critical. Maintaining what we already have
should be higher priority.  If you're really worried about things
being broken, you'll take a look at ways to help us improve our existing
QA situation without throwing more ebuilds to the fire.  That pretty
much means working through the existing bugs already in Bugzilla, and
working with Bugzilla for managing submissions of fixes and patches.

In any event, I say again - I am fully behind your ideas *in theory*,
possibly even before you were considering them:

http://cvs.gentoo.org/~zwelch/udder/

In fact, some of the herds ideas tossed around lately are echos of the
exact same I issues that I pressed too hard and resulting in my first
pink slip. I was right in my solutions -- completely wrong in both their
timing and presentation. I know I could still get myself "fired" again
by pressing too hard on similarly premature issues, have no doubt.

We are still talking only theory with the ideas of Udder and herds
even today. The implementation is slowly creeping into existence, and
there is nothing anyone (not even myself) can do to hurry it along any
faster than it is already moving.  Too many chefs spoil the soup.

On the other hand, you have essentially proposed to spend your time and
resources maintaing your own forums, trees, etc. Instead, you might
consider that your ideas' time has not quite yet come, focusing your
efforts with helping us within the larger context that we have already
started to try and achieve.

When the timing is right, your ideas can be made to flourish - but you
must also accept that the community process will transform them into
something that resembles, yet may prove to be vastly different, than
what you started out doing. Of course, we must all be willing to make
these compromises along the way, both technically and socially.

Such is life.

 > We plan to release a tarball once a week with new ebuilds, now we are
 >  not asking for them to just go directly into portage, so there needs
 >  to be some developer review time going on also if possible - we also
 >  wanna make sure we waste as little time as possible right?

Collecting ebuilds is not the problem. If you want this to work, users
must be doing all of the QA steps, wrapping their results up in an
automated report form that the developers can verify locally. And this
goes back to the key point, there must be *trust* between the users
doing this work and the developers maintaining the tree.

For example, I would happily install an ebuild from certain developser
without even looking inside it. Needless to say, I am not so cavalier
about packages I received from Bugzila. I have yet to see my first
trojaned submission, but that's not for lack of looking. I must be able
to trust the submitter to have gone to the same lengths I do before I
will trust their ebuilds.

Further, many submissions come with absolutely no quantitaive
information as to why it should be trusted. Most ebuilds are drastically
undercommented, insufficiently protected against failures, and lacking a
general feeling of having been "engineered". An innocuous looking
statement like rm -rf "${A}/${B}" can not be let slip out the door if
there is a chance that A and B could both be left unset. And that is not
a hypothetical situation - these events have happened.

Even if an ebuild or patch looks well-engineered, I will not trust
someone's changes simply because they claim it fixes a problem: I must
also comprehend what that patch is doing only to the exent that I am
personally unfamiliar with the source. Anonymous submissions require my
full comprehension.

The real solution to these problem is improving the order, structure,
and efficiency of communications. If we could all get together, learn to
trust one another, the world would be a better place. And since that's
not likely to anytime happen soon, let's work together with what we do
have and struggle (yes it will be a struggle) forward toward those
distant goals.

When submitters and developers meet in IRC and bridge the gap, problems
can get solved very, very fast. While adequate, e-mail is a very big
step away from this level of interaction, and the current web-based
systems offer only shreds of back-end integration I want to see us have
someday. Personally, I loath the web forums and will not go near them
when I can help it, but that should not shut me out from what is
happening there -- we need an infrastructure that unites us together,
not yet another forum that fragments our resources.


In the end, I encourage you to do whatever you want to do, but do not
expect Gentoo developers to do anything for you until you manage to fit
into the existing culture. If you're not working with the group, you
have effectively forked yourself - even if that was not your intention.
Setting up a new forum is not playing in the existing culture, and I
personally consider it borderline unethical to be advertising it using
"legitimate" Gentoo resources.

Now all that said, I would love to see your group to propose a plan that
can be supported within our existing culture. I, for one, am truly
joyful to see a group of users willing to step up to this enourmous
challenge, but simultaneously challenging the surrounding culture makes
the result problems nearly intractable. There are enough technical
issues to keep us busy without having to deal with social volatility at
the same time.


Please come talk to us on IRC to resolve these things; for those of you
that haven't caught on, that medium might just be the singularly most
effective catalyst for change in this project. In fact, I have the
#gentoo-udder channel was set up precisely to help us resolve these issues.

Cheers,

Zach Welch
Superlucidity Services


--
gentoo-dev@gentoo.org mailing list


  reply	other threads:[~2003-05-13 23:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-11 21:41 [gentoo-dev] Re: Ebuild Janitor Project -- Any formalities to joining it? David Nielsen
2003-05-13 23:31 ` Zach Welch [this message]
2003-05-14  1:42   ` [gentoo-dev] Re: culture clash (was: Ebuild Janitor Project) Luke Graham
2003-05-14  9:32     ` David Nielsen
2003-05-14 19:41       ` Martin Schlemmer
2003-05-14 20:17         ` David Nielsen

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=3EC1803B.7010803@gentoo.org \
    --to=zwelch@gentoo.org \
    --cc=Lovechild@foolclan.com \
    --cc=genone@homeip.net \
    --cc=gentoo-dev@gentoo.org \
    --cc=swest1@loyola.edu \
    /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