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

Reply via email to