Re: [gentoo-dev] The Plethora of Patches
Andrew D Kirch a écrit : Here's the script that I used to generate this. I have not manually reviewed all of thousands of patches to determine the unique situation of each patch, however I would like a suggestion on how to demonstrate _real_ statistics short of auditing each and every patch in portage which I personally don't have time to do. Then how can you come to the conclusion that all the patches we carry are somehow bad? I won't reiterate what Robin and others have said about various upstreams, but this is a _reality_ we have to work with. Now instead of doubting your stats once again, here's my suggestion : Pick a set of packages you like/use, contact its Gentoo maintainers and ask for more info about the patches we carry in Portage. Chances are, most patches will already be in upstream's BTS or mailing list's archives. But some patches may have been forgotten. Saying we are doing an awful job because $nb_patches 0 is *not* the way to get things moving in the right direction. I for one, want to get $nb_patches closer to 0, but it's an ongoing process, not a goal. And yes, there *will* have to be a review of all epatch and sed lines in all our ebuilds if we want to go in the right direction. Cheers Rémi
Re: [gentoo-dev] [GLEP 56] metadata.xml USE flag descriptions [Clarifications]
Jeroen Roovers wrote: On Wed, 13 Aug 2008 16:13:26 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: What is the benefit? There is none really. Allow all use flags to exist in metadata.xml. It's really more of a clarification to the GLEP if this is allowed. snip [1] Come to think of it, in the recent metadata.xml / no-herd debate, wasn't having an empty herd tag ever suggested? herd / I've been championing that for what feels like 3 years now. The problem is it breaks backwards compat with all tools out there..
Re: [gentoo-dev] [GLEP 56] metadata.xml USE flag descriptions [Clarifications]
On 13:11 Wed 13 Aug , Doug Goldstein wrote: Further questions regarding use.desc have come up with regard to this GLEP. My proposed solution would be a potential amendment to the GLEP to state that flag name='png' / Would be allowed. This syntax is not actually disallowed or allowed by the current GLEP, but mentioning it would allow a metadata.xml contain all the USE flags that appear in IUSE, even the global ones. By using the above syntax, it would simply state that there is no additional descriptions or details but to just use the use.desc description. Further more, it would allow us in the future to make that mandatory and repoman would only have to check metadata.xml for your USE flag. It seems like this doesn't have much benefit and is a bit confusing to me. You now need to know which flags in metadata.xml are global so you don't allow descriptions for them. You also need to verify the globals between the two places they'll be specified (metadata.xml and use.desc for the description) so you don't have things claiming they're global but aren't. The benefit here doesn't end up saving anything at all once you have a consistency check anyway. Halcy0n also mentioned that this gets really annoying when USE flags inherited from eclasses change. You'd need to edit every metadata.xml of all inheriting packages. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpOM2C0Wc6rW.pgp Description: PGP signature
[gentoo-dev] Packages up for grabs
Good afternoon fellow developers, There are three ebuilds that I used to maintain that I no longer have the hardware for. I'm hoping that one of you could give them some love. Do assign the bugs to yourself, and please drop me from the relevant metadata.xml once you do. They are: media-video/nvidia-settings x11-drivers/nvidia-drivers sys-auth/thinkfinger I used to have a Fujitsu-Siemens Lifebook E8410-nVidia with a 8400M G, but have switched to a Lifebook S6410 that has Intel graphics. Previous to said Lifebooks, I used to own a ThinkPad X41. While my new laptops have a fingerprint scanner, it is not of the type that thinkfinger prefers. Regards, Tony V. (Chainsaw) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs
On Mon, Aug 18, 2008 at 04:18:53PM +0100, Tony Chainsaw Vroon wrote: There are three ebuilds that I used to maintain that I no longer have the hardware for. I'm hoping that one of you could give them some love. Do assign the bugs to yourself, and please drop me from the relevant metadata.xml once you do. They are: media-video/nvidia-settings x11-drivers/nvidia-drivers sys-auth/thinkfinger I have taken over x11-drivers/nvidia-drivers, the media-video/nvidia-settings package will continue to be maintained by peper at the moment. Ricardo
Re: [gentoo-dev] Packages up for grabs
On Mon, 2008-08-18 at 16:18 +0100, Tony Chainsaw Vroon wrote: sys-auth/thinkfinger I have a thinkpad with the right hardware, so I can take this one, did you already pimp out your other thinkpad packages? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs
On Mon, 2008-08-18 at 15:14 -0400, Olivier Crête wrote: I have a thinkpad with the right hardware, so I can take this one, did you already pimp out your other thinkpad packages? I don't recall of other thinkpad packages that are still mine, but if you see my name on them, they're all yours. Thanks. Regards, Tony V. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [GLEP 56] metadata.xml USE flag descriptions [Clarifications]
Doug Goldstein wrote: What is the benefit? Regards, There is none really. Allow all use flags to exist in metadata.xml. It's really more of a clarification to the GLEP if this is allowed. Agreed, it has no benefit at all plus would lead to some kind of useless duplication of information. Stating flag name='png' / in metadata.xml for global use flags makes basically no difference to IUSE=png, except that we already have the latter one. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] The Plethora of Patches
Santiago M. Mola wrote: I think that's all we need in order to know how were things when the patch was added and if it needs to be pushed/tracked upstream, removed in the next version of the package, etc. Some of us already put these kind of headers, or at least an URL to upstream bug or a meaningful source of info about the patch. A short description possibly including a reference to an upstream or Gentoo bugreport prefixed to every epatch call should be our minimum standard. Working on packages whose maintainers are MIA isn't always that simple - but it's even worse if you have to check a number of patches to find out what they are for, since when they are in and what their status is ... However, tracking the status of every patch since its inclusion in portage until it's removed would be a huge work overhead... and I doubt it's worthy. I don't think it's a huge work overhead, it'll take an additional minute per included patch to include a minimal description into the ebuild(s) and use a standardized header for the patch. Compared to the time one needs to spend when searching for information on that patch somewhen later on it's worth every minute. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] The Plethora of Patches
On Tue, Aug 19, 2008 at 12:02 AM, Tobias Scherbaum [EMAIL PROTECTED] wrote: Santiago M. Mola wrote: However, tracking the status of every patch since its inclusion in portage until it's removed would be a huge work overhead... and I doubt it's worthy. I don't think it's a huge work overhead, it'll take an additional minute per included patch to include a minimal description into the ebuild(s) and use a standardized header for the patch. Compared to the time one needs to spend when searching for information on that patch somewhen later on it's worth every minute. Of course, puting a header with info in every patch is not a work overhead and I'd say it should be policy. What I meant is that it's no worth to track the status of every patch after it's added, as was suggested. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
John Brooks wrote: Random idea: How about a different bug assignee for maintainer-needed packages with provided ebuilds/patches? Either something generic, or try to go for something more category/package specific (herds, etc). Lots of work for bugwranglers, though. There is a huge difference to developers between an unmaintained package with no progress and just looking over an ebuild that has been used successfully by several people. No need for an additional mail/bugzie alias here, we could simply use a KEYWORD like the existing 'Inclusion' (which isn't used that much for now, 63 open bugs have that keyword) or a new 'HasPatch' as a counterpart for 'NeedPatch'. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] The Plethora of Patches
Santiago M. Mola wrote: On Tue, Aug 19, 2008 at 12:02 AM, Tobias Scherbaum [EMAIL PROTECTED] wrote: Santiago M. Mola wrote: However, tracking the status of every patch since its inclusion in portage until it's removed would be a huge work overhead... and I doubt it's worthy. I don't think it's a huge work overhead, it'll take an additional minute per included patch to include a minimal description into the ebuild(s) and use a standardized header for the patch. Compared to the time one needs to spend when searching for information on that patch somewhen later on it's worth every minute. Of course, puting a header with info in every patch is not a work overhead and I'd say it should be policy. What I meant is that it's no worth to track the status of every patch after it's added, as was suggested. Agreed. Everyone of us is doing some kind of status tracking for each and every patch at least for every version bump, additional status tracking like Andrew suggested would be a good thing (tm) but is plain impossible to realize for now given the fact we're lacking the needed manpower. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] [RFC] Add support for package.keywords in profiles?
Zac Medico wrote: Does package.keywords seem like a good solution for the types of problems it's meant to solve? Would anybody like to discuss any alternative approaches? I think it's a good and easy solution to the problem(s) solar described in #55321. But as Marius [1] said this can become quite confusing very quickly, therefore we would need to limit it's usage to uclibc/hardened/$special sub-profiles imho. Otherwise it gets more of a pain in the ass. Tobias [1] http://bugs.gentoo.org/show_bug.cgi?id=55321#c11 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
On Mon, Aug 18, 2008 at 5:12 PM, Tobias Scherbaum [EMAIL PROTECTED] wrote: John Brooks wrote: Random idea: How about a different bug assignee for maintainer-needed packages with provided ebuilds/patches? Either something generic, or try to go for something more category/package specific (herds, etc). Lots of work for bugwranglers, though. There is a huge difference to developers between an unmaintained package with no progress and just looking over an ebuild that has been used successfully by several people. No need for an additional mail/bugzie alias here, we could simply use a KEYWORD like the existing 'Inclusion' (which isn't used that much for now, 63 open bugs have that keyword) or a new 'HasPatch' as a counterpart for 'NeedPatch'. (This email isn't targeted towards Tobias - just replying) What is wrong with the KEYWORD called 'EBUILD' defined as: Marks an issue to be a user submitted ebuild. ? You can easily make a search that is assigned to maintainer-needed and has the EBUILD keyword (or any keyword).[1] I feel like you guys are trying to solve issues related to an underlying problem but not actually targeting the problem itself. The main issue is a lack of man-power. Also, devs willing to maintain packages but then later retiring and leaving the packages in limbo. Maybe there should be some policy such as, when devs retire if no one else steps up to maintain the package, then it automatically gets moved to sunrise overlay and only maintained packages stay in the portage tree. This would cut down on our current 247 maintainer-needed bugs[2] or our 35 bugs assigned to maintainer-needed with 'bump' in the summary[3]. However, keep in mind that we do have 497 bugs assigned to anyone with 'bump' in the summary[4]. Just some thoughts to ponder, Jeremy [1]: http://tinyurl.com/6y653y [2]: http://tinyurl.com/6olohq [3]: http://tinyurl.com/5d3tfl [4]: http://tinyurl.com/689y5p
Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
Jeremy Olexa wrote: Also, devs willing to maintain packages but then later retiring and leaving the packages in limbo. Maybe there should be some policy such as, when devs retire if no one else steps up to maintain the package, then it automatically gets moved to sunrise overlay and only maintained packages stay in the portage tree. My opinion is that packages should not be removed from the tree just because there is no assigned maintainer. Even moving a package to sunrise effectively makes it invisible to many users, and a great strength of Gentoo is that it has such a variety of packages in the tree. I do see that there are potential problems with unmaintained packages, so it is a good goal to try to solve that. Perhaps developers who have the time and choose to make themselves available to do simple version bumps on unmaintained packages could put themselves on a mailing list to receive such bug reports. Encouraging users to be proxy maintainers is a great idea too (as others have suggested). As a last resort, otherwise working packages could be masked as unmaintained, which is probably better than total removal (after all, they could still be useful to some users. -Joe
Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
I agree that packages shouldn't be removed or moved because they have no active developer maintaining them - that is going to take the value of portage down quite a lot. Outdated packages do too, but not in quite the same way. I like the idea of a list or mailing list of developers willing to help update unmaintained packages, and if community submitted ebuilds were encouraged a bit more, the job would be pretty simple. Most of the times i've done version bumps myself have just involved changing the name and fixing up patches. I definitely like the idea of encouraging proxy maintainers, as I said before. Becoming a full developer is (from what i've seen externally) quite difficult and requires a lot of dedicated time, but the user community is much larger - and 100 people doing one ebuild each is going to work better than one person doing 100 ebuilds. As another interesting idea for encouraging proxy maintainence, once an easier/more developed system exists for that (such as the mailing list mentioned before), perhaps a notice should be added to unmaintained ebuilds mentioning that it has no active maintainer, to warn users that a newer version may be available (in which case they can file a bug, etc) and encourage those with the time and skills to take up some of the work on those ebuilds. I would be very willing to work on some ebuilds if it didn't involve chasing a trail of vaguely relevant developers down until one pays attention. :P I would think that masking them due to a lack of maintainence should be used only as a last resort - if a package is blocking other updates or is extremely out of date (unsupported by upstream / everything else). But in those situations, deleting might be a better idea anyway, because what purpose does it really serve? - John Brooks On Mon, Aug 18, 2008 at 5:35 PM, Joe Peterson [EMAIL PROTECTED] wrote: Jeremy Olexa wrote: Also, devs willing to maintain packages but then later retiring and leaving the packages in limbo. Maybe there should be some policy such as, when devs retire if no one else steps up to maintain the package, then it automatically gets moved to sunrise overlay and only maintained packages stay in the portage tree. My opinion is that packages should not be removed from the tree just because there is no assigned maintainer. Even moving a package to sunrise effectively makes it invisible to many users, and a great strength of Gentoo is that it has such a variety of packages in the tree. I do see that there are potential problems with unmaintained packages, so it is a good goal to try to solve that. Perhaps developers who have the time and choose to make themselves available to do simple version bumps on unmaintained packages could put themselves on a mailing list to receive such bug reports. Encouraging users to be proxy maintainers is a great idea too (as others have suggested). As a last resort, otherwise working packages could be masked as unmaintained, which is probably better than total removal (after all, they could still be useful to some users. -Joe
Re: [gentoo-dev] Gentoo Council Reminder for August 7
Lukasz Damentko [EMAIL PROTECTED] said: Fair enough. Let me wrap up the IRC part. 1. I'd like to ask Council to discuss possible reactions to our developer being banned from Freenode without providing us with a reason. The situation looks like one of Freenode staffers overreacted over something Chris said during previous Council meeting and banned him to prevent him from attending next meetings when he was supposed to provide more information on the CoC topic. The ban was removed after an hour, but they still refuse to provide us with reasons for it which looks like (mostly because we weren't shown any sane justification for the ban) a cover up operation. It would be good if Council officially protested against that ban and demanded a detailed explanation from Freenode staff. Due to their privacy policy I don't think we'll ever be able to get adequate explanations from Freenode staff when our devs are banned. 2. I want Council to consider moving their meetings somewhere where third parties can't control who in Gentoo can attend and who can't. Like our own small and created just for this purpose IRC server. A situation when a third party may disallow our developer from attending a meeting without even telling us why isn't the healthiest one. We should be independent from such decisions of third parties so they can't politically influence Council decisions by removing people who are inconvenient for them. Now when it (most probably) happened once, we have no other choice but to believe it's possible it will happen again. If for some reason a developer was unable to attend a meeting due to being klined or the internet being FUBAR'd, I know that I have my IM details available in LDAP for that dev to be able to contact me, or they could send the entire council an email. I don't think setting up our own IRC server is worth the trouble for this small purpose. 3. I want Council to consider creating and using irc.gentoo.org alias instead of irc.freenode.net in our docs, news items and so on. The alias would allow us to move out of the network more easily should we ever decide to do so. Debian did exactly the same a couple of months ago prior to them moving out to OFTC (http://www.debian.org/News/2006/20060604) so maybe it would be a good idea to have this for Gentoo too. Infra (Shyam Mani) say it isn't a problem at all to create and maintain it, we in fact already have something like this pointing at Freenode, it would be just a question of updating that alias and updating our docs with it. It would increase our independence from Freenode and make future network switching much easier should we ever decide it's time to part our ways with our current IRC service provider. I like this idea. spb rose some concerns in the meeting with regards to some users thinking that if they came onto irc.gentoo.org and joined #java that it would be a Gentoo java channel, but it doesn't seem like Freenode considers this to be much of a problem. For evidence of this: http://freenode.net/acknowledgements.shtml They thank projects for pointing their domains to them, so I believe that the network as a whole shouldn't have a problem with this. If someone thinks I'm misunderstanding what they mean on that page, please let me know. Thanks, -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpuLxRnl25xF.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for August 7
Ben de Groot [EMAIL PROTECTED] said: 2) Continued presence of forcefully retired devs It really baffles me that some developers are forcefully retired for anti-social behavior, but are not consequently banned from the places where they display this behavior, such as our MLs and IRC channels. What good is it to retire developers, but allow them to continue to be disruptive? I would like the Council to decide for a change in our policy on this point. I personally don't see why they should be allowed to stay part of our communication channels where they have caused problems bad enough to get them retired. With that being said, I think the same technical issues come into play here as with banning someone from Gentoo entirely. I am not sure how we would be able to enforce this across the board for forcefully retired developers. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpvsdKcZDfkV.pgp Description: PGP signature
