Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Patrick Lauer wrote: On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote: How exactly is it easier to manage a large number of ebuilds versus a small number? It is easier to manage one large overlay than managing 35 small overlays. Communication overhead, duplication of effort, ... How many people will manage the big overlay? , How many ebuilds will this overlay have? , now compare that to the amount of people maintaining the small overlays and their number of ebuilds. Which one is easier now? Note: And i am omitting all that part of who are maintaining the ebuilds?, how they are maintaining them?, what kind of ebuilds they are maintaining?, and many many other details that probably immediately kill the assumption of a big overlay being easier than 35, 40, 90, 500 smaller overlays. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Sat, 10 Jun 2006 10:27:29 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: [lots of good stuff - +lots Chris] Not so many moons ago, new ebuilds were submitted to bugzilla. The bug wranglers would assign the bugs to the team most likely to end up as the maintainers, and new ebuilds either made it into the tree, or sat in bugzilla until the interest was there for it to be added, if ever. Some people felt that this process left lots of packages in bugzilla, with no one to watch over them. Because of this, the maintainer-wanted, and maintainer-needed bugzilla accounts were created to assist in tracking these bugs/packages. This was a good idea at the time, and worked fairly well so long as there were developers going through and actively searching for bugs, that were no longer assigned to the relevant teams, but instead, assigned into some big dumping ground for new package requests. I think it's clear that the maintainer-wanted/maintainer-needed hasn't actually solved the problem it was trying to address. While it has improved on some counts, I think the fact that herd maintainers are not watching those aliases means that new builds are not being brought to the attention of the devs most likely to take them on. Instead of having sunrise on gentoo.org, which I agree with Chris is fundamentally a bad idea, could we simply go back to assigning new builds to the most relevant herd alias, but also add maintainer-wanted/needed to the CC:? That way some responsibility is assigned to the herd to deal with it one way or another. If the herd does not have the manpower to deal with it they can just reassign to maintainer-needed and CC the herd, indicating they need someone to join the group of herd maintainers to take the package on. With maintainer-* on CC the benefits accrued so far from having a bunch of people helping to iron out early QA problems would remain, and at the same time the group of people most likely to pick up the package would also be aware of it. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: [. . .] Right on! :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEi/j4rsJQqN81j74RAsRHAKCJsN09KKGlLq5CD4Bh/7r9QYJ12QCgnFx1 lRWrDI1euePCP0MrwoP/Emg= =G9qu -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Donnie Berkholz wrote: Chris Gianelloni wrote: Since when was overlays.gentoo.org supposed to even be a service to our users? As I understand it, the goal was to ease development, not to provide an easy method for half-working ebuilds to make it to our user's machines. Our users are our biggest base of testers, and the point of overlays is to develop and test, so of course one of the goals is to get overlays onto users' (testers') machines. Making testing as easy as possible is important. But it should be clear that it is testing, and if the apps were ready for the real Portage tree, they'd be in it. Thanks, Donnie That's already being done very well with per-team overlays. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
First off, I would like to apologize to everyone who has to read this thread. I know that it is long. I know that it can be frustrating. That being said, I also ask for your patience in this matter, as I am not going to back down on this. I will not roll over and let something I see as this damaging to Gentoo simply happen. Also, since it is obvious that some people are trying to deflect attention away from the actual issues, I will likely not respond to any points that I don't consider to be relevant. I'm not wasting my time, nor yours, with this garbage. Some people seem to not understand that this is not *only* a technical problem, and therefore cannot be discussed on a purely technical level. Some people also think that by comparing someone to a certain ex-developer, that they're going to either win some traction or cause their opposing side to give up. This is not the truth, at all. If it has done anything, it has *fueled* me to fight this project even more. On Fri, 2006-06-09 at 23:54 +0200, Patrick Lauer wrote: On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote: Since when was overlays.gentoo.org supposed to even be a service to our users? As I understand it, the goal was to ease development, not to provide an easy method for half-working ebuilds to make it to our user's machines. What's the point of development if not to help users? Umm... perhaps to create a *product* that gives usable software to users? How about a little history lesson? Not so many moons ago, new ebuilds were submitted to bugzilla. The bug wranglers would assign the bugs to the team most likely to end up as the maintainers, and new ebuilds either made it into the tree, or sat in bugzilla until the interest was there for it to be added, if ever. Some people felt that this process left lots of packages in bugzilla, with no one to watch over them. Because of this, the maintainer-wanted, and maintainer-needed bugzilla accounts were created to assist in tracking these bugs/packages. This was a good idea at the time, and worked fairly well so long as there were developers going through and actively searching for bugs, that were no longer assigned to the relevant teams, but instead, assigned into some big dumping ground for new package requests. This process failed, as visibility for new packages was reduced to the teams that would likely be doing the actual work. Now, instead of reverting a broken and failed process, a new project is being created in an attempt to fix the problem. Unfortunately, it has been pointed out that this will introduce an even larger set of problems, but that is not being addressed very well. Everything we do should be done to help users (and worst case we help that small group of users that are devs). I would have to absolutely disagree here. Gentoo's resources should be spent helping developers do their work more efficiently. This provides a positive end result of users getting more and better software. If we simply did everything for the users, then we would have every single kernel source tree done by a few guys with little understanding of kernel internals, we'd only ship a stage1 tarball, and reiser4 would be our default file-system, stability be damned. This means it *CANNOT* be left up to a small group of developers to decide without any discussion on the matter. So now we're a democracy where everything needs to be voted upon? Anything this abhorrently stupid doesn't need a vote. Bullshit. If you need to resort to insults you failed to show on a technical level why it is bad. I have already shown that this is a piss poor idea on a technical level. I don't think I need to reiterate this again and again, but just for you, since you're not catching on, I'll do it one more time. This is an attempt to fix what is a social problem with a technical solution, where one doesn't fit. What problem is this project trying to resolve, exactly? How will creating a secondary official (hey, it's on *.gentoo.org) portage tree help in creating a higher-quality primary portage tree? How will a small team maintain the security and reliability that Gentoo has come to be known for in a secondary portage tree without the support of a security team, or the architecture teams? Why was this not discussed on the developer mailing list before being publicly announced to the world as if it were a complete and working service, with all of the issues worked out? Now, (sorry Flameeyes) let's look at another scenario. A new user to Gentoo decides that he absolutely *must* have package foo. He reads on the forums that package foo is in the Sunrise overlay, so he uses layman and syncs up the overlay. Three weeks later, he decides that he wants pam_skey. He does a search, and there it is! He installs it. This user is not even *aware* that the package came from the overlay. He has a problem. He files a bug. Guess who gets it? Remember, that he isn't
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote: You don't need a subversion client, you perhaps notice the http in front of the url.. just open it up in your browser and you get the source immediately. Umm... so now I need to go and instead of clicking a nice link in bugzilla, trawl through the subversion repository and find what I'm looking for? How exactly is downloading things via http any different than downloading them from bugzilla, which is also http? just my point of view - bugzilla sucks. Ever had to download 10 attachments for one ebuild? It is a good tool for discussion, but I would prefer a simple tool (like layman) that can automatically update things. You obviously don't like overlays, but that shouldn't be a reason to stop us from using it. Or, if you want some history like sources.g.o, you can do so as well here: http://overlays.gentoo.org/proj/sunrise/browser/ Excellent. So we're moving the history from being in a single location (the bug) to being in multiple locations. That will definitely improve the development process. Yes, now it is easier to check out the ebuilds. More users == better testing. ;-) No offense, but everything I have seen looks as if it will add even *more* overhead to actually getting packages into the tree. The only thing this seems to provide is a half-baked repository for the users to get marginally-tested ebuilds for software that wasn't interesting enough for inclusion in the tree. That differs from the 20 or so overlays maintained by users how? Honestly I'd prefer an overlay where I can marginally trust the content over a foreign repository maintained by people I don't know. And the quality of some of the overlays ... better have that supervised by devs, they should know how to handle b0rkage. Except that I can *look* at an ebuild without having to break out a subversion client currently. See my answer in 3) See mine. ;] Hmmm ... bugzilla. Instead of a simple cvs up; cd /usr/local/portage/category/package I need to search for ALL bugs with $name in it, look which one it is, curse bugzilla for falling asleep again, see which attachments are relevant, download them, curse bugzilla for falling asleep again, copy them to my overlay, read the bugcomments to see if any special renaming or directory structure is needed ... Hmmm. I think an overlay does have some advantages there ... Again, read what I wrote. I said that the developer would see sunrise in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated without considering. This is a login bug. At no point did they make mention of having installed pam_skey from this overlay. This means that I, as the developer getting this bug, am now responsible for looking at *every package* in the sunrise overlay to determine if *any* of them could *possibly* be affecting this package or causing this bug, then asking the user if they have any of them installed. This differs from a manually patched ebuild in /usr/portage by virtue of showing you that an overlay is used ... Wouldn't this process be *infinitely* easier if instead of sunrise there was a pam overlay with *only* the pam stuff? Ooooh, cool. Now I need about 75 overlays to get things done, and of course there will be no bad interaction between them ;-) Having one overlay with a focus on not-in-portage ebuilds should not cause the scenario you described and will most likely cause less weird bugs because of intra-overlay dependencies. /opinion That is *exactly* what we get with the other overlays like php and vmware. I *know* that if I'm looking at a glibc bug and the user has php as an overlay, that it isn't going to be a concern. ... and if we control the overlay we can exclude things like system packages easily. Could be part of the policy to not touch existing ebuilds. This is a prime example of totally glossing over any discussion to make it sound promising for you. If bugzilla wasn't so sucky people wouldn't try to use other methods of communication ;-) And again, one svn repo vs. 113 hard-to-find bugs ... Even better, if I am the proxy maintainer for a particular set of ebuilds for one or more user/maintainers, why do I need it in your big, bloated, and completely inappropriately-named sunshine overlay versus a developer overlay of my own? You don't. Please use your developer overlay. Please don't try to take away our more open overlay. After all, I am the *only* proxy maintainer. Why should there be the added *insecurity* of allowing any number of people that *I* might not trust complete access to the small number of packages where I am the proxy? It's your choice. Either you get mailbombed with each minor version update or you trust them to not screw up with the sunrise overlay. And the users could just create their own overlay, get it added to layman and we'd have the same without supervision. From where I'm standing it's better to have
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On 6/9/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Wouldn't this process be *infinitely* easier if instead of sunrise there was a pam overlay with *only* the pam stuff? I agree that it would make sense for the the sunrise overlay to contain smaller package trees, with each package tree aimed at a particular type of ebuild. Layman supports automatically downloading each of these smaller trees as separate overlays. This would still allow Sunrise to maintain a social workspace, where Gentoo can encourage and train would-be developers (and hopefully recruit the good ones) . In fact, I believe that it will work better, because we'll be encouraging users to focus on particular problem areas rather than encouraging users to download a large and sprawling mass of packages. Having smaller, targetted trees would also help ensure that Sunrise doesn't become another BMG. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Patrick Lauer wrote: On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote: Again, read what I wrote. I said that the developer would see sunrise in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated without considering. This is a login bug. At no point did they make mention of having installed pam_skey from this overlay. This means that I, as the developer getting this bug, am now responsible for looking at *every package* in the sunrise overlay to determine if *any* of them could *possibly* be affecting this package or causing this bug, then asking the user if they have any of them installed. This differs from a manually patched ebuild in /usr/portage by virtue of showing you that an overlay is used ... Wouldn't this process be *infinitely* easier if instead of sunrise there was a pam overlay with *only* the pam stuff? Ooooh, cool. Now I need about 75 overlays to get things done, and of course there will be no bad interaction between them ;-) Please, leave pam_skey alone. ;) It's a thing I'm using daily and the default system-auth config file installed by this ebuild allows for both system and S/KEY passwords to be used at the same time, you can pick whichever one you want. There's no way to get yourself locked out of system unless you've already forgotten your normal password and didn't yet set up OTP, in which case, it's not pam_skey problem at all. The thing has been sitting in bugzilla for ages, I've asked Flameeyes to commit it and he said he's not going to put any mode pam stuff into the tree unless he's using the modules himself. Nothing wrong w/ that. So, I can either keep on maintaining it in my local overlay or let other people use it if they find it useful. I prefer the latter. pam_abl and pam_mount is also stuff that I'm testing/using myself. The only thing I haven't tested beyond it compiles and installs is pam_pgsql, that one doesn't touch system-auth at all, comes w/ commented-out .conf and so has no effect until the user has configured it. There are about 3 other bugs requesting pam stuff, but since that stuff is essentially dead upstream, it won't be in the overlay. So, are you asking to have a separate overlay project for 4 pam ebuilds? Heh, really an overkill. Could be part of the policy to not touch existing ebuilds. IMHO the sunrice project is a good place for maintainer-wanted/needed bugs. Shouldn't be a dumpspace for whatever experimental patches for stuff that's actually being maintained in the main tree. This is a prime example of totally glossing over any discussion to make it sound promising for you. If bugzilla wasn't so sucky people wouldn't try to use other methods of communication ;-) Erm, look at the vmware-server bug (http://bugs.gentoo.org/show_bug.cgi?id=122500) . It's vastly useless for grabbing any ebuilds, there are ~350 comments and tons of obsolete, yet not marked as such ebuilds, that's why you switched to subversion, right? And it boosted the effectivity by a huge margin. Also comes w/ a nice side-effect of not bugspamming another 200 folks CCed on the bug when someone screws w/ attachments for a couple of times. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Friday 09 June 2006 11:06, Jakub Moc wrote: The thing has been sitting in bugzilla for ages, I've asked Flameeyes to commit it and he said he's not going to put any mode pam stuff into the tree unless he's using the modules himself. Or if somebody wants to help with PAM and related... considering right now Azarah is mostly away and I'm almost alone handling the rest. Yes it's offtopic, but a quick way to remember that we need more PAM maintainers :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpyjpJZELOjq.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 10:28 +0200, Patrick Lauer wrote: Except that I can *look* at an ebuild without having to break out a subversion client currently. See my answer in 3) See mine. ;] Hmmm ... bugzilla. Instead of a simple cvs up; cd /usr/local/portage/category/package I need to search for ALL bugs with $name in it, look which one it is, curse bugzilla for falling asleep again, see which attachments are relevant, download them, curse bugzilla for falling asleep again, copy them to my overlay, read the bugcomments to see if any special renaming or directory structure is needed ... Hmmm. I think an overlay does have some advantages there ... Advantages? With bugzilla I: search for the bug, cc myself on it, download the relevant files, look over them, note a style error, try to merge it, fix a compilation bug, re-upload the fixed ebuild and patch to bugzilla with a comment to the ebuild author on their mistake. When an update hits my inbox I can go directly to the bug... With an overlay: search sunrice.gentoo.org for the package (no, I don't know category/name), sync that directory (no, I'm not syncing the whole sunrice tree), check it over, note some mistakes, compile it if I feel OK with it, it fails, I fix it - and what then? Where do I discuss the problems? How do I get my fixes to other users, considering the package is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will it be read? This seems like *raising* the barrier to entry to me... Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On 6/9/06, Edward Catmur [EMAIL PROTECTED] wrote: With an overlay: search sunrice.gentoo.org for the package If you want people to debate seriously with you, stop calling this project 'sunrice'. If you can't discuss this topic respectfully with others on this list, please stop using our lists. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Edward Catmur wrote: On Fri, 2006-06-09 at 10:28 +0200, Patrick Lauer wrote: Instead of a simple cvs up; cd /usr/local/portage/category/package I need to search for ALL bugs with $name in it, look which one it is, curse bugzilla for falling asleep again, see which attachments are relevant, download them, curse bugzilla for falling asleep again, copy them to my overlay, read the bugcomments to see if any special renaming or directory structure is needed ... Hmmm. I think an overlay does have some advantages there ... Advantages? With bugzilla I: search for the bug, cc myself on it, download the relevant files, look over them, note a style error, try to merge it, fix a compilation bug, re-upload the fixed ebuild and patch to bugzilla with a comment to the ebuild author on their mistake. When an update hits my inbox I can go directly to the bug... Hmmm, I mostly notice a different scenario: - search for the bug, and file a dupe because you didn't find it :P - bug gets marked as a dupe - the guy who filed the dupe comments on how much bugzilla search sucks - download one of obsolete broken ebuilds attached to the bug - moan that it doesn't work - download another ebuild - moan that it doesn't work either - someone points to comment #27 that says you need to edit lines XX and YY for the ebuild to work - do it, post yet another redundant yay, that finally worked! comment - attach a fixed ebuild tarball - you get scream upon to not attach tarballs - you attach a plaintext ebuild now - notice that its MIME type is application/octet-stream - change the mime type - look at the ebuild in the browser now that you can and notice bunch of stupid typos you've done that ruin the whole fix (hello, Mr. Murphy) - try to edit the attachment in bugzilla, which produces one huge nonsense comment instead of actually editing the ebuild - attach a new one - oh noes, it's octet-stream again! argh! - fix it... - forgot to mark previous one as obsolete, do it now - produce sorry for the noise comment - someone notices that you've still left two typos there and attaches yet another ebuild By now, about 15 bugspams times the number of people CCed on the bug got sent, containing mostly useless crap. With an overlay: search sunrice.gentoo.org for the package (no, I don't know category/name), sync that directory (no, I'm not syncing the whole sunrice tree), check it over, note some mistakes, compile it if I feel OK with it, it fails, I fix it - and what then? Where do I discuss the problems? How do I get my fixes to other users, considering the package is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will it be read? This seems like *raising* the barrier to entry to me... Yes, with an overlay you can prevent all the attachment screwups noted above and once you are really satisfied that it works, you post a link to bugzilla. You can fix your typos in VCS, even multiple times, without bugspamming the hell out of people, and you still have the history to go back if you screw up. Bugs with tens of attachments are essentially useless for most of newcomers and suck for effective development as well. A couple of examples: http://bugs.gentoo.org/show_bug.cgi?id=24247 http://bugs.gentoo.org/show_bug.cgi?id=70161 http://bugs.gentoo.org/show_bug.cgi?id=122500 -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
This may work for Apache or PHP, but an overlay with arbitrary maintainer wanted ebuilds would need an extra bugzilla account. The problem is that this won't really help, since (some) users will see oh, an kde app crashed and file a bug at [EMAIL PROTECTED] Then /me looks at the tree, doesn't see the package and marks the bug as invalid. Even worse it is for bug wranglers. You hardly can expect that they look up every single overlay. You should at least make it visible in bold letters on the overlay.g.o front page, what the conditions of each overlay are and which [EMAIL PROTECTED] address bugs have to be assigned to. Also some warning that an overlay may break the tree or fubar the users system and that only the one who uses it, is responsible for using it, wouldn't be wrong. Carsten pgpbOuaBdZ6Hq.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 02:49 +0200, Markus Ullmann wrote: Excellent. So we're moving the history from being in a single location (the bug) to being in multiple locations. That will definitely improve the development process. Another thing that people tend to miss is that not all improved versions of ebuilds submitted to bugzilla are done byt he original authors. There are many cases where an initial ebuild is done, a developer makes comments on what needs to be changed, and *another* contributor gives a fixed ebuild. How exactly will this streamline that process? No offense, but everything I have seen looks as if it will add even *more* overhead to actually getting packages into the tree. The only thing this seems to provide is a half-baked repository for the users to get marginally-tested ebuilds for software that wasn't interesting enough for inclusion in the tree. we want to encourage users to contribute and if they do good contributions in bugzilla they get commit access to the overlay. and then the workload is drastically reduced... You didn't answer anything I asked here. This is a bug for an ebuild that the user does not think is related to the pam_skey. Go back and read what I wrote. it was agreed upon that we don't keep extra bugzilla or whatever for all things on o.g.o but keep track of all issues within bugs.g.o. and btw, most work on new bugs is done by bug wranglers and not the common devs. So if they say the workload from it is too high, I'll take it as valid reason as they have to handle it. I'm sorry, but you're avoiding the question here. How will the bug-wranglers even *know* that this is related to a package in the overlay? They wouldn't. As I ststed *repeatedly* now. The user has not mentioned that they're using pam_skey, as is a common occurrence in bugs. Again, read what I wrote. I said that the developer would see sunrise in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated without considering. This is a login bug. At no point did they make mention of having installed pam_skey from this overlay. This means that I, as the developer getting this bug, am now responsible for looking at *every package* in the sunrise overlay to determine if *any* of them could *possibly* be affecting this package or causing this bug, then asking the user if they have any of them installed. why would a pam dev get this bug? as far as I know bug wranglers work, a check whether the ebuild is in tree is one of the first ones... So the chance that it really hits the pam dev is damn small... Because the user has pam in USE and there's nothing else indiciating that they're using some pam packages from an overlay that has absolutely no hint as to its contents. Also, as I have said, while the bug wranlgers are wonderful and really do reduce our workload, they're *nowhere* near perfect. There are *tons* of bugs that go to the wrong people, or are simply invalid once the actual maintainers see it. The bug wranglers cannot be expected to be experts on every package. Your comments make it sound like they will be. We're not the first large overlay project, there are other ones out there already and these wrong bugs aren't a new thing arising here... No. You're the first large overlay project that is on official Gentoo infrastructure, even after it was agreed that there wouldn't be something like this. With the non-official projects, we simply don't support any bugs from anyone using them. It's that simple. With this project, you're vying for official status, meaning we cannot do that. This will be an *enormous* time sink for the entire ebuild developer pool. Wouldn't this process be *infinitely* easier if instead of sunrise there was a pam overlay with *only* the pam stuff? Then the pam devs are responsible for all the things with it. As it would surely be hosted on o.g.o then, we'll notice it and either shift all ebuilds we have in the sunrise tree over or do whatever is fine with pam devs. If they really dislike the m-w bugs out of their control, then a friendly note on irc, a friendly mail or whatever is enough and we won't touch things of them then... Excellent job of avoiding the issue. I asked how the pam developers would even *know* that there is pam crap in your aptly-named sunrise overlay, and you respond with a comment about how when the pam devs tell you to move the packages you will. I am honestly seeing that this is starting to go nowhere as the answers to my questions aren't being given, and instead the issues are being avoided. That is *exactly* what we get with the other overlays like php and vmware. I *know* that if I'm looking at a glibc bug and the user has php as an overlay, that it isn't going to be a concern. Well we don't keep ebuilds in there which have a maintainer in contrast to the php overlay. they may even keep newer versions of in-tree packages
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, Jun 09, 2006 at 08:16:32AM -0400, Chris Gianelloni wrote: On Fri, 2006-06-09 at 02:49 +0200, Markus Ullmann wrote: This is a bug for an ebuild that the user does not think is related to the pam_skey. Go back and read what I wrote. it was agreed upon that we don't keep extra bugzilla or whatever for all things on o.g.o but keep track of all issues within bugs.g.o. and btw, most work on new bugs is done by bug wranglers and not the common devs. So if they say the workload from it is too high, I'll take it as valid reason as they have to handle it. I'm sorry, but you're avoiding the question here. How will the bug-wranglers even *know* that this is related to a package in the overlay? They wouldn't. As I ststed *repeatedly* now. The user has not mentioned that they're using pam_skey, as is a common occurrence in bugs. Curious, how will the wrangler know in general? *cough* they won't. You're using a generic arguement against a specific target- iow, apply it to overlays.g.o in general instead of singling sunrise out via it. Meanwhile, answer to that one is better bug data for reporting- dump of (random out of the ass example) first level deps, and where they came from (overlay/portdir). Downside to that data is that slackers will automatically punt the bug if they see non portdir in cases where it's obvious it's an issue in the pkg rather then the deps, but there always is a downside... We're not the first large overlay project, there are other ones out there already and these wrong bugs aren't a new thing arising here... No. You're the first large overlay project that is on official Gentoo infrastructure, even after it was agreed that there wouldn't be something like this. With the non-official projects, we simply don't support any bugs from anyone using them. It's that simple. With this project, you're vying for official status, meaning we cannot do that. This will be an *enormous* time sink for the entire ebuild developer pool. Same for above re: large overlay, realistically, like it or not the general case of N overlay/repo is coming down the pipe. Personally, I'd rather see this particular case be handled from the get go as an experiment- lay out from the start the exit conditions for it (if it becomes a dumping ground, out she goes). Reason? Devs/users have been after a true testing branch/repo from day one, if we're doing overlays and people are willing to try and supply that demand, lets get the question answered once and for all (instead of everyone and their mother shooting off about every potential they can think of for why it might fail). ~harring pgpcq5ihyOyf2.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, Jun 09, 2006 at 05:42:01AM -0700, Brian Harring wrote: Curious, how will the wrangler know in general? *cough* they won't. You're using a generic arguement against a specific target- iow, apply it to overlays.g.o in general instead of singling sunrise out via it. Well, the other overlays at overlays.gentoo.org will primarily be team/herd specific overlays as I understand it - overlays maintained by the people managing the ebuilds. If a bug ticks in about, say, a KDE related ebuild it will be assigned to the KDE herd - who are in a much better position to know whether or not this bug might be caused by something available in their project overlay, since they're the ones who put it there in the first place. Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpyxOX8zX14r.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 10:28 +0200, Patrick Lauer wrote: On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote: You don't need a subversion client, you perhaps notice the http in front of the url.. just open it up in your browser and you get the source immediately. Umm... so now I need to go and instead of clicking a nice link in bugzilla, trawl through the subversion repository and find what I'm looking for? How exactly is downloading things via http any different than downloading them from bugzilla, which is also http? just my point of view - bugzilla sucks. Ever had to download 10 attachments for one ebuild? It is a good tool for discussion, but I would prefer a simple tool (like layman) that can automatically update things. You obviously don't like overlays, but that shouldn't be a reason to stop us from using it. Well, I thank you for your vast experience as an ebuild developer in this matter. You do realize that this isn't one of those things where you can say that if you don't like it you don't have to use it, right? This *will* affect *every* ebuild developer. This means it *CANNOT* be left up to a small group of developers to decide without any discussion on the matter. Or, if you want some history like sources.g.o, you can do so as well here: http://overlays.gentoo.org/proj/sunrise/browser/ Excellent. So we're moving the history from being in a single location (the bug) to being in multiple locations. That will definitely improve the development process. Yes, now it is easier to check out the ebuilds. More users == better testing. Except that now the developer has to do much more work to get the same information, making it even less likely that he'll bother to pick up one of these maintainer-wanted bugs. You also completely gloss over the ability of a single rogue user to now compromise countless users with a single commit. Please come back once you've firmly grounded yourself in the reality that we're a pretty popular distribution, and that makes this project a prime target for malicious abuse. Perhaps if you were responsible for some ebuilds, you've be more cognizant of the implications that a bad commit can cause our users. No offense, but everything I have seen looks as if it will add even *more* overhead to actually getting packages into the tree. The only thing this seems to provide is a half-baked repository for the users to get marginally-tested ebuilds for software that wasn't interesting enough for inclusion in the tree. That differs from the 20 or so overlays maintained by users how? Let's see. They aren't on Gentoo infrastructure, which means they don't give off any immediate assumption of being official or supported in any way. Hell, go back and look at Peter's response about how he would use an overlay such as this only *because* it is on Gentoo infrastructure. So what exactly was your counter-point again? Honestly I'd prefer an overlay where I can marginally trust the content over a foreign repository maintained by people I don't know. Having an overlay such as this will tarnish Gentoo's reputation. We should not be providing *anything* that is only half-supported or half-tested. Anything less than being sully supported via the security team and QA is a failure on the part of Gentoo. We have enough *crap* in the *tree* that is unsupported, which makes us look bad, yet you want to insist on supporting a project that affects all of the ebuild developers, which you have not mentioned is a group which you are not a part of, so can gladly speak of increasing their workload with no consequences to yourself, and provides an avenue for low-quality or possibly malicious ebuilds to be distributed to our users, all under a Gentoo banner? I seriously question your motives towards the Gentoo project. Hmmm ... bugzilla. Instead of a simple cvs up; cd /usr/local/portage/category/package I need to search for ALL bugs with $name in it, look which one it is, curse bugzilla for falling asleep again, see which attachments are relevant, download them, curse bugzilla for falling asleep again, copy them to my overlay, read the bugcomments to see if any special renaming or directory structure is needed ... Hmmm. I think an overlay does have some advantages there ... Sure. Until I sneak in some obfuscated code as a fix to a bug and it gets executed on your machine because the actual *developers* that are used to maintaining this stuff and know what to look for aren't a part of the process. Making something easier does not make it better. I'm sorry, but you've yet to convince me on how your laziness is supposed to be an improvement for the development process of Gentoo. Again, read what I wrote. I said that the developer would see sunrise in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated without considering. This is a login bug. At no point did they make mention of
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 11:06 +0200, Jakub Moc wrote: The thing has been sitting in bugzilla for ages, I've asked Flameeyes to commit it and he said he's not going to put any mode pam stuff into the tree unless he's using the modules himself. Nothing wrong w/ that. So, I can either keep on maintaining it in my local overlay or let other people use it if they find it useful. I prefer the latter. pam_abl and pam_mount is also stuff that I'm testing/using myself. The only thing I haven't tested beyond it compiles and installs is pam_pgsql, that one doesn't touch system-auth at all, comes w/ commented-out .conf and so has no effect until the user has configured it. Uhh... You're a developer. How about instead, you simply join the pam team with Flameeyes and add these packages and maintain them yourself? Do you really need an overlay with *countless* possibilities for other ebuilds to maintain 4 packages? There are about 3 other bugs requesting pam stuff, but since that stuff is essentially dead upstream, it won't be in the overlay. So, are you asking to have a separate overlay project for 4 pam ebuilds? Heh, really an overkill. No. It is called a repository that actually has an explicit purpose. I guess you've missed all of the other overlays out there that are limited to a specific scope. The funny thing is that I *know* that you use at least one of these external repositories, and I haven't heard you complaining that you need to move these packages to some free-for-all overlay such as this. I wonder why that is? Could be part of the policy to not touch existing ebuilds. IMHO the sunrice project is a good place for maintainer-wanted/needed bugs. Shouldn't be a dumpspace for whatever experimental patches for stuff that's actually being maintained in the main tree. It really is funny when you're arguing *for* something, yet you call it the sunrice project. Freudian slip, or an admission of truth? This is a prime example of totally glossing over any discussion to make it sound promising for you. If bugzilla wasn't so sucky people wouldn't try to use other methods of communication ;-) Erm, look at the vmware-server bug (http://bugs.gentoo.org/show_bug.cgi?id=122500) . It's vastly useless for grabbing any ebuilds, there are ~350 comments and tons of obsolete, yet not marked as such ebuilds, that's why you switched to subversion, right? And it boosted the effectivity by a huge margin. Also comes w/ a nice side-effect of not bugspamming another 200 folks CCed on the bug when someone screws w/ attachments for a couple of times. So you're going to try to use my own project as an example against me? Great. Bring it on. The vmware overlay is limited to only vmware products. When someone uses the overlay, they *know* that they are only getting ebuilds related to vmware. The project sunricer overlay is for any ebuilds of any kind. It is not focused on anything, what-so-ever, and has had many arguments against its use for many reasons. In the future, if you're going to try to use someone's project as an argument against them, at least try to come up with an argument that works. Using a focused overlay as an example of why a massive, bloated, free-for-all overlay should exist isn't exactly helping your argument, but instead helps mine. Thanks for making my work easier. =] -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Chris Gianelloni wrote: snipped lots and lots of valid points Well, I am going to do everything within my power to stop it. I will not back down until this project is dead. It really is that simple. *golf-clap* -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 11:01 +0100, Edward Catmur wrote: Hmmm. I think an overlay does have some advantages there ... Advantages? With bugzilla I: search for the bug, cc myself on it, download the relevant files, look over them, note a style error, try to merge it, fix a compilation bug, re-upload the fixed ebuild and patch to bugzilla with a comment to the ebuild author on their mistake. When an update hits my inbox I can go directly to the bug... With an overlay: search sunrice.gentoo.org for the package (no, I don't know category/name), sync that directory (no, I'm not syncing the whole sunrice tree), check it over, note some mistakes, compile it if I feel OK with it, it fails, I fix it - and what then? Where do I discuss the problems? How do I get my fixes to other users, considering the package is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will it be read? This seems like *raising* the barrier to entry to me... Thank you. This explains my point about no longer having a definitive place to look for things much better than I did, and from a user point-of-view no less. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 12:33 +0200, Jakub Moc wrote: well. A couple of examples: http://bugs.gentoo.org/show_bug.cgi?id=122500 And again, you use my project of an example. Perhaps you should try looking at something that actually supports your argument? A subversion repository was built for this. However, if you took the 3 seconds to *look* at the repository, you would see that it is actually an overlay for *all* of the vmware stuff. Then again, I guess it is just easier to ignore the facts and use things as you wish in an attempt to strengthen a weak argument. Of course, this is also an example of how a repository with an actual defined goal can bring on developers, since Mike is now a developer and a part of the VMware team. So again, I thank you for strengthening my position, while attempting to support your own. If you keep this up, I won't even have to reply anymore. ;] -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Chris Gianelloni wrote: With an overlay: search sunrice.gentoo.org for the package (no, I don't know category/name), sync that directory (no, I'm not syncing the whole sunrice tree), check it over, note some mistakes, compile it if I feel OK with it, it fails, I fix it - and what then? Where do I discuss the problems? How do I get my fixes to other users, considering the package is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will it be read? If the overlay were using a decent distributed SCM, you would get your fixes to users by posting your repository and requesting that it be merged in. I was under the impression that all ebuilds in this overlay would already have an associated bug for discussion. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
well. A couple of examples: http://bugs.gentoo.org/show_bug.cgi?id=122500 And again, you use my project of an example. Perhaps you should try looking at something that actually supports your argument? I think it's an example of how user-friendly is bugzilla... -- Best Regards, Piotr Jaroszynski -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 02:08 +0100, Ciaran McCreesh wrote: On Fri, 09 Jun 2006 02:49:14 +0200 Markus Ullmann [EMAIL PROTECTED] wrote: | No. It clearly says that you would be doing the basic QA checks and | repoman checking on initial commit. You even said it right above | where I commented! | | You're doing some witch hunting here... I said we keep an eye on | non-devs commits. How much do you want to bet that I couldn't sneak malicious code past you? And if you accept that I could do it, you're also admitting that quite a few other random people, some of whom don't share my own ethical objections to such a stunt, could also pull it off given sufficient time and effort... I'd say that it's entirely possibly for some non-dev to sneak malicious code into the tree as is now, just as it will be possible to do in an overlay. It's not like it's particulary difficult to have someone proxy for you, and let's face it, if someone is willing to do so then they probably can't be arsed checking that what they are committing is clean and nice.. I mean, I trust you, right? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Peper wrote: well. A couple of examples: http://bugs.gentoo.org/show_bug.cgi?id=122500 And again, you use my project of an example. Perhaps you should try looking at something that actually supports your argument? I think it's an example of how user-friendly is bugzilla... Yeah, exactly... I don't understand where did this idea of me using someone else's own project against himself came from in the first place. *confused* I've merely posted a few examples illustrating that bugzilla and attachments suck big time for new ebuilds' development. Or, why did you switch vmware-server work to SVN if bugzilla is *the* place for all this? Apparently it's not all that great, otherwise you wouldn't have done that. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 20:12 +0200, Jakub Moc wrote:
Peper wrote:
well. A couple of examples:
http://bugs.gentoo.org/show_bug.cgi?id=122500
And again, you use my project of an example. Perhaps you should try
looking at something that actually supports your argument?
I think it's an example of how user-friendly is bugzilla...
Yeah, exactly... I don't understand where did this idea of me using
someone else's own project against himself came from in the first place.
*confused*
I've merely posted a few examples illustrating that bugzilla and
attachments suck big time for new ebuilds' development. Or, why did you
switch vmware-server work to SVN if bugzilla is *the* place for all
this? Apparently it's not all that great, otherwise you wouldn't have
done that.
See you are just missing the point. He switched it to a VMware specific
SVN repo maintained by people who know VMware inside and out, otherwise
known as the VMware team. There is a HUGE difference between an overlay
with ${random_ebuilds} maintained by a small group who cannot possibly
know all of the ins and outs of every package and their impact on every
architecture and a targeted overlay for a very specific purpose which
only contains ebuilds for which the maintainers have 100% complete
understanding. Targeted overlays maintained by people who understand the
packages in question in totality == good, Catchall overlays maintained
by a few people who cannot possibly (and this isn't meant as a dig
against anyone it's just a fact) understand the implications and
interactions of *all* the packages in said overlay == BAD!
--Dan
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 05:42 -0700, Brian Harring wrote: On Fri, Jun 09, 2006 at 08:16:32AM -0400, Chris Gianelloni wrote: On Fri, 2006-06-09 at 02:49 +0200, Markus Ullmann wrote: This is a bug for an ebuild that the user does not think is related to the pam_skey. Go back and read what I wrote. it was agreed upon that we don't keep extra bugzilla or whatever for all things on o.g.o but keep track of all issues within bugs.g.o. and btw, most work on new bugs is done by bug wranglers and not the common devs. So if they say the workload from it is too high, I'll take it as valid reason as they have to handle it. I'm sorry, but you're avoiding the question here. How will the bug-wranglers even *know* that this is related to a package in the overlay? They wouldn't. As I ststed *repeatedly* now. The user has not mentioned that they're using pam_skey, as is a common occurrence in bugs. Curious, how will the wrangler know in general? *cough* they won't. I already covered this. If you're going to be a part of the conversation, try to keep up, will you? *grin* You're using a generic arguement against a specific target- iow, apply it to overlays.g.o in general instead of singling sunrise out via it. Except the other overlays are not designed as end-user overlays. They are designed to aid developers. Also, they are targeted at a specific task/goal, as opposed to being a dumping ground for the unwanted and unmaintained. Meanwhile, answer to that one is better bug data for reporting- dump of (random out of the ass example) first level deps, and where they came from (overlay/portdir). I definitely agree that better bug data would help the situation. However, it does not change the fact that this is still a dumping ground. Again, this was something that was *explicitly* stated that overlays.gentoo.org would *not* become, yet here we are. Downside to that data is that slackers will automatically punt the bug if they see non portdir in cases where it's obvious it's an issue in the pkg rather then the deps, but there always is a downside... Most people tend to not punt the bug so much as ask for proof that it isn't caused by the overlay. I know that we have done this in games and it has almost always ended up as something the user has done thanks to an overlay. In the cases where it truly is a bug, we fix it. We're not the first large overlay project, there are other ones out there already and these wrong bugs aren't a new thing arising here... No. You're the first large overlay project that is on official Gentoo infrastructure, even after it was agreed that there wouldn't be something like this. With the non-official projects, we simply don't support any bugs from anyone using them. It's that simple. With this project, you're vying for official status, meaning we cannot do that. This will be an *enormous* time sink for the entire ebuild developer pool. Same for above re: large overlay, realistically, like it or not the general case of N overlay/repo is coming down the pipe. Sure. Doesn't mean I have to support anything but the one and only official Gentoo package repository. Complain all you want, but I became a Gentoo developer, not a $random_repository developer for a reason. Personally, I'd rather see this particular case be handled from the get go as an experiment- lay out from the start the exit conditions for it (if it becomes a dumping ground, out she goes). I'd rather the things that were agreed upon when the overlays project was started were actually adhered to, instead. I guess it is just too much to ask from some people to keep their word. ...and people wonder why Gentoo developers don't trust each other anymore. Reason? Devs/users have been after a true testing branch/repo from day one, if we're doing overlays and people are willing to try and supply that demand, lets get the question answered once and for all (instead of everyone and their mother shooting off about every potential they can think of for why it might fail). Fine. Make a proposal to actually add it to the tree and do it properly. There's no need to have this sort of thing limited to a very small subset of developers who couldn't *possibly* keep up with the workload. Yes, there will only be a few developers and they'll be really busy, especially since they're going to be checking every commit to ensure that there's no malicious code.. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 10:05 -0700, Donnie Berkholz wrote: Chris Gianelloni wrote: With an overlay: search sunrice.gentoo.org for the package (no, I don't know category/name), sync that directory (no, I'm not syncing the whole sunrice tree), check it over, note some mistakes, compile it if I feel OK with it, it fails, I fix it - and what then? Where do I discuss the problems? How do I get my fixes to other users, considering the package is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will it be read? If the overlay were using a decent distributed SCM, you would get your fixes to users by posting your repository and requesting that it be merged in. I was under the impression that all ebuilds in this overlay would already have an associated bug for discussion. Initially, yes. What happens once the user gets complete access to the repository, though? Are we going to be keeping people from adding packages without bugs? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Chris Gianelloni wrote: Initially, yes. What happens once the user gets complete access to the repository, though? Are we going to be keeping people from adding packages without bugs? Absolutely. This is for maintainer-wanted stuff, so it should be documented in Bugzilla and assigned to maintainer-wanted with a special keyword to indicate it's in the overlay. The question is how to come up with some QA tool to enforce this. I don't find this overlay objectionable, assuming it's only used for maintainer-wanted packages. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 09 Jun 2006 20:06:04 +0100 Christel Dahlskjaer [EMAIL PROTECTED] wrote: | I'd say that it's entirely possibly for some non-dev to sneak | malicious code into the tree as is now, just as it will be possible | to do in an overlay. | | It's not like it's particulary difficult to have someone proxy for | you, and let's face it, if someone is willing to do so then they | probably can't be arsed checking that what they are committing is | clean and nice.. I mean, I trust you, right? Huge difference between committing a few things for a person you know, where you have time to review code, and bulk committing random stuff where you don't have time to check anything. That's the deal here -- if a large number of developers can't handle maintainer-wanted, what makes people think a far smaller number can without screwing up? -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 19:41 +0200, Patrick Lauer wrote: This *will* affect *every* ebuild developer. Maybe you don't realize that taking ebuilds for packages that are _not in portage_ and providing them in a nice bundle does not affect every developer? I'm sorry for the language, but I call bullshit. It is painfully obvious by your response that you've never had a library that is an optional dependency (and one we don't --without durng configure, since it isn't in the tree) cause a problem in one of your packages. Allowing libraries means it can cause breakage. Period. Noone wants to push a new cvs-snapshot of glibc. That so not the point here. Nobody ever said that you have to push a new glibc to cause mass breakage. But having a controlled managed overlay with ebuilds that are now spread all across bugzilla ... that would be a good service to our users. Since when was overlays.gentoo.org supposed to even be a service to our users? As I understand it, the goal was to ease development, not to provide an easy method for half-working ebuilds to make it to our user's machines. This means it *CANNOT* be left up to a small group of developers to decide without any discussion on the matter. So now we're a democracy where everything needs to be voted upon? Anything this abhorrently stupid doesn't need a vote. It should be cast out on its complete lack of merit, alone. Also, at no point did I ever ask for a vote. Don't put words in my mouth and I'll try to pretend like I care what you say, OK? *sigh* Let's leave that debate for another day ... You brought it up, not I. Feel free to debate it with yourself until you're blue in the face. Yes, now it is easier to check out the ebuilds. More users == better testing. Except that now the developer has to do much more work to get the same information, making it even less likely that he'll bother to pick up one of these maintainer-wanted bugs. s/the developer/I/ You're right... I had that wrong. s/the developer/the developers/ After all, there have been quite a number of people agreeing with me. there are some devs that would prefer this overlay environment. Please don't push your personal preferences as The Right Way (tm) Ehh. Were you an ebuild developer, your opinion might actually count for something when it comes to an ebuild development discussion. By the way, where's the GWN this week? You also completely gloss over the ability of a single rogue user to now compromise countless users with a single commit. And an ebuild on bugzilla has more security? Nope. However, I'm also not proposing that ebuilds from bugzilla automatically get pulled in over some magical overlay that is supposed to fix all of the problems Gentoo's ever had with unmaintained packages. We're just making it easier to use these ebuilds. Also I expect the maintainers to keep a reasonable quality standard. I'm glad your faith in them is so high. My faith in *any* group this small having the ability to watch over a large number of outside contributors simply isn't there. Please come back once you've firmly grounded yourself in the reality that we're a pretty popular distribution, and that makes this project a prime target for malicious abuse. Perhaps if you were responsible for some ebuilds, you've be more cognizant of the implications that a bad commit can cause our users. I am not responsible for ebuilds because I don't trust myself enough :-) That's great. I don't trust you enough, either. ;] That doesn't stop me from giving out access to my server to anyone who has a good reason ... like the Gentoo/HURD repository or the Java overlay. Well, we thank you for your immense self-sacrifice. What this has to do with the topic at hand, I have no idea. That differs from the 20 or so overlays maintained by users how? Let's see. They aren't on Gentoo infrastructure, which means they don't give off any immediate assumption of being official or supported in any way. Hell, go back and look at Peter's response about how he would use an overlay such as this only *because* it is on Gentoo infrastructure. So what exactly was your counter-point again? We have control over sunrise. And hey, if it sucks kill the project with silver bullets, a stake to the heart and two pounds of garlic. I'm locked and loaded. Just don't kill an idea before it is even tested ... Why not? What reason is there to stop me from aborting this brain-dead monstrosity before it claims a single user casualty, let alone our reputation? I would have thought that your involvement in PR would have you thinking better. A reputation is something that takes years to establish, and seconds to demolish. You, of all people, should know that. Having an overlay such as this will tarnish Gentoo's reputation. No :-) What reputation are we talking about? The distro that lags in updates behind others? Yes, we are *so*
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Chris Gianelloni wrote: Since when was overlays.gentoo.org supposed to even be a service to our users? As I understand it, the goal was to ease development, not to provide an easy method for half-working ebuilds to make it to our user's machines. Our users are our biggest base of testers, and the point of overlays is to develop and test, so of course one of the goals is to get overlays onto users' (testers') machines. Making testing as easy as possible is important. But it should be clear that it is testing, and if the apps were ready for the real Portage tree, they'd be in it. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 20:32 +0100, Ciaran McCreesh wrote: Huge difference between committing a few things for a person you know, where you have time to review code, and bulk committing random stuff where you don't have time to check anything. That's the deal here -- if a large number of developers can't handle maintainer-wanted, what makes people think a far smaller number can without screwing up? *ding* *ding* *ding* *ding* *ding* We have a winner! What do we have for our winner, today, Dianne? Isn't that nice, a turkey baster! ;] -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 20:32 +0100, Ciaran McCreesh wrote: On Fri, 09 Jun 2006 20:06:04 +0100 Christel Dahlskjaer [EMAIL PROTECTED] wrote: | I'd say that it's entirely possibly for some non-dev to sneak | malicious code into the tree as is now, just as it will be possible | to do in an overlay. | | It's not like it's particulary difficult to have someone proxy for | you, and let's face it, if someone is willing to do so then they | probably can't be arsed checking that what they are committing is | clean and nice.. I mean, I trust you, right? Huge difference between committing a few things for a person you know, where you have time to review code, and bulk committing random stuff where you don't have time to check anything. That's the deal here -- if a large number of developers can't handle maintainer-wanted, what makes people think a far smaller number can without screwing up? I was actually agreeing with you. I also believe to be mistaken as I believed that all overlays on o.g.o would be in the style of say the existing PHP and Haskell overlays, and as such those with access would be trusted contributors, and I also believed that the individual projects would be making sure that they were testing and reviewing whatever patches were made to their stuff. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 22:51 +0200, Patrick Lauer wrote: On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote: [snip] If someone wanted to exploit boxen he'd use a much simpler attack vector ... our rsync mirrors are wide open. No need to secure the little window over there when the front door is open ... Really? I'd like you to give me root on rsync.gentoo.org, then. What's that? You can't? What a wonder! I don't need that ... Look, three-step plan to hacking Gentoo boxen: 1) open a few rsync mirrors and get them into the official rotation Umm... the rsync servers in rsync.gentoo.org are all controlled by infra now. If you're using another rsync server (read, untrusted) then you get what you deserve. ;] -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 20:12 +0200, Jakub Moc wrote: Peper wrote: well. A couple of examples: http://bugs.gentoo.org/show_bug.cgi?id=122500 And again, you use my project of an example. Perhaps you should try looking at something that actually supports your argument? I think it's an example of how user-friendly is bugzilla... Yeah, exactly... I don't understand where did this idea of me using someone else's own project against himself came from in the first place. *confused* I've merely posted a few examples illustrating that bugzilla and attachments suck big time for new ebuilds' development. Or, why did you switch vmware-server work to SVN if bugzilla is *the* place for all this? Apparently it's not all that great, otherwise you wouldn't have done that. #1. *I* (as the vmware team) didn't do it, the (then) user who posted the package did #2. We also built it up as the entire vmware overlay... it had little to do with any limitations in bugzilla, and more to do with my already-established desires to make maintaining vmware-* easier This really is a case of you not knowing what the actual facts were in regards to the situation, yet pointing it out as some kind of corroborating evidence for your argument. This is definitely not the case. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Patrick Lauer wrote: On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote: [snip] If someone wanted to exploit boxen he'd use a much simpler attack vector ... our rsync mirrors are wide open. No need to secure the little window over there when the front door is open ... Really? I'd like you to give me root on rsync.gentoo.org, then. What's that? You can't? What a wonder! I don't need that ... Look, three-step plan to hacking Gentoo boxen: 1) open a few rsync mirrors and get them into the official rotation Actually, the only rotation you can get on is a community one (which minimizes the amount of users). All the servers under rsync.g.o are strictly controlled by infra. So nice try ... -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 9 Jun 2006 11:24:34 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | On 6/9/06, Edward Catmur [EMAIL PROTECTED] wrote: | With an overlay: search sunrice.gentoo.org for the package | | If you want people to debate seriously with you, stop calling this | project 'sunrice'. Why? It's a small amount of mild entertainment in what is otherwise a highly depressing state of affairs. It doesn't in any way detract from the other valid points he raised. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, Jun 09, 2006 at 05:22:18PM -0400, Chris Gianelloni wrote: On Fri, 2006-06-09 at 22:51 +0200, Patrick Lauer wrote: On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote: [snip] If someone wanted to exploit boxen he'd use a much simpler attack vector ... our rsync mirrors are wide open. No need to secure the little window over there when the front door is open ... Really? I'd like you to give me root on rsync.gentoo.org, then. What's that? You can't? What a wonder! I don't need that ... Look, three-step plan to hacking Gentoo boxen: 1) open a few rsync mirrors and get them into the official rotation Umm... the rsync servers in rsync.gentoo.org are all controlled by infra now. If you're using another rsync server (read, untrusted) then you get what you deserve. ;] Right. Besides all distro suffer this same problem, indeed shouting that our mirror system is a wide open door is far from being fair. This new project though could be a nice attack vector, in the FAQ you state that you don't allow eclasses, that's nice...but I can think thousand of other ways for compromises without them using ebuilds. Not pointing fingers here, just stating that if this is an official project (whatever that means)...or even if it's not, much caution is advised security-wise in who you trust and what you are going to put in the tree (and most important what the perception of your authority/reliability will be user-wise). Cheers -- Andrea Barisani [EMAIL PROTECTED].*. Gentoo Linux Infrastructure Developer V ( ) PGP-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc ( ) 0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E^^_^^ Pluralitas non est ponenda sine necessitate -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote: Since when was overlays.gentoo.org supposed to even be a service to our users? As I understand it, the goal was to ease development, not to provide an easy method for half-working ebuilds to make it to our user's machines. What's the point of development if not to help users? Everything we do should be done to help users (and worst case we help that small group of users that are devs). This means it *CANNOT* be left up to a small group of developers to decide without any discussion on the matter. So now we're a democracy where everything needs to be voted upon? Anything this abhorrently stupid doesn't need a vote. Bullshit. If you need to resort to insults you failed to show on a technical level why it is bad. It should be cast out on its complete lack of merit, alone. Also, at no point did I ever ask for a vote. Don't put words in my mouth and I'll try to pretend like I care what you say, OK? So now you're El Cheffe? And please, stop sounding like my father. *sigh* Let's leave that debate for another day ... You brought it up, not I. Feel free to debate it with yourself until you're blue in the face. I debated it for about 27 seconds, seems quite obvious now. Thanks for the hint. Yes, now it is easier to check out the ebuilds. More users == better testing. Except that now the developer has to do much more work to get the same information, making it even less likely that he'll bother to pick up one of these maintainer-wanted bugs. s/the developer/I/ You're right... I had that wrong. s/the developer/the developers/ After all, there have been quite a number of people agreeing with me. That's a non sequitur. There's also quite a number of people agreeing with me, but that doesn't make any point of view better or more thruthful. So either we try to discuss in the hope of finding a compromise or we do a headcount and do something stupid. I'd prefer a discussion, but if you just want to HULK SMASH SUNRISE I won't stop you. there are some devs that would prefer this overlay environment. Please don't push your personal preferences as The Right Way (tm) Ehh. Were you an ebuild developer, your opinion might actually count for something when it comes to an ebuild development discussion. By the way, where's the GWN this week? Ulrich is MIA, nothing I can change. He does that from time to time. I'm glad your faith in them is so high. My faith in *any* group this small having the ability to watch over a large number of outside contributors simply isn't there. Let it grow. Slowly. Either it stands on its own or it dies from lack of interest. That doesn't stop me from giving out access to my server to anyone who has a good reason ... like the Gentoo/HURD repository or the Java overlay. Well, we thank you for your immense self-sacrifice. What this has to do with the topic at hand, I have no idea. Well ... think about it. It's kinda obvious once you grok it. Just don't kill an idea before it is even tested ... Why not? What reason is there to stop me from aborting this brain-dead monstrosity before it claims a single user casualty, let alone our reputation? I would have thought that your involvement in PR would have you thinking better. A reputation is something that takes years to establish, and seconds to demolish. You, of all people, should know that. Yes. But killing an idea like this seems almost as damaging to me. There's a group of devs thinking Hey, how can we make things better?. They come up with a few ideas, throw away those that are just not feasible. Then they have one idea that looks useful, they try to implement it. So either you convince those people (with whom I am only tangentially involved) that it is a bad idea or you let them do their thing. I think what is more damaging to the reputation of Gentoo is the incessant discussion of ideas before they are even tried, killing many good things before they even have a chance on a technical level. Yes, we are *so* lagged behind everyone else. Where do you come up with these facts anyway? I'd like to visit this mythical land. Like, gcc 4 ? Gentoo is lagging behind most others (because our QA has grown from non-existant to really really good) Sidenote: I don't mind that at all. But I see a split here ... one group going the debian route of making everything really really stable. And the other group that doesn't mind mild b0rkage, but wants to be on the bleeding edge. Those two populations will be hard to reconcile. Give the second group a sandbox and the first group can do their thing much easier ... Where you see a problem I see potential: More well-tested ebuilds, recruiting potential developers ... if you don't want that you're an elitist bastard. ;-) Aww, how sweet. We've started the name calling. Don't act that surprised, it looks fake. I'd appreciate it
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
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
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Markus Ullmann wrote: 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. Thanks for the clarification. To clarify my point, I'm all for helping our distro, but I just don't want this project to be labeled as a more official BMG. If you suit the needs of what the devs think is the right way to do this, then I'm all for it. I just noticed several mails from the project that seemed to be ignoring the issues at hand and I wasn't going to support the project on infra if they continued to be like that. Thanks for answering most of those questions. I'll let the developer community decide if they like them or not :-). -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, Jun 08, 2006 at 08:58:48PM +0200, Markus Ullmann wrote: 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. It's not a normal overlay as I see it. You've promoted it to be an official overlay. The difference is huge in my opinion. 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. Will you also review the code each and every ebuild pull down over the internet? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpbX3aW1uIEb.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thursday 08 June 2006 20:58, Markus Ullmann wrote: 3) replacement for bugs.g.o I would prefer if people would still comment on the bugs when they do some changes on the overlay so that at least we know that. 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. This is appreciated. On this note, I would like to ask what are you going to do with eclasses. From my POV I'd ask to absolutely _not_ touching eclasses at all in the overlay. I have bad past experiences with overlays replacing eclasses. As bad as with xgl overlay rewriting some of the kde packages and breaking then with gcc 4.1 :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpO5e5GSRzQc.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Чтв, 2006-06-08 at 21:20 +0200, Henrik Brix Andersen wrote: It's not a normal overlay as I see it. You've promoted it to be an official overlay. The difference is huge in my opinion. IMO such overlay should be official! Why not to keep all (partially) broken ebuilds in one place? This is the same story as with German gentoo forum that is outside gentoo.org and thus none of devs wanted to keep eyes there, so forum became much less useful. Another problem with BMG is that it is gnome oriented, as cleary stated on About page and thus I never thought that my, fex, www-apps could be there. 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. Will you also review the code each and every ebuild pull down over the internet? And that is really exciting moment. :) The main difference between such overlay and wiki is that reading text never does `rm -rf /`. How can one stop such jokes? I think if this problem will be solved such overlay should be. Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Чтв, 2006-06-08 at 21:20 +0200, Henrik Brix Andersen wrote: It's not a normal overlay as I see it. You've promoted it to be an official overlay. The difference is huge in my opinion. IMO such overlay should be official! Why not to keep all (partially) broken ebuilds in one place? This is the same story as with German gentoo forum that is outside gentoo.org and thus none of devs wanted to keep eyes there, so forum became much less useful. Another problem with BMG is that it is gnome oriented, as cleary stated on About page and thus I never thought that my, fex, www-apps could be there. 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. Will you also review the code each and every ebuild pull down over the internet? And that is really exciting moment. :) The main difference between such overlay and wiki is that reading text never does `rm -rf /`. How can one stop such jokes? I think if this problem will be solved such overlay should be. Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Henrik Brix Andersen wrote: It's not a normal overlay as I see it. You've promoted it to be an official overlay. The difference is huge in my opinion. Well partly you're right. As it is promoted that way it is a bit more official but anyway still an overlay. Will you also review the code each and every ebuild pull down over the internet? Well at least briefly. We decided to maintain it in an official way and thus keep an eye on the quality of the checkins. As said, at least a briefly view at it and also a repoman scan. We're going to have some contributors at it so it wouldn't be an easy job but I think we can get some more of them that way. Searched my inbox and found a mail saying this: --- Paste --- He was trying to recruit me as a Gentoo developer. Unfortunately, I turned him down, the main reason being time. Also, I don't really need/want the status/powers/responsibilities that come with being a developer, so that was another reason. He then suggested that I become an arch-tester, or maybe contribute to this public overlay that you have in mind. The arch-tester position didn't seem that appealing to me. The public overlay on the other hand is more suitable for me. I like to write the occasional ebuild and there are some ebuilds writen by me in Bugzilla that are currently assigned to maintainer-wanted so getting these in an overlay would be nice. Also, I would assume that the barrier of entry and time requirements are lower than the developer position. --- Paste --- Sounds he likes to contribute / maintain some apps, just not the whole thing you have to do when being a full dev. But he expressed his interest in this as a possible entry point. So I guess we can keep an eye on him... But one thing is important: As the project has some overlay nature, there _may_ be the one or other small issue with it. On the other hand what ebuild is 100% bugfree? ;) QA would have nothing todo then... And here we don't break the (stable) tree if some really nasty issue ever slips through our fingers. Greetz, Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, 08 Jun 2006 23:52:50 +0400 Peter Volkov (pva) [EMAIL PROTECTED] wrote: | Will you also review the code each and every ebuild pull down over | the internet? | | And that is really exciting moment. :) The main difference between | such overlay and wiki is that reading text never does `rm -rf /`. How | can one stop such jokes? I think if this problem will be solved such | overlay should be. Somehow I think certain people aren't quite grasping the potential security breaches with this whole thing... Slipping in malicious and hard to detect code that gets executed by everybody is very very easy. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On 6/8/06, Henrik Brix Andersen [EMAIL PROTECTED] wrote: Will you also review the code each and every ebuild pull down over the internet? The policy for overlays.gentoo.org hosting [1] is hopefully clear: as the project leads, they're ultimately responsible (and therefore accountable) for what goes into their project overlay - no matter whether it's committed by a dev or by a user who has been entrusted with commit rights to the overlay. The policy for what can go into an overlay is also hopefully clear: overlays are for package trees, their patchsets, any docs, and any downloadable tarballs that have nowhere else to be hosted. It's not there to be $UPSTREAM, except for eselect modules, -config scripts and the like that exist purely to support ebuilds in the package tree. I expect projects and developers who are using overlays to be respectful of others. The whole point of the overlays project is to continue our work in trying to get our users much more involved in developing Gentoo. It's there to be a stepping stone for getting packages into the tree - although I do not expect every package in overlays to end up in the tree. Any hostile hijacking of other people's packages doesn't fit into that vision, and there's no place for it on o.g.o. I also expect projects and developers who are not using overlays to be equally respectful of those who are. There are projects and developers who find overlays an excellent way of safely testing and developing ebuilds, and who find overlays to be a good way to help train and develop the next generation of Gentoo developers (good developers are something we really need more of). If any overlay is ultimately an abuse of the hosting that the overlays project provides, then your first course of redress is with the overlay's owner. If you're still unhappy, then come and talk to me as the Overlays Project team lead. I'm here to listen, and if necessary to act. If I don't agree, you can still go to the Council as a last resort if you feel that strongly about it. [1] http://www.gentoo.org/proj/en/overlays/policy.xml Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, Jun 08, 2006 at 09:35:07PM +0100, Ciaran McCreesh wrote: On Thu, 08 Jun 2006 23:52:50 +0400 Peter Volkov (pva) [EMAIL PROTECTED] wrote: | Will you also review the code each and every ebuild pull down over | the internet? | | And that is really exciting moment. :) The main difference between | such overlay and wiki is that reading text never does `rm -rf /`. How | can one stop such jokes? I think if this problem will be solved such | overlay should be. Somehow I think certain people aren't quite grasping the potential security breaches with this whole thing... Slipping in malicious and hard to detect code that gets executed by everybody is very very easy. My point exactly. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpFg6scJLgGu.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, Jun 08, 2006 at 10:05:38PM +0100, Stuart Herbert wrote: On 6/8/06, Henrik Brix Andersen [EMAIL PROTECTED] wrote: Will you also review the code each and every ebuild pull down over the internet? The policy for overlays.gentoo.org hosting [1] is hopefully clear: as the project leads, they're ultimately responsible (and therefore accountable) for what goes into their project overlay - no matter whether it's committed by a dev or by a user who has been entrusted with commit rights to the overlay. [snip] I don't really see how this answers my question, but I do appreciate the summary of the policy for overlays.g.o. I have no problems with the overlay project in general - my concern is about the Sunshine project. [1] http://www.gentoo.org/proj/en/overlays/policy.xml While reading the policy above, I stumbled across this line: Bug Tracking: bugs.g.o is the OneTrueBugTrackingSystem(tm), even for overlays. Could you please elaborate on this? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpnHA655xWmO.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, 2006-06-08 at 20:58 +0200, Markus Ullmann wrote: 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. 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 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 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 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 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. 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
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Hi Henrik, On 6/8/06, Henrik Brix Andersen [EMAIL PROTECTED] wrote: While reading the policy above, I stumbled across this line: Bug Tracking: bugs.g.o is the OneTrueBugTrackingSystem(tm), even for overlays. Could you please elaborate on this? Sure ... in the discussion we had on -dev earlier in the year about the overlays service, it was agreed that we wouldn't maintain separate bug tracking systems for each overlay. All the bugs for each overlay will go into bugs.gentoo.org. This means that the following cycle can happen: a) User A submits ebuild via bugzilla b) Developer takes ebuild from bugzilla, and adds it to overlay for testing fixing c) User B submits bug in bugzilla about the ebuild in the overlay For example, we've been working that way in the webapps overlay for some months now, and it's worked well for us (although we haven't been using bugzilla until this week). Hope that answers your question. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, 2006-06-08 at 21:57 +0200, Markus Ullmann wrote: Well at least briefly. We decided to maintain it in an official way and thus keep an eye on the quality of the checkins. As said, at least a briefly view at it and also a repoman scan. A repoman scan won't catch subtle bugs caused in other packages by packages in this overlay. It *will* add extra maintenance to any package maintainer within Gentoo. Sounds he likes to contribute / maintain some apps, just not the whole thing you have to do when being a full dev. But he expressed his interest in this as a possible entry point. So I guess we can keep an eye on him... Yes. This person is also fully capable of continuing to provide ebuilds to bugzilla. But one thing is important: As the project has some overlay nature, there _may_ be the one or other small issue with it. On the other hand what ebuild is 100% bugfree? ;) QA would have nothing todo then... And here we don't break the (stable) tree if some really nasty issue ever slips through our fingers. No, but the ebuilds are also checked by the team in question, that actually knows the packages, versus a couple of developers that will be overworked, dealing with packages that they are completely unfamiliar with and have no experience with. I just don't see the two as equal in any way. I also do not see how this helps Gentoo development. The only thing that this does is allows for a few packages that hardly anyone is interested in having become available for our users. That's a noble effort, but there's usually a reason why these packages do not get picked up. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, 2006-06-08 at 21:35 +0100, Ciaran McCreesh wrote: On Thu, 08 Jun 2006 23:52:50 +0400 Peter Volkov (pva) [EMAIL PROTECTED] wrote: | Will you also review the code each and every ebuild pull down over | the internet? | | And that is really exciting moment. :) The main difference between | such overlay and wiki is that reading text never does `rm -rf /`. How | can one stop such jokes? I think if this problem will be solved such | overlay should be. Somehow I think certain people aren't quite grasping the potential security breaches with this whole thing... Slipping in malicious and hard to detect code that gets executed by everybody is very very easy. You mean like: perl -e 'print i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' I'm sure everyone will get what that means in a quick cursory glance... and of course repoman will know what it does, right? *grin* -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Chris Gianelloni wrote: No, but the ebuilds are also checked by the team in question, that actually knows the packages, versus a couple of developers that will be overworked, dealing with packages that they are completely unfamiliar with and have no experience with. I just don't see the two as equal in any way. I also do not see how this helps Gentoo development. Being able to maintain these ebuilds in version control rather than random attachments to bugzilla is a huge improvement. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
First let me state this one really important thing: The sunrise project is a project on its own. We're about to convert it to a TLP to make clear that it shares nothing with the overlay project except the hardware ressources and the overlay feature of portage. Chris Gianelloni wrote: On Thu, 2006-06-08 at 20:58 +0200, Markus Ullmann wrote: To clarify things a bit (hopefully): 1) security 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. You're right here, there is a chance that your system gets vulnerable. But this isn't limited to this one overlay. All overlays are affected here. 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 The problem is that you are only checking on the initial commit. Go back to point #1 (security). You just assume this, no real reason/example for it. 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. First let me say this. We don't blindly commit things here nor do we commit everything from m-w bugs. There is this interface inbetween called human intelligence. So I can convince you that I do look at things that are committed. 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. Well if you can look / test a bit easier, that helps a lot... Some (won't exclude myself here) are just a bit lazy if they see a bunch of things to download, rename and move instead of a single checkout command ;) 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. 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. You don't need a subversion client, you perhaps notice the http in front of the url.. just open it up in your browser and you get the source immediately. Or, if you want some history like sources.g.o, you can do so as well here: http://overlays.gentoo.org/proj/sunrise/browser/ 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. Except that I can *look* at an ebuild without having to break out a subversion client currently. See my answer in 3) 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? Well as the ebuilds in there already have open bugs, comments can be attached there. Secondly, the portage team already integrates a patch to show you a bright warning in the error that you use an overlay... also, if you take a look at the PORTDIR_OVERLAY in emerge --info, you can get really fast that in case you don't find the ebuild in tree that it doesn't belong there. (We even get bugs originating at other overlay's ebuils...) All of
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, 2006-06-08 at 15:22 -0700, Donnie Berkholz wrote: Chris Gianelloni wrote: No, but the ebuilds are also checked by the team in question, that actually knows the packages, versus a couple of developers that will be overworked, dealing with packages that they are completely unfamiliar with and have no experience with. I just don't see the two as equal in any way. I also do not see how this helps Gentoo development. Being able to maintain these ebuilds in version control rather than random attachments to bugzilla is a huge improvement. Of course they would be, to the team in question. To a few random developers being responsible for *any* kind of package, it won't make much difference since their familiarity level is very near zero. Good examples of this *working* are php, webapps, or even vmware. Bad examples would be this overlay. Instead of a directed and focused overlay, designed to ease testing and development on otherwise intrusive changes to the tree, it is a dumping ground for ebuilds that either weren't good enough, or weren't interesting enough for inclusion. Either that, or they're ebuilds related to an already-established project where the team members simply don't have the time. This is probably the only case where the ebuilds in question might make it into the tree after being in this overlay. This overlay is a dumping ground for the barely-wanted, and little more. As I have said, I don't see it actually improving the situation nearly as much as it will be detrimental to it. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 00:30 +0200, Markus Ullmann wrote: 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. You're right here, there is a chance that your system gets vulnerable. But this isn't limited to this one overlay. All overlays are affected here. Not like you think that they are. Let me try to make this clearer. The php overlay is maintained by the php developers. They are intimately aware of the issues with their package, and are probably aware of any security bugs before the rest of us. You are talking about a random collection of ebuilds with absolutely no cohesiveness other than they were submitted to bugzilla. How are you going to maintain any form of security on this project? 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 The problem is that you are only checking on the initial commit. Go back to point #1 (security). You just assume this, no real reason/example for it. No. It clearly says that you would be doing the basic QA checks and repoman checking on initial commit. You even said it right above where I commented! 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. You don't need a subversion client, you perhaps notice the http in front of the url.. just open it up in your browser and you get the source immediately. Umm... so now I need to go and instead of clicking a nice link in bugzilla, trawl through the subversion repository and find what I'm looking for? How exactly is downloading things via http any different than downloading them from bugzilla, which is also http? Now, I know that you're not an idiot, so please don't treat me like one. Or, if you want some history like sources.g.o, you can do so as well here: http://overlays.gentoo.org/proj/sunrise/browser/ Excellent. So we're moving the history from being in a single location (the bug) to being in multiple locations. That will definitely improve the development process. Another thing that people tend to miss is that not all improved versions of ebuilds submitted to bugzilla are done byt he original authors. There are many cases where an initial ebuild is done, a developer makes comments on what needs to be changed, and *another* contributor gives a fixed ebuild. How exactly will this streamline that process? No offense, but everything I have seen looks as if it will add even *more* overhead to actually getting packages into the tree. The only thing this seems to provide is a half-baked repository for the users to get marginally-tested ebuilds for software that wasn't interesting enough for inclusion in the tree. Except that I can *look* at an ebuild without having to break out a subversion client currently. See my answer in 3) See mine. ;] 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? Well as the ebuilds in there already have open bugs, comments can be attached there. This is a bug for an ebuild that the user does not think is related to the pam_skey. Go back and read what I wrote. Secondly, the portage team already integrates a patch to show you a bright warning in the error that you use an overlay... also, if you take a look at the PORTDIR_OVERLAY in emerge --info, you can get really fast that in case you don't find the ebuild in tree that it doesn't belong there. (We even get bugs originating at other overlay's ebuils...) Again, read what I wrote. I said that the developer would see sunrise in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated without considering. This is a login bug. At no point did they make mention of having installed pam_skey from this overlay. This means that I, as the developer getting this bug, am now responsible for looking at *every package* in the sunrise overlay to determine if *any* of them could *possibly* be affecting this package or causing this bug, then asking the user if they have any of them installed. Wouldn't this process be *infinitely* easier if instead of sunrise there was a pam overlay with *only* the pam
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Chris Gianelloni wrote: On Fri, 2006-06-09 at 00:30 +0200, Markus Ullmann wrote: 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. You're right here, there is a chance that your system gets vulnerable. But this isn't limited to this one overlay. All overlays are affected here. Not like you think that they are. Let me try to make this clearer. The php overlay is maintained by the php developers. They are intimately aware of the issues with their package, and are probably aware of any security bugs before the rest of us. You are talking about a random collection of ebuilds with absolutely no cohesiveness other than they were submitted to bugzilla. How are you going to maintain any form of security on this project? The approach is to get them maintained... But there is a chance that there'll be security bugs in it, I admit that. Once we know about it, we p.mask it as we have support for it in the overlay. I'm following most common vuln lists and run some automated scripts already on installed packages, should be easy to adapt them to search one other dir as well. 2) responsibility No. It clearly says that you would be doing the basic QA checks and repoman checking on initial commit. You even said it right above where I commented! You're doing some witch hunting here... I said we keep an eye on non-devs commits. 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. You don't need a subversion client, you perhaps notice the http in front of the url.. just open it up in your browser and you get the source immediately. Umm... so now I need to go and instead of clicking a nice link in bugzilla, trawl through the subversion repository and find what I'm looking for? How exactly is downloading things via http any different than downloading them from bugzilla, which is also http? the key difference is that you only need one wget command to get a completely prepared dir to work on, no ebuild renaming manual files/ population needed. Now, I know that you're not an idiot, so please don't treat me like one. Was really not the intention.. You keeped the svn requirement which is simply wrong. Needed to make that clear. Or, if you want some history like sources.g.o, you can do so as well here: http://overlays.gentoo.org/proj/sunrise/browser/ Excellent. So we're moving the history from being in a single location (the bug) to being in multiple locations. That will definitely improve the development process. Another thing that people tend to miss is that not all improved versions of ebuilds submitted to bugzilla are done byt he original authors. There are many cases where an initial ebuild is done, a developer makes comments on what needs to be changed, and *another* contributor gives a fixed ebuild. How exactly will this streamline that process? No offense, but everything I have seen looks as if it will add even *more* overhead to actually getting packages into the tree. The only thing this seems to provide is a half-baked repository for the users to get marginally-tested ebuilds for software that wasn't interesting enough for inclusion in the tree. we want to encourage users to contribute and if they do good contributions in bugzilla they get commit access to the overlay. and then the workload is drastically reduced... 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? Well as the ebuilds in there already have open bugs, comments can be attached there. This is a bug for an ebuild that the user does not think is related to the pam_skey. Go back and read what I wrote. it was agreed upon that we don't keep extra bugzilla or whatever for all things on o.g.o but keep track of all issues within bugs.g.o. and btw, most work on new bugs is done by bug wranglers and not the common devs. So if they say the workload from it is too high, I'll take it as valid reason as they have to handle it. Secondly, the portage team already integrates a patch to show you a bright warning in the error that you use an overlay... also, if you take a look at the PORTDIR_OVERLAY in emerge --info, you can get really fast that in case you don't find the ebuild in tree that it doesn't belong there. (We even get bugs originating at other overlay's ebuils...) Again, read what I wrote. I said that the developer would see sunrise in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated without considering. This is a
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 09 Jun 2006 02:49:14 +0200 Markus Ullmann [EMAIL PROTECTED] wrote: | No. It clearly says that you would be doing the basic QA checks and | repoman checking on initial commit. You even said it right above | where I commented! | | You're doing some witch hunting here... I said we keep an eye on | non-devs commits. How much do you want to bet that I couldn't sneak malicious code past you? And if you accept that I could do it, you're also admitting that quite a few other random people, some of whom don't share my own ethical objections to such a stunt, could also pull it off given sufficient time and effort... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Stuart Herbert wrote: On 6/8/06, Henrik Brix Andersen [EMAIL PROTECTED] wrote: Will you also review the code each and every ebuild pull down over the internet? The policy for overlays.gentoo.org hosting [1] is hopefully clear: as the project leads, they're ultimately responsible (and therefore accountable) for what goes into their project overlay - no matter whether it's committed by a dev or by a user who has been entrusted with commit rights to the overlay. The policy for what can go into an overlay is also hopefully clear: overlays are for package trees, their patchsets, any docs, and any downloadable tarballs that have nowhere else to be hosted. It's not there to be $UPSTREAM, except for eselect modules, -config scripts and the like that exist purely to support ebuilds in the package tree. I expect projects and developers who are using overlays to be respectful of others. The whole point of the overlays project is to continue our work in trying to get our users much more involved in developing Gentoo. It's there to be a stepping stone for getting packages into the tree - although I do not expect every package in overlays to end up in the tree. Any hostile hijacking of other people's packages doesn't fit into that vision, and there's no place for it on o.g.o. I also expect projects and developers who are not using overlays to be equally respectful of those who are. There are projects and developers who find overlays an excellent way of safely testing and developing ebuilds, and who find overlays to be a good way to help train and develop the next generation of Gentoo developers (good developers are something we really need more of). That is being done with the per-group overlays. No need to have a maintainer-wanted official overlay for it. -- gentoo-dev@gentoo.org mailing list
