From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1FoSf9-0000R8-9D for garchives@archives.gentoo.org; Thu, 08 Jun 2006 22:07:35 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k58M46MB009726; Thu, 8 Jun 2006 22:04:06 GMT Received: from smtp03.gnvlscdb.sys.nuvox.net (smtp.nuvox.net [64.89.70.9]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k58LxYbo019374 for ; Thu, 8 Jun 2006 21:59:34 GMT Received: from cgianelloni.nuvox.net (216.215.202.4.nw.nuvox.net [216.215.202.4]) by smtp03.gnvlscdb.sys.nuvox.net (8.12.11.20060308/8.12.11) with SMTP id k58LxhOC002895 for ; Thu, 8 Jun 2006 17:59:43 -0400 Received: by cgianelloni.nuvox.net (sSMTP sendmail emulation); Thu, 8 Jun 2006 17:57:18 -0400 Subject: Re: [gentoo-dev] Project Sunrise thread -- a try of clarification From: Chris Gianelloni To: gentoo-dev@lists.gentoo.org In-Reply-To: <44887368.9030302@gentoo.org> References: <44887368.9030302@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4mmsHrtoOVMtYTLU1Ft2" Organization: Gentoo Linux Date: Thu, 08 Jun 2006 17:57:17 -0400 Message-Id: <1149803837.19443.101.camel@cgianelloni.nuvox.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Archives-Salt: 29238a88-770a-4206-ac72-f81cd50d5b4e X-Archives-Hash: 28b01dd864831838fe4319e89773a8f0 --=-4mmsHrtoOVMtYTLU1Ft2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2006-06-08 at 20:58 +0200, Markus Ullmann wrote: > To clarify things a bit (hopefully): >=20 > 1) security >=20 > 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. I know that when I spoke of security, I was not only talking about the security of letting non-developers commit to an overlay that is, by design, for end users, but also of the implications of ensuring that any packages in these overlays are not vulnerable to exploits. > 2) responsibility >=20 > 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 The problem is that you are only checking on the initial commit. Go back to point #1 (security). Again, the entire concept of overlays.gentoo.org was stated again and again that this would *not* be the result of the project. Many of the maintainer-wanted ebuilds are quite good, many need to be completely rewritten to even work properly. This also completely missing the point that most of the things in maintainer-wanted are there because there is not a developer interested in them. How will this change by moving the ebuild into an overlay, I have yet to hear. > 3) replacement for bugs.g.o >=20 > 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. Honestly, having to break out a subversion client to check a fix immediately sounds like extra work. It is usually much easier to simply look at the attachment online and make a decision immediately. > 4) workload on devs >=20 > 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. Except that I can *look* at an ebuild without having to break out a subversion client currently. Also, you completely gloss over the fact that this is a overlay designed for end-user usage. This means that anything in this overlay is *very* likely to be on user's machines and cause any number of possible problems. Let's use your pam_skey as an example. Now, let's say that someone has this installed, and has configured it improperly. They file a bug because they are unable to login, and the pam maintainers receive the bug. How exactly are they supposed to know that this user has pam_skey even *available* to them when all they see as an overlay is "sunrise" and not the project-specific overlays that overlays.gentoo.org was designed for? All of the time wasted to determine that the user has done something unsupported to break their system is time that this developer could be working on a problem with a package that is actually in the portage tree, which is our primary product. > 5) the tarball problem >=20 > 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=3D36060 ). 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. An overlay will have exactly 0 impact on this. You have already stated that the ebuilds will come from bugzilla. That means that a user can still post a tarball and can still have a developer request that he not post a tarball again. This is a non-issue in this conversation. > 6) problems on infra hardware >=20 > 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. You miss something. Things in this overlay still don't make it into the official tree unless a maintainer picks it up. Taking an ebuild from bugzilla and being responsible for it and taking an ebuild from an overlay and being responsible for it have the exact same cost on developer resources. Someone *still* has to maintain it. > 7) non maintainer-wanted things >=20 > 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. Thank you. This was a major concern for myself, and I'm sure quite a few others. --=20 Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux --=-4mmsHrtoOVMtYTLU1Ft2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEiJ09kT4lNIS36YERAs13AJ4pNvD2dg99xr7y/gAn1UqST+bQdQCfQGHS A03a1QwZWCZF2fOc3sjbJgw= =OmOf -----END PGP SIGNATURE----- --=-4mmsHrtoOVMtYTLU1Ft2-- -- gentoo-dev@gentoo.org mailing list