-----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 , [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. 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@gentoo.org mailing list