Luis Francisco Araujo wrote: > 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?)
The user should send the ebuild changes together with the mail. Make it look like on LKML including diffstat and the actual diff. This way you can quote and give review comments on the mailing list - visible for everyone. Of course diffing needs a good script so that the user does not have to generate the diff and the stat manually > 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,2,3,4]: How are we going to reach this? Currently the bugs for ebuilds which have both developer and user in metadata get assigned to the developer and then the developer puts the user on CC. The proposed solution is to put in metadata: maintainer-needed as herd and the user as maintainer. Thus the user can take care of the package but when he leaves or is unavailable it is still considered maintainer-neeeded which means that every developer can take it over or fix bugs. In my opinion it does not matter which developer reviews a specific version bug for a package - so the developer should not be noted in metadata.xml. Of course developers can personally commit themselves to take care of the package and add themselves to metadata too. > 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. "internal developer communication" turns out to be CCing arches on stable bugs. Giving ok to stabilize some new version. This should be done by the maintaining user since he knows the package best. What exactly do you mean with internal developer communication? - Stefan -- gentoo-dev@gentoo.org mailing list