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 in their overlays. That doesn't have anything to do with what I stated. Again, avoiding the issue. > > They do this in a very quick and cursory manner. They do a pretty good > > job of it, but there are countless bugs which they do not catch that are > > not assigned properly or end up being invalid due to user negligence. > > The bug wranglers cannot be *expected* to perform this level of service, > > lest they burn out and run away within a couple weeks. ;] > > Well a simple grep for "sunrise" in there will show the needed thing... So I can mark any bug that has sunrise in it as INVALID, then, because the overlay is going to be known to be in an unmaintained state? Perfect. > And, sorry, if one or another bug slips through. Wranglers are humans as > well and humans make mistakes. Also you can't expect them to know about > all issues. But that is a bit off-topic here. No. It is *exactly* the topic that I am speaking of, which you're avoiding. > Just a last note on it: the main bug wrangler is helping us as well as > commiting so I guess he notices the problems with sunrise... So having one extra man on the team is going to alleviate all of the problems? Excellent. My fears are quelled. > > This is a prime example of totally glossing over any discussion to make > > it sound promising for you. How exactly is a proxy maintainer going to > > know that a new version of an ebuild has been committed? Either by > > watching the overlay like a hawk, or when the maintainer > > emails/pings/whatever and lets him know that there's a new version. How > > exactly is this easier to track? 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? 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? > > Tracking: > First we want people to get used to it. Adding some random features like > automated email upon a special commit can be added easily with just two > lines in the post-commit hook... > > Dev-Overlay: > Well you're free to use the dev overlay for it. But if you keep it on > the sunrise overlay, it (hopefully) gets more tested. No offense, but this email was pretty much useless as you avoided my questions with lots of vague references to how it will make things "better" and didn't bother to actually thoughtfully answer any of my points. I'm through wasting my time with this. If I see a bug with sunrise, it's going INVALID, as it is now apparent to me that the issues with the project won't be resolved. So long, and thanks for all the fish. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
