Luis Francisco Araujo wrote:
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 , [EMAIL PROTECTED] , or [EMAIL PROTECTED]
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.
So far the only difference between this and doing a query on b.g.o for
maintainer-wanted is that it's on mailing list.
Now .. most of you must already be thinking, "well .. isn't this the
same that going and picking maintainer-wanted ebuilds after all?"
Yep. ;)
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.
_Has_ to? How do we enforce that?
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 :-)
So basically, the user does all the work in exchange for the ebuild being in
portage. Once it's in they disappear off the face of the earth. I still don't
see how this is any different than the status quo.
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.
Right, just like now.
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 don't think it's necessary to formalize it. If you find a user who wants to
help then great. Go ahead. You're free to define whatever relationships that
work for you. It doesn't have to be officially stamped and sealed, it's just
everyday social interaction.
--de.
--
gentoo-dev@gentoo.org mailing list
