Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)

[Luis Francisco Araujo]

-----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@g.o mailing list