To clarify things a bit (hopefully): 1) security
This is not the main tree, just a normal overlay. Okay, some non-devs contribute here but doesn't change the fact that it is just an overlay as any other out there in the world. Well, it is a bit different. Here are some devs keeping an eye on the evolution and can help people with doing it right and thus get better contributions in the end. 2) responsibility As already mentioned at 1), it is an overlay. The devs on sunrise do keep an eye on it and all ebuilds do have to pass at least repoman and some basic QA checks (currently done when porting them from bugs.g.o) so that they don't do some rm -rf / thing. They should be improved by the contributors then so that we have two things here: a) a contributor who can contribute good-quality ebuils and b) a good ebuild to be picked up by a dev and ported to the tree 3) replacement for bugs.g.o This project isn't a try to replace the contributions to bugs. It should just help to fetch and update things. We have help from bug-wranglers here (well, at least from jakub) to keep the overlay in sync with it so that one can say "Yeah, my-example/myapp r158 has this and this issue, here is a fix for it" and then either the sunrise-devs or one of the project-contributors commits it to the overlay. 4) workload on devs Well I really have problems to see increased workload on devs here who don't actively support the project. They can scour bugzie for interesting ebuilds and instead of fetching files, renaming them, moving them to a local overlay dir, just do a svn co http://overlays.gentoo.org/svn/proj/sunrise/sys-auth/pam_skey/ (as an example here) and you have all needed files already prepared to look at them or to give them a try. 5) the tarball problem On some bugs we also notice that people contribute tarballs instead of ebuilds and the files as such. Some apps need a change on a bunch of files with every version bump. Take MailScanner as an example ( http://bugs.gentoo.org/show_bug.cgi?id=36060 ). Many devs cry out loud when they come across a tarball on bugzie. It is not the best way of contribution, I know that myself. But take it the otherway around. Someone out there took time (on some apps it is really much time) and provided an ebuild. Maybe he is new to it and doesn't know much about bugzie (no usability talk required here, done every 3 months on bugzie devel ml) then they post their hard work there. Then a dev comes along and says "never ever do attach tarballs blah blubb", the contributor feels scared as it was his first contribution and the dev was crying out loud and would surely think twice if the work done is worth it. 6) problems on infra hardware Well Lance arised that, so if infra has that big concerns about this project (I personally see no hard reason for it, but let the infra guys handle it how they want), then feel free to drop me a note and we host it elsewhere. I really see a great chance for contributors here as they can improve themselves here and if they contribute good quality, even commit themselves and learn how to handle maintainership. You all know we also have some people out there that would like to maintain just one or two packages. Now we call it proxy maintainership but why not giving them commit access to sunrise then? They can maintain it here without the whole workload as dev, but maybe they get encouraged by doing so and then become a dev later. Lots of options are possible here. 7) non maintainer-wanted things Some ebuilds found their way into the overlay, we talked about that internally and I'll remove them after this mail is sent out, so that we stick to maintainer-wanted things here. Greetz, Jokey
signature.asc
Description: OpenPGP digital signature
