[gentoo-dev] [RFC] Non-Dev Contributors and the Tree

[Michael Cummings]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

...or, Trees and Tree Climbers: Shaking up the tree

Parts of this argument have been raised before. If this particular angle
has already been addressed, kindly point me to the archive so I can see
whether I have anything new and original to add or not. Please desist
from simply flaming this as a "seen it, declined it" deal.

I was listening to last night's recording of the Linux Link Tech Show,
during which one of the Fedora leads was interviewed. During the course
of his talk, he mentioned that Fedora had a 1000+ contributors, with
only about 250 (ish) actual Fedora developers with commit rights to the
final tree. This got me thinking about how Gentoo has historically
handled contributors and the tree, and made me wonder if there weren't a
better way that would help bolster direct community involvement without
simultaneously overtaxing our existing infrastructure.

One of Gentoo's flaws, and I can say this because I have been guilty of
doing this at least once in the dim past, is that our work-from tree is
the same one that the mirrors are reading and people are downloading to
their desktops. A mistake in committing to CVS ruins it for everyone,
with rapid (and rabid) users getting bit right after a --sync. We've
done a good job of catching and correcting these incidents - but
wouldn't it be nice if they couldn't happen as easily?

One of the comments I hear frequently from active users is that they
would love to be able to help maintain a package, or assist with what we
do, but have neither the time nor the energy to become a full dev. Sure,
we have the various overlays, bugzilla, and the home grown solutions
that some teams have come up with, but there isn't a cohesive, unified
approach to the issue of maintaining by proxy that I am aware of.

What I would like to propose is that we have an official (yes, official)
cvs overlay that is used by developers *and* contributors to commit new
ebuilds and changes to. Mirrors would still pull, as they always have,
from the gentoo-x86 cvs repo. "Official" Gentoo developers would then be
able to take from the overlay and commit to the main tree at will, but
have a common stomping ground for contributors and developers to work in
without fear of breaking the rest of the tree. We reward those users
(pardon the terms if you find that condescending, its not intended as
such) with the drive and passion, but not the means, resources, or time,
by making them contributors to this overlay, where they can make cvs
commits.

This overlay wouldn't necessarily need to be the whole of the tree,
either. Some areas, such as profiles, could be absent, as well as select
projects (perhaps the kernel and toolchain portions?). These
contributors wouldn't need to have a flood of @gentoo.org email
addresses - they are only contributors who, for whatever reason, are not
actually full scale developers.

What's the advantage to the developer community? I'm glad you asked :) I
see a few benefits right from the start. First, it frees up some of the
developers from the 'grind' of the bump-test-commit cycle. We (the
Gentoo developers) didn't come here to be ebuild monkeys. We came here,
gave our energy and time, so that we could help shape and make something
out of this product. The bump and grind is a necessary part of it, but
too often, especially for teams managing large segments (perl team
being, obviously, no exception), that bump-test-commit cycle becomes the
only thing you are ever doing.

This might mean some developers, who joined Gentoo solely for the
ability to commit new ebuilds and maintain a small segment of the tree,
decide to downgrade themselves to contributor status. That isn't a bad
thing, and I wouldn't suggest that it be compulsory either. But it would
also mean that we would be opening the doors for those folks that
actually want to help with the maintenance without the pressure and
requirements of being a dev. Perhaps the definition and role of a dev
would need to be modified, enhanced even, under this new guise, but I
don't believe that to be a bad thing.

What about the infrastructure requirements? Well, hopefully, A) we're
scaled so that if we had a 1000 developers with cvs access we'd be ok
anyway (in which case, under this proposal, there would be little
difference - 1000 cvs accounts is a 1000 cvs accounts, no matter which
way you slice it), and B) we'd only be talking about the *actual* cvs
end of the house, not anything that would affect the mirrors. I wouldn't
suggest that this additional cvs root be opened to the user community at
large, or that the mirrors be asked to dup it as well. Since in my
(limited?) vision this would only be a segment, albeit a sizable
segment, I'll grant, it shouldn't exceed any of the current thresholds
we have.

As developers, we are already accustomed (and if not, what exactly are
you maintaining in the tree??) to using a cvs checkout as an overlay.
This would simply be adding another checkout - and, it strikes me,
finally achieving the 'stable' vs 'development' branches of the tree.
And yes, in case the question is posed, the 'stable' branch that is
mirrored would still have ~arch'd material; removing testing ebuilds is
not the intent. The intent is to open up the development and maintenance
of the tree to the audience at large. And maybe even making the dev
mailing list about development again, as devs that were formerly tied up
in in the bump cycle are now free to do what they came here to do: have
parties and lobby for the softserve machine.

This email was not vetted by any member of infrastructure, or the
developers at large (that's what I thought the -dev mailing list was a
forum for, after all). I speak in hypotheticals and potentials here, not
based on hard concrete facts, so some of my premises may be amiss. Yes,
I believe we would need to create some new 'tools' (ok, shell scripts :)
to help with some of the maintenance involved in this plan - but that
should hardly be a hinderance, as I'm sure there's plenty of us that
love sinking our teeth into a good shell script (or a bad one, as the
case may be).

Comments?

~mcummings

P.S. Core readers, the irony isn't lost on me that I am posting to dev.
Consider this my last ditch post about development on -dev :)
- --

- -----o()o----------------------------------------------
Michael Cummings   |    #gentoo-dev, #gentoo-perl
Gentoo Perl Dev    |    on irc.freenode.net
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
- -----o()o----------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)

iD8DBQFGZ+9xq1ztTp5/Ti4RAmc2AKChahdXYyVViF1u7202XiypnoFybACgmx0/
9VeDhgKjnMTE3WNFtYarU3w=
=uOtS
-----END PGP SIGNATURE-----
-- 
gentoo-dev@g.o mailing list