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 the possibility to nuke a bad ebuild in the overlay instead of asking some random user to change this in that overlay because of $problem. Maybe we even find some motivated new ebuild monkeys that have the motivation to become devs ... one can always hope :-) Patrick -- Stand still, and let the rest of the universe move
signature.asc
Description: This is a digitally signed message part
