Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
Enrico Weigelt wrote: The gentoo devs currently do much of the upstream's work. Fixing bugs or even adding new stuff which does not directly have to do w/ gentoo should be done exlusively by the upstream. This is not really a problem. Fixing bugs is what I enjoy after all, this is the interesting stuff. Spending hours on one broken build system is far more interesting than writing 100 ebuilds. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
Luis Francisco Araujo wrote: 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. So far the only difference between this and doing a query on b.g.o for maintainer-wanted is that it's on mailing list. Now .. most of you must already be thinking, well .. isn't this the same that going and picking maintainer-wanted ebuilds after all? Yep. ;) 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. _Has_ to? How do we enforce that? 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 :-) So basically, the user does all the work in exchange for the ebuild being in portage. Once it's in they disappear off the face of the earth. I still don't see how this is any different than the status quo. 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. Right, just like now. 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 don't think it's necessary to formalize it. If you find a user who wants to help then great. Go ahead. You're free to define whatever relationships that work for you. It doesn't have to be officially stamped and sealed, it's just everyday social interaction. --de. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Hill wrote: So far the only difference between this and doing a query on b.g.o for maintainer-wanted is that it's on mailing list. Which (as a side note), increase the flow of communication between developers and users, giving an alternative bugzilla. 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. _Has_ to? How do we enforce that? Nobody forces anybody here to do anything. In the same way we (by ourselves) compromise as developer to cooperate with Gentoo , we also need the same degree of compromise from the users. That simple. This is a project for people who wants to cooperate under these requirements. The users will need to read the guidelines of the project (when posted), and all these points would be explained as better as possible, so he/she might know what kind of work they need to do inside the proxy project. So basically, the user does all the work in exchange for the ebuild being in portage. Once it's in they disappear off the face of the earth. I still don't see how this is any different than the status quo. Please (re^10e)-read the point 4. (the most important one by the way) 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. Right, just like now. Not for those packages we fully maintain. I don't think it's necessary to formalize it. If you find a user who wants to help then great. Go ahead. You're free to define whatever relationships that work for you. It doesn't have to be officially stamped and sealed, it's just everyday social interaction. --de. It is organizing more than formalizing. I actually can see it might help to spread the word about this technique that many of us have been using for quite a time now. And even if we gain only one more user interested to help with this, i think it is worthy. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEy+YAdZ42PGEF17URAkhrAKDe7BNWY1yhOJibXoNBMu4ZbJYZqwCfZ32Q 2nKjQcISUdErK0jx7cVs5U0= =Y8YL -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
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
Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
-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
Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
* Luis Francisco Araujo [EMAIL PROTECTED] schrieb: Hi, 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 so far okay, but we probably suffer an different problem: The gentoo devs currently do much of the upstream's work. Fixing bugs or even adding new stuff which does not directly have to do w/ gentoo should be done exlusively by the upstream. The problem is: many projects have quite long release cycles and don't do separate bugfix releases. For example expat: it took very long to get some little makefile fixes into the release - the upstream team collected quite much until they did the next release (and then they released an direct, just bugfixing, sucessor of 1.98.x as 2.0.x ...). Some projects are quite strange about such things and its like fighting against windmills trying to change their minds. So I founded an project which maintains such bugfixes and releases hotfix patches against many versions of many patches and also stays in contact w/ upstream to get them in the tree: http://wiki.metux.de/public/OpenSource_QM_Taskforce This project is meant to concentrate QM efforts more generally (instead of each distro for its own) and prevent double works, so many distros (and also self-compiling people) can benefit from it. I'd like to invite you all to join this project and use it for your dev works @ gentoo. For an oss-qm + gentoo connection I imagine the following workflow: (should also work w/ other distros this way) * gentoo user files an bug - gets assigned to the devs. * dev inspects the bug whether its gentoo-specific or general @ general: * dev pushes the bug to oss-qm (files a bug there), * oss-qm tries to solve this bug and releases a new hotfix * the gentoo dev then takes in the hotfix and gives the patched package into the QM cycle. @ gentoo: * works as currently As for the suggested user contribution: The users willing to contribute simply join the oss-qm team and do their works there. This at least would cope evrything that's not gentoo specific. What remains to gentoo would be just the contents of the ebuild file (ie. useflags and dependencies okay, etc). At the moment some ebuilds contain much logic for doing the actual build, ie. generating makefiles, etc. This should go completely to oss-qm - the (hotfixed) packages should all supply one of the semi- standard interfaces like autoconf-style ./configure, package imports should be done entirely via pkg-config, etc. In the last few days I did much of such fixing works, ie. on mpd and libao, mainly fixing configure.in + makefiles. Some of those works are currently hanging on the devs feet, but shouldn't. The gentoo devs should only have to take some (maybe hotfixed) package, pull it through the QM cycle and look if its good enough to get it into the tree. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Enrico Weigelt wrote: The gentoo devs currently do much of the upstream's work. Fixing bugs or even adding new stuff which does not directly have to do w/ gentoo should be done exlusively by the upstream. Not true at all. We (as developers) won't be able to avoid helping upstream (it is actually in our social contract). For example, we have dealt with packages inside our herd where we are able to reproduce and detect a bug before upstream does; or even found a better way of doing something, and upstream (lucky for us) has always been happy of receiving our suggestions/fixes , included even patches. I personally think there is nothing wrong with this, i see it actually as one of the goal of gentoo. For an oss-qm + gentoo connection I imagine the following workflow: (should also work w/ other distros this way) * gentoo user files an bug - gets assigned to the devs. * dev inspects the bug whether its gentoo-specific or general @ general: * dev pushes the bug to oss-qm (files a bug there), * oss-qm tries to solve this bug and releases a new hotfix * the gentoo dev then takes in the hotfix and gives the patched package into the QM cycle. @ gentoo: * works as currently As for the suggested user contribution: The users willing to contribute simply join the oss-qm team and do their works there. This at least would cope evrything that's not gentoo specific. What remains to gentoo would be just the contents of the ebuild file (ie. useflags and dependencies okay, etc). I fail to see a border line between what you call 'gentoo specific' problems, and upstream problems. Really, it is not _that_ simple. Also, i don't see how this might be an alternative to my current proposal. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEykgrdZ42PGEF17URAhleAKDgRx+zMNomW+UUUbg3dCvJmHdtggCbB25s hGHkKFzMQmA6q9tMIaz3IhU= =y4MH -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
