[gentoo-dev] proxy-dev (an alternative to sunrise?)

[Luis Francisco Araujo]

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

Hello everyone,

Here, with this email, i propose (after a brief discussion on irc with
gensteaf)an alternative or at least a new model to address a few issues
with our maintainers needs and the inclusion of new packages into the
tree. Probably an alternative (temporary?) as well to the sunrise
project as the subject of this email suggest.

The idea is very simple, i will generally describe it here.

In my opinion, most of the developers are usually afraid of taking care
of maintainer-{needed-wanted} packages because of the following reasons:

1 - To fix bugs of the package: this might be a very easy task, or a
whole nightmare. Many of these packages got bunch of open bugs, so, a
developer think twice before going after a package that probably he even
doesn't know what it is for, besides that, this task might become very
time-consuming , the developer might prefer to invest this time with the
packages/herd he already maintains instead.

2 - To keep track of upstream: Though it sounds as an easy task, it
might become tedious sometimes, mainly if the developer isn't interested
at all on the project, and, this is definitely, another important point
when maintaining a package.

3 - Interesting packages: Which packages should we pick? , There exist
interested users/developers to maintain/use such a package?. We don't
have an easy way to keep track of this either.

These are the main points i have personally faced when picking
maintainer-{needed,wanted} ebuilds from bugzilla. So, i am pretty much
assuming from a personal point-of-view that others developers might be
also finding these problems (sorry if it is not the case). I don't
believe we all are happy with the current status of packages in need of
maintainers, something must be happening, and i think these three points
are part of the problem.

Ok, after detecting the problem, we need to solve it right? , the idea
is to create a proxy developer structure/mechanism/model/project , where
 the developers could let all these three points at the hands of the
user wanting to get the ebuild included into the tree.

The 'modus-operandi' would go like this:

1 - We setup a mailing list (yes, yet another one, but this one is gonna
be useful!) , call it , proxy-dev@g.o , or proxy-review@g.o.

2 - Developers interested to serve as a proxy , subscribe to the list.

3 - Users ask on this mailing list if there exist any developer
interested to include X, or Y ebuild into the tree. (Probably we could
create a template for this?)

4 - An interested developer says 'yes' on the list (so the rest of devel
can see him too) , and from there on, the developer and the user work
off-list.
   Or a developer can say 'no'. Explaining the reason (if any) of why
this ebuild shouldn't be included into the tree.
   I think this would be solving some bugzilla communication annoyances,
and opening the doors of another 'feedback' way between developers and
users.

This is pretty much the general behaviour , simple right?

Now .. most of you must already be thinking, "well .. isn't this the
same that going and picking maintainer-wanted ebuilds after all?"

Here it comes the trick or 'trap' ;-)

The user _has_ to compromise to take care of those previous commented
three points that some of us might be afraid of, besides of giving us a
centralized way of keeping informed about new ebuilds.

The users explicitly compromise to (just to make it clear):

1 - To fix *all* bugs and problems of the package: The user will need to
take care of all the bugs and problems of the specific package.
Including all dependencies if needed, in the case that the package need
dependencies that are not in the tree yet. (All these requirements
should of course be explicitly stated in the user request email)

2 - To keep track of upstream: The user needs to know the package's
project, and all the communication with upstream should be
responsibility of the user. we also sometimes find developers of a
specific project who would like to cooperate with gentoo , in my opinion
this model would give them an easy and organized opportunity to do so
either.

3 - This will give us a nice way to officially include into the tree
those packages that are more interesting for our users community. After
all they are the ones maintaining them.

4 - These users will need to keep constant and fluent communication with
the developers , you can even call it a 'team' , where the gentoo
developer is the official representation of the project. This also would
give a nice 'isolated' environment , where Gentoo as a project only
would see one developer , so we don't need any internal changes to our
current way of working. /me knock infra doors :-)

This evidently brings some developers responsibilities too, we will need
to review, and test the ebuilds. we sometimes will have to check with
upstream, and comment on the ebuild, or fixing some details. But it
should be a far minimimal effort than the developer taking care of the
package(s) by his own, in the better of the cases, he even shouldn't do
anything but to test, review and commit, from there on, the ebuild will
be under the standard procedures of maintenance (arch testing to
stabilize, bug reports to notify problems, etc). The developer should
also take care of any internal developer communication if needed.

You also can see, how we would be growing the seeds for future
developers right?

I know there already exist some developers working as proxy, well, i
appreciate if they got any comment or observation about this idea. This
is just a way of giving some organization to this kind of cooperative
mechanism at some degree. And an 'official' representation inside Gentoo
if we agree with it.

I think the project offers many advantages , i still don't figure out
too much about its implementation details (i hope you guys can help me
there too), we for sure would need a nice documentation paper , and
probably some bash scripts to automate things as genstef suggested me,
would this require a new project too?. I guess the implementation would
be something very easy though. /me knock knock infra

Ok, this is pretty much all i had in my mind for now, please send
suggestions , and criticism. Also, i hope this email helps to bring out
any problems i am not considering at the moment, if there exist any, i
am more than glad to hear them, as long as we keep the discussion in a
friendly and constructive manner. Sure we'll do!

Thanks and Gentoo for everyone!


- --


Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFEyXMKdZ42PGEF17URAs9JAJ9CWRH8MaUMTIYVnlaRiuMFfqAIuACghtKF
+QMKfUKkjQlbWw0INaA4/bI=
=6GTl
-----END PGP SIGNATURE-----
-- 
gentoo-dev@g.o mailing list