Re: [gentoo-dev] [warning] the bug queue has 82 bugs
On Sat, 06 Feb 2016 22:02:45 + "M. J. Everitt" wrote: > On 06/02/16 22:00, Alex Alexander wrote: > > Our bug queue has 82 bugs! > > > > If you have some spare time, please help assign/sort a few bugs. > > > > To view the bug queue, click here: http://bit.ly/m8PQS5 > > > > Thanks! > > > Only 82? that's not, like, 4k ... :) > http://tinyurl.com/maintainer-wanted . Yes, that's because this e-mail report is about new and unassigned bug reports, and you're talking about assigned bug reports about new packages. jer
[gentoo-dev] [ANNOUNCE] genkernel 3.5.0.0 release
Hi all, This is a quick announcement of the early testing of the genkernel-3.5.0.0 release. The 3.5.0.x series should NOT be considered as stable candidates. As such, I've also removed ALL keywords from 3.5.0.0. Further 3.5.0.x releases will land other major changes hopefully, including updating the included tools. The 3.5.1.x series will hopefully be the next stable candidate series. 3.5.0.0: - It turns out the generic+per-arch config was previously merging fragments in the wrong order. Generic settings were overriding per-arch, instead of the opposite. Furthermore, because of this, many arches had a kernel config that had a high chance of being unbootable, if it even compiled. - Many options that included debugging in the generated kernel configs are now disabled. This returns behavior to the older static kernel configs that had these debug options disabled. See these commits for further info: 247626b6d8b30eb3ed13cb23226c149169607c5e 945a877a0277befb1fa21281e61ae138af19d356 333a300e9f40996750a2622c634b0ca5a04469ab The following architectures are presently SUPPORTED for automatic kernel configuration: - alpha - ppc - ppc64 - x86 - x86_64 The following architectures are presently UNSUPPORTED for automatic kernel configuration (but may have static configs): - arm - ia64 - mips - parisc - parisc64 - s390 - sparc - sparc64 - um Arch Teams: If you want to get automatic kernel config support, please review arch/*/arch-config from a supported architectures, and provide a good hardware-agnostic version for your arch. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] [warning] the bug queue has 82 bugs
On 06/02/16 22:00, Alex Alexander wrote: > Our bug queue has 82 bugs! > > If you have some spare time, please help assign/sort a few bugs. > > To view the bug queue, click here: http://bit.ly/m8PQS5 > > Thanks! > Only 82? that's not, like, 4k ... :) http://tinyurl.com/maintainer-wanted .
[gentoo-dev] [warning] the bug queue has 82 bugs
Our bug queue has 82 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM
On Fri, Feb 5, 2016 at 3:07 AM, Michał Górny wrote: > Dnia 5 lutego 2016 07:38:44 CET, Jason Zaman > napisał(a): >>On Thu, Feb 04, 2016 at 04:35:44PM -0600, Gordon Pettey wrote: >>> On Thu, Feb 4, 2016 at 6:17 AM, Kent Fredric >><[1]kentfred...@gmail.com> >>> wrote: >>[ ... ] Its really sad we can't just have what Paludis does, package.use side support for USE_EXPAND. www-servers/nginx normal_use_flags NGINX_MODULES: http_access http_auth_basic http_autoindex Or similar. >>> >>> But we can do exactly that, as of at least portage-2.2.24, possibly >>> earlier. >> >>Whoa that I was unaware of. This is amazing and makes USE_EXPAND much >>less important to me :D > > Exactly. Furthermore, I wanted to deprecated setting flags via make.conf and > switch to pure package.use alike paludis but met the usual resistance. I don't remember such a thread, but I'm not surprised. FWIW, I think the idea has merit.
Re: [gentoo-dev] Automatic Bug Assignment
On 02/06/2016 10:35 AM, Andrew Savchenko wrote: > Automation can go further: if there are multiple maintainers, > assign bug to the first one and CC others. Which is exactly what I'm doing in my tinderbox: # get assignee and cc, GLEP 67 simplifies it # m=$(equery --no-color meta -m $curr 2>/dev/null | grep '@' | xargs) if [[ -z "$m" ]]; then m="maintainer-nee...@gentoo.org" fi echo "$m" | cut -f1 -d ' ' > $issuedir/assignee echo "$m" | grep -q ' ' if [[ $? -eq 0 ]]; then echo "$m" | cut -f2- -d ' ' | tr ' ' ',' > $issuedir/cc else echo "" > $issuedir/cc fi :-D -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
[gentoo-dev] Packages Up For Grabs
Hey, I spoke with steveeJ the maintainer of app-emulation/rkt and that package is also without a maintainer. Please, feel free to take app-emulation/rkt, and if we're still the maintainers in two weeks, I'll mark it as maintainer-needed. Short: app-emulation/rkt will be marked maintainer-needed in two weeks if not claimed. Regards, -- Alex Brandt Software Developer for Rackspace and Developer for Gentoo http://blog.alunduil.com signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Automatic Bug Assignment
On 7 February 2016 at 04:26, William Hubbs wrote:
> One concern I see with making this part of the web ui for Bugzilla is
> that Bugzilla would have to be able to parse the metadata.xml files in
> our portage tree to find the maintainers.
You could simplify it with a cron job that parses metadata.xml and
creates a quick lookup table of:
cat/pn => {
maintainers => [ ],
bgo_category => $N
}
And then Bugzilla would just have to query some endpoint/index and
fetch the matching result.
--
Kent
KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Automatic Bug Assignment
On Sat, Feb 06, 2016 at 09:09:13AM +0100, Patrick Lauer wrote: > On 01/30/2016 06:45 PM, Alex Brandt wrote: > > Hey Guys, > > > > I've oft wondered why we don't automatically assign bugs to the > > ebuild maintainer (if a CPV is in the subject). Would there be an > > issue with adding a bug modification hook to bugzilla or a daily > > job to re-assign bugs to ebuild owners (if a CPV is in the > > subject)? > > > > Just curious not trying to incite anything. > > > > Regards, > > > Maybe we could add a "Assign to maintainer(s)" button visible only to > certain groups of users, so that a bugwrangler who decides this bug is > valid just has to hit one button instead of figuring out the details of > assignment? > > There seems to be valid criticism about fully automating the workflow, > but partial automation can still save huge amounts of time ... One concern I see with making this part of the web ui for Bugzilla is that Bugzilla would have to be able to parse the metadata.xml files in our portage tree to find the maintainers. Something like this could be done pretty easily though with an external program, a python script for example, using Bugzilla's web services API. [1] William [1] https://www.bugzilla.org/docs/5.0/en/html/api/Bugzilla/WebService.html signature.asc Description: Digital signature
Re: [gentoo-dev] New virtual: virtual/jack for jack protocol implementations
On 04/02/16 15:05, Alexis Ballier wrote: > Hi, > > We've been supporting jack sound server [1] for a long time. > Currently, we're supporting jack1 as > media-sound/jack-audio-connection-kit. However, jack2 has been out for > quite some time. > > As its name does not imply, jack2 is not really the successor of jack1 > but rather another implementation of the same protocol [2]. As such, I > don't think it is wise to add jack2 as an update to jack1 in > media-sound/jack-audio-connection-kit but rather to add a new package > (media-sound/jack2) along with a virtual that packages can depend onto. > > Proposed ebuild for the virtual is here: > https://github.com/suhr/gentoo/commit/1aebd8e72ff4ff2665761fc3b07f796945aa0943 > > Best regards, > > Alexis. > > > [1] http://www.jackaudio.org/ > [2] > https://github.com/jackaudio/jackaudio.github.com/wiki/Q_difference_jack1_jack2 > Sounds a good idea.
Re: [gentoo-dev] Re: Automatic Bug Assignment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/06/2016 04:43 AM, Duncan wrote: > Talking about which, I've toyed with asking for bug-assignment > privileges for awhile, but haven't known who to ask, or if the > privilege model is fine grained enough to give me that without > giving me stuff I probably shouldn't have. Currently, there exists one method, the editbugs privilege. Basically, a developer sets their Bugzilla to watch the user's and the developer is responsible for making sure the privilege is not abused. As it is right now, it's an all or nothing priv (as far as editing is concerned, still restricted by ACLs out of private bugs, etc) https://bugs.gentoo.org/show_bug.cgi?id=editbugs - -- NP-Hardass -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWtcHuAAoJEBzZQR2yrxj7msMP/A1QtPS0saGRovQJZgwk5GTW vNLxOsqd7w3jwel5sDcnsar9BARj04PdbYmF2baPg8N6rfFmJ+nD47olvym0maI/ JgEVJNiy2H1gJfR7Hz3UGDPeiYUnuQTpFe+fpIRU6yfqTGEIOt96wPX9bhKbp8+y qbkaDfjmFLtvCQDPevvu/UuZHRZWBVvE4yrifOqHoAPeyD13qb3+1+yQdMLFCLxc ZiC25qsHyRuPamzIgPK3CMBHaegGzRmuZ7bhhs90jndyc5OvSaE4E/dsO3PrG69f vacCMY2WTRtbugyVTKKOzoROAd0PWYMvlFQvjJHG6ZQgswd2rlkaYkd4zzL1h2xl l+ToDbZpL3/S9mBjjwObJ3rCGnU8HMdIFy9TRfeJpELdXj9P/6dczhgcsT6Fy3Wl KFSREh7SGPLqc9A4Uddx++uJq/TTcvBRgddc26GEaXbrAra6BfaYqd8mswDCCIM1 H5CE4I0KlISsI2LUpMtRh0RxoqMJ7XwKxyflLvsTM2SkMb9naipriuFJGZZZsApB 6NAuZWhtqtvqa9PT9QdLK5mm1K/XYKqZRZPDzAAs70zcoCEPKqhczPIP3D/e1IHq I/h54ns7OjINRXsY99mGx9ZUSYvKGgD5voxkfQD+sNeBf7HTPAbzyy5+8ZY0juKB xdzySoZX2Vyik7ArQr6Y =iHA4 -END PGP SIGNATURE-
[gentoo-dev] Re: Automatic Bug Assignment
Patrick Lauer posted on Sat, 06 Feb 2016 09:09:13 +0100 as excerpted: > Maybe we could add a "Assign to maintainer(s)" button visible only to > certain groups of users, so that a bugwrangler who decides this bug is > valid just has to hit one button instead of figuring out the details of > assignment? > > There seems to be valid criticism about fully automating the workflow, > but partial automation can still save huge amounts of time ... Talking about which, I've toyed with asking for bug-assignment privileges for awhile, but haven't known who to ask, or if the privilege model is fine grained enough to give me that without giving me stuff I probably shouldn't have. Such a button that could be made available to selected users, or even in general, since we already trust users with setting CC, adding archs, and even (controversially) with setting importance. Arguably, even making this button available to all users would be but a small extension from that. Meanwhile, lately I've started ccing the maintainer, based on equery meta's results for the package. So far for this try I've had good results and faster bug resolution as I effectively bypassed wrangling, but awhile back I tried that on a bug and when wranglers did assign, they didn't take the CC out so the dev was getting two notices on changes and was a bit cranky about that. So I make it a point to mention the CC now, so hopefully if a wrangler gets to it before the CCed dev, they can unCC at the same time they assign. Too bad most of the components aren't fine grained enough to do direct assignment, as they do for kde and (IIRC) portage bugs, for instance. I always thought gentoo's bz organization there was buggy, as it made a lot more sense to me to have say applications or libraries at the product level, and the cat/pkg at the component level, or even category as the product and package as the component. But it was already too late to change that when I became a gentooer in 2004, let alone now. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Automatic Bug Assignment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/05/2016 03:47 PM, Rich Freeman wrote: > On Fri, Feb 5, 2016 at 1:27 PM, Kent Fredric > wrote: >> On 6 February 2016 at 07:19, Rich Freeman >> wrote: >>> 'd be all for automated bug assignment. Usually when this >>> comes up a bunch of hero bug wranglers step up and say it isn't >>> needed, because we have hero bug wranglers. As long as people >>> keep stepping up to do that I'm not going to tell them that >>> they can't. However, if the bug queue ever does go out of >>> control I'd be all for just auto-assigning them. If they >>> rarely get assigned to the wrong people, then they can just >>> reassign them. And nothing stops us from having a bugzilla >>> query for "new bugs filed in last 24h" for people who want to >>> take a quick look at recent bugs for trends or to help clean >>> them up across projects. >> >> >> Hm, or alternatively, you could have a scheme where things >> defaulted in the bug queue, and were auto-assigned where possible >> after no feedback for a time, or maybe it would be defaulted only >> when the queue is over a certain size. >> > > That was my thought around having a query for bugs filed in the > last 24h. Basically they'd be auto-assigned, but people could > choose to review recent bugs to see if any were mis-assigned, and > no action is necessary if they're OK. > > The main problem I see with auto-assignment is that some asignees > end up being black holes for bugs. If two active devs get their > bugs crossed it isn't a big deal since they'll just reassign them > to each other. If an active dev gets their bug assigned to an > inactive dev, they might never hear about it. > As an alternative to bug assignment, which does carry the risk of "black holes," what about automatic bug CC'ing? That gives the likely party the heads up, and if they don't take it, wranglers take over and determine what to do with it. This gives us some degree of automation (automatic notification, but not sorting), and leaves in the space for the wranglers, who I believe are important to getting things where they need to be effectively. - -- NP-Hardass -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWtb6SAAoJEBzZQR2yrxj7n6IQAIcEmhkIUUie4u6DsodgCRSc qnP5cqR9C/0EyXZwQwbntX6Zh18MoFS9/VqQt9kHwFiuqsJaNoxZVMaofM58dwq+ BZN5kq4qVO3TI9gp3D4Y4PlzjnYvOg7eiEPRyHy02ZTvJ/Hjhq4wC2VhIKoTF3EF L5NKqWebwOre62xCHWeCM0EJGrTj/j/ggSrTjMMrpF/iRJM880IA4j+Nqr3CwLkB jH7uM2b2fgjDiyztwKdk90yspax/CBBG0F/XGyuj2bO4BaCCHFD8xDj8lLALkneJ D/ihRjNMkgHW6gHRXhrUfABPFEGULadpXKFt/G7RWi0hcn5fjuoRpaoA8k0z/8wl YxhQFPdTtfgiQhiL2q5wogSzwXbiliWQDeonBnboC+CKqxByEumOYi05jXgGbBx7 mPUcdjKmePbbM4SW/WPbr57HTdMZ2G70EFlg5UNGNN4phvX7T2tz3fiCRLqiO1nm UTbykpwACnVTcWmNFgWD11xg4oISr8kxcoql86bwFJdT3fVGedLNwOE3f6YRryZC mxt/PbqVHiVuFsZTgLHC/NdV52DD9QQhBDaBxZnQKazPDaqVbNyM6fbwf54xDRbZ fO+ZrKix2n+n+aE8bUBmJQ66v8+upBKOSzIu741bW4eKAYdF8+9iJKRVKEhT6Mx2 efg+xYoIkEtrJTKTdKNG =iylA -END PGP SIGNATURE-
Re: [gentoo-dev] Automatic Bug Assignment
On Fri, 5 Feb 2016 16:10:48 -0500 Michael Orlitzky wrote: > On 02/05/2016 03:47 PM, Rich Freeman wrote: > > The main problem I see with auto-assignment is that some asignees end > > up being black holes for bugs. If two active devs get their bugs > > crossed it isn't a big deal since they'll just reassign them to each > > other. If an active dev gets their bug assigned to an inactive dev, > > they might never hear about it. > > > > We already trust users to tell us what went wrong and put bugs in the > right component. I think we can trust the package atom if one exists in > the summary. How about, if there's (exactly) one portage-compatible atom > in the summary and that package has (exactly) one maintainer, we > auto-assign it? Otherwise, leave it to the bug wranglers. Automation can go further: if there are multiple maintainers, assign bug to the first one and CC others. As long as a package have a valid CP, maintainers will see them via a simple bugzilla query. Afaik this is a good idea to loop through all open package bugs before stabilization or version bump. Most (all?) bug wranglers are devs, so their time can be spent for better use, e.g. fixing actual bugs. Anyway bug wranglers will still have job: many bug reports doesn't contain a valid CP. The only concern I have with this: sometimes bug title reference multiple packages and it is possible that it will contain one valid CP and another one will be incomplete/invalid, e.g. "mplayer fails to build with dev-libs/openssl". In this case bug may be improperly auto assigned. But such cases should be quite rare thus tolerable. Another note: atom validity check should be performed for CP, not CPV, since many bugs affect all versions of a package in the tree, I often file such bugs myself :) Best regards, Andrew Savchenko pgp5ykgJ4ZqWv.pgp Description: PGP signature
Re: [gentoo-dev] Automatic Bug Assignment
On 01/30/2016 06:45 PM, Alex Brandt wrote: > Hey Guys, > > I've oft wondered why we don't automatically assign bugs to the > ebuild maintainer (if a CPV is in the subject). Would there be an > issue with adding a bug modification hook to bugzilla or a daily > job to re-assign bugs to ebuild owners (if a CPV is in the > subject)? > > Just curious not trying to incite anything. > > Regards, > Maybe we could add a "Assign to maintainer(s)" button visible only to certain groups of users, so that a bugwrangler who decides this bug is valid just has to hit one button instead of figuring out the details of assignment? There seems to be valid criticism about fully automating the workflow, but partial automation can still save huge amounts of time ...
