[gentoo-dev] Re: Project Sunrice: arch team perspective
Stephen P. Becker wrote: Starting a new thread here for a new angle... As Stuart mentioned, bugs for any ebuild on o.g.o would go through Gentoo bugzilla. Yeah, as there is usually a bug report for maintainer-wanted and maintainer-needed bugs it wont hurt anyone. It seems like genstef and jokey have completely ignored support from arch teams for this overlay. What are you proposing with respect to arch keywords and package.mask? users are supported to do everything themselves in the sunrise overlay. We are not trying to add any additional workload to your current one. We are in fact trying to make life easier for everyone. Do you actually expect us to do anything but close assigned bugs for sunrice ebuilds as WONTFIX? It is more like, explain the users how to fix it themselves, because they can with the sunrise overlay. Where else would these bugs go except for arch teams, seeing as we clearly can't assign them to end users who originally submitted the maintainer-wanted ebuilds? These are not expected to be filed as bugs, they should be fixed by the users in question. - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Project Sunrice: arch team perspective
Where else would these bugs go except for arch teams, seeing as we clearly can't assign them to end users who originally submitted the maintainer-wanted ebuilds? These are not expected to be filed as bugs, they should be fixed by the users in question. Apparently, this is not the case. Policy for overlays.gentoo.org stipulates that all bugs in overlays must use our bugzilla. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Project Sunrice: arch team perspective
On 6/9/06, Stephen P. Becker [EMAIL PROTECTED] wrote: Apparently, this is not the case. Policy for overlays.gentoo.org stipulates that all bugs in overlays must use our bugzilla. The intention of the policy is to prevent the use of third-party bug trackers for tracking problems w/ ebuilds in overlays. There's no requirement that developers and users must use bugzillla to track changes to ebuilds (which is what I believe Stefan was trying to say). Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Project Sunrice: arch team perspective
On Fri, 2006-06-09 at 15:35 +0200, Stefan Schweizer wrote: It seems like genstef and jokey have completely ignored support from arch teams for this overlay. What are you proposing with respect to arch keywords and package.mask? users are supported to do everything themselves in the sunrise overlay. We are not trying to add any additional workload to your current one. We are in fact trying to make life easier for everyone. Except that you aren't accomplishing this. I have shown lots of points where this will increase workload on an already overworked group of volunteers, yet the proponents of this project are either overlooking them, avoiding them, or simply ignoring them. Do you actually expect us to do anything but close assigned bugs for sunrice ebuilds as WONTFIX? It is more like, explain the users how to fix it themselves, because they can with the sunrise overlay. ...or just mark it as WONTFIX because we won't fix it. It isn't our job to go around policing things that are not in the portage tree. If it was good enough or popular enough to be of concern to us, it would be *IN THE TREE* where it belongs. Why is this so hard to understand? Where else would these bugs go except for arch teams, seeing as we clearly can't assign them to end users who originally submitted the maintainer-wanted ebuilds? These are not expected to be filed as bugs, they should be fixed by the users in question. So now we will have random users also doing work of the architecture team? How about you guys start building the releases, too? I'm sure you'll have a wonderful time with the reiser4/broken-sources ricer crowd out there. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
