-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan Schweizer wrote: > 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 > You mean, when the user initially submit the request to the mailing list? , or this one should always be used for the maintenance of the package?
>> 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. > Well, my idea is more focused on getting closer the developer with the user, in the sense that they would be like a team (as i already said) , where the developer is the official figure in the group. So, at some degree, it does matter who is the proxy-developer in this case. The main idea is that he _indeed_ would be maintaining the package from a Gentoo perspective, and that is where the user will need to compromise with the developer. We could even create a new herd (proxy), so we can differentiate between these ebuilds inside maintainer-needed and those under the control of a specific proxy developer. This idea is heavily based on 'trust' and 'constant' communication between the user and the developer. And that is the way we can get the 'isolation' effect i commented earlier on. >> 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 > Many things, for example, if one of the package affects other(s) herd(s) (for example, some package dependency), i think that the right person to coordinate this work with the rest of the developers would be the proxy-developer. And yes, the proxy-devel also would file stabilization bugs , CCing the user too, so he can keep track of the process. - -- Luis F. Araujo "araujo at gentoo.org" Gentoo Linux -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEydx/dZ42PGEF17URAtQXAKDTfcHhXthFw7cRS4Ko9p00mTYCkgCg2omJ JaoyxDew0HETTJxZ8ZrLrvk= =lfn9 -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list
