Re: [gentoo-dev] metadata.xml: changepolicies
On Thursday 25 February 2010 08:22:17 Ulrich Mueller wrote: On Wed, 24 Feb 2010, Robin H Johnson wrote: Metadata.xml should allow use of a changepolicies element. Within the element, package maintainers should be able to describe how non-maintainer changes to the package are handled. Could we allow this element in the category metadata files, too? Its value there would be the default for the category, with the possibility to override it for individual packages. Ulrich How are you so sure that a general rule can apply to a whole category? E.g. the x11-misc/ one. Which rule for non-maintainer changes are you going to apply since every single developer is maintaining a x11-misc application? Same for app-misc etc. -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] metadata.xml: changepolicies
On Thu, 25 Feb 2010, Markos Chandras wrote: Could we allow this element in the category metadata files, too? Its value there would be the default for the category, with the possibility to override it for individual packages. How are you so sure that a general rule can apply to a whole category? E.g. the x11-misc/ one. Which rule for non-maintainer changes are you going to apply since every single developer is maintaining a x11-misc application? Same for app-misc etc. Of course it would make no sense for the x11-misc category. But we have categories that mainly consist of packages belonging to one herd, for example the dev-language categories. Ulrich
Re: [gentoo-dev] Re: Remove dev-status of mips profiles
Torsten Veller ml...@veller.net said: * Torsten Veller t...@gentoo.org: Can we please move the mips profiles from dev to exp in profiles/profiles.desc? Based on the current feedback I'll change it not earlier than friday next week if nobody objects. That would be nice. I'd also love to know why we need about 150 different profiles for MIPS... -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com
Re: [gentoo-dev] Re: Remove dev-status of mips profiles
On 02/25/2010 05:14 PM, Mark Loeser wrote: Torsten Veller ml...@veller.net said: * Torsten Veller t...@gentoo.org: Can we please move the mips profiles from dev to exp in profiles/profiles.desc? Based on the current feedback I'll change it not earlier than friday next week if nobody objects. That would be nice. I'd also love to know why we need about 150 different profiles for MIPS... Every machine type profile has a developer, desktop and server sub profile. How about deleting those? If you are capable of setting up a Gentoo/MIPS setup, then you are certainly capable of setting up few profile defaults on your own too. See attached patch --- profiles.desc.orig 2010-02-25 17:19:46.0 +0200 +++ profiles.desc 2010-02-25 17:21:34.0 +0200 @@ -44,158 +44,41 @@ m68kdefault/linux/m68k/10.0/server dev # MIPS Profiles -mipsdefault/linux/mips/10.0/cobalt/desktop dev -mipsdefault/linux/mips/10.0/cobalt/developer dev -mipsdefault/linux/mips/10.0/cobalt/n32/desktop dev -mipsdefault/linux/mips/10.0/cobalt/n32/developer dev -mipsdefault/linux/mips/10.0/cobalt/n32/server dev mipsdefault/linux/mips/10.0/cobalt/n32 dev -mipsdefault/linux/mips/10.0/cobalt/n64/desktop dev -mipsdefault/linux/mips/10.0/cobalt/n64/developer dev -mipsdefault/linux/mips/10.0/cobalt/n64/server dev mipsdefault/linux/mips/10.0/cobalt/n64 dev -mipsdefault/linux/mips/10.0/cobalt/server dev mipsdefault/linux/mips/10.0/cobalt dev -mipsdefault/linux/mips/10.0/desktop dev -mipsdefault/linux/mips/10.0/developer dev -mipsdefault/linux/mips/10.0/lemote/lm2e/desktop dev -mipsdefault/linux/mips/10.0/lemote/lm2e/developer dev -mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/desktop dev -mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/developer dev -mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n32/desktop dev -mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n32/developer dev -mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n32/server dev mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n32 dev -mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n64/desktop dev -mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n64/developer dev -mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n64/server dev mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n64 dev -mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/server dev mipsdefault/linux/mips/10.0/lemote/lm2e/fulong dev -mipsdefault/linux/mips/10.0/lemote/lm2e/n32/desktop dev -mipsdefault/linux/mips/10.0/lemote/lm2e/n32/developer dev -mipsdefault/linux/mips/10.0/lemote/lm2e/n32/server dev mipsdefault/linux/mips/10.0/lemote/lm2e/n32 dev -mipsdefault/linux/mips/10.0/lemote/lm2e/n64/desktop dev -mipsdefault/linux/mips/10.0/lemote/lm2e/n64/developer dev -mipsdefault/linux/mips/10.0/lemote/lm2e/n64/server dev mipsdefault/linux/mips/10.0/lemote/lm2e/n64 dev -mipsdefault/linux/mips/10.0/lemote/lm2e/server dev -mipsdefault/linux/mips/10.0/lemote/lm2f/desktop dev -mipsdefault/linux/mips/10.0/lemote/lm2f/developer dev -mipsdefault/linux/mips/10.0/lemote/lm2f/n32/desktop dev -mipsdefault/linux/mips/10.0/lemote/lm2f/n32/developer dev -mipsdefault/linux/mips/10.0/lemote/lm2f/n32/server dev mipsdefault/linux/mips/10.0/lemote/lm2f/n32 dev -mipsdefault/linux/mips/10.0/lemote/lm2f/n64/desktop dev -mipsdefault/linux/mips/10.0/lemote/lm2f/n64/developer dev -mipsdefault/linux/mips/10.0/lemote/lm2f/n64/server dev mipsdefault/linux/mips/10.0/lemote/lm2f/n64 dev -mipsdefault/linux/mips/10.0/lemote/lm2f/server
[gentoo-dev] [rfc] Making repoman/metagen check for validity of herds
I agree that additional repoman checks can help to improve quality in Gentoo... It seems that currently neither metagen nor repoman check what I put in for herd (i.e. if such a herd exists or not). Does anyone feel like getting his hands on that or like teaming up on it? Sebastian
Re: [gentoo-dev] Re: Remove dev-status of mips profiles
On Thu, Feb 25, 2010 at 05:24:25PM +0200, Samuli Suominen wrote: Every machine type profile has a developer, desktop and server sub profile. How about deleting those? If you are capable of setting up a Gentoo/MIPS setup, then you are certainly capable of setting up few profile defaults on your own too. Or better yet, you can stack your own mix of profiles: # rm /etc/make.profile # mkdir /etc/make.profile # cat /etc/make.profile/parent EOF /usr/portage/profiles/default/linux/mips/10.0/cobalt/n32 /usr/portage/profiles/targets/developer EOF This avoids the need for desktop/developer/server everywhere, as I'm not aware of ANY end profile of those that applies any other changes. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgppkM9MCOZkK.pgp Description: PGP signature
Re: [gentoo-dev] metadata.xml: changepolicies
On 02/25/2010 02:41 PM, Markos Chandras wrote: On Thursday 25 February 2010 08:22:17 Ulrich Mueller wrote: On Wed, 24 Feb 2010, Robin H Johnson wrote: Metadata.xml should allow use of achangepolicies element. Within the element, package maintainers should be able to describe how non-maintainer changes to the package are handled. Could we allow this element in the category metadata files, too? Its value there would be the default for the category, with the possibility to override it for individual packages. Ulrich How are you so sure that a general rule can apply to a whole category? E.g. the x11-misc/ one. Which rule for non-maintainer changes are you going to apply since every single developer is maintaining a x11-misc application? Same for app-misc etc. I think it would make more sense in herds.xml. Not sure about packages with more than one herd though :) maybe use the stricter one? This would definitely need some tool support for simple queries, to be usable. Vlastimil
Re: [gentoo-dev] metadata.xml: changepolicies
On 24-02-2010 23:41:26 +, Robin H. Johnson wrote: Proposed types: --- - version-bump - trivial-version-bump - trivial-fixes - fixes - enhancements - qa-fixes - trivial-qa-fixes Isn't the QA team by its definition allowed to fix QA issues? If so, I don't see a point in explicitly allowing qa-fixes of any kind, since it's implicit for the QA team that is supposed to do this. For QA its probably good to get people in the loop anyway, so they learn, instead of just find their packages fixed in one way or another. In general it feels like if you really want to allow a very high degree of modifications to your ebuilds as maintainer, perhaps it is better to introduce a special group of ebuilds that have in the best case someone watching over them every now and then, but are not tied to someone. Almost sounds like maintainer-needed: looking for someone who really cares about this package, perhaps even users welcome for proxy maintenance. Another thing may be just the maintainer-timeout thing, that simply says that if the maintainer doesn't respond to requests for a change/update, you are allowed to perform the change. Normal sanity and responsibility rules apply of course. Some bugs just hang around for even years with multiple devs commenting on them, and the maintainers just not responding at all. Seems like in such case a time-out rule says more than a once written metadata element. Maybe we just shouldn't try to own something, but rather be the first to say something about it. Maybe we should try to identify (groups of) packages that are way more important than others (think of ... python?) and mark them as needing special care, treatment and barriers before any dev would feel like touching them. Perhaps that would just mean rings of developer ranks where the inner circle is QA or something? The more you are on the outside, the less you are allowed to touch by policy. As learning process, making the thin line of the Gentoo quizes too access all or nothing more fine-grained and hopefully community controlled? -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] metadata.xml: changepolicies
Stop. Is introduction of such a high level of bureaucracy really a good idea? In my eyes it could backfire and make matters worse as people either - start ignoring it due to high noise - reduce people's activity below set permissions To summarize presented proposal has a few points that may not work well with humans. To my understanding we have the assumption in Gentoo that a Gentoo dev is at least willing to use his brain most of the time. To me such a machine only makes sense when assuming the opposite(!) So I would like to propose a much more loose and simple approach: A distinction - between major and minor changes - need for prior interaction or not A sensible default may differ from developer to developer. I propose collecting these defaults somewhere and make it overridable per maintainer per package in metadata.xml (just as robbat2 did). One question to decide would be if access is allowed iff - no one is objecting or - everyone is acknowledging Once all defaults are collected the options are equal, before they are not. How to best handle herds is not clear to me in detail, yet. Anyone seing potential in this minimalistic with a natural extension on herds in mind? Sebastian
[gentoo-dev] Re: [gentoo-desktop] [RFC] Splitting desktop profile to KDE and GNOME
On Friday 22 January 2010 18:15:49 Ben de Groot wrote: 2009/10/24 Maciej Mrozowski reave...@gmail.com: Hi there! Resulting from discussion during last Gentoo KDE team meeting taking place 22 Oct 2009 at #gentoo-meetings (summary fill be available soon), having Gentoo GNOME team representative, it's been decided to go ahead with splitting desktop profile to DE-specific subprofiles, to avoid bloat and provide desktop specific separation which should result in desktop subprofiles being actually practical. It's been proposed to: - keep 'desktop' profile but strip it from any desktop specific features and settings, making it default recommended choice for anyone using non-KDE and non-GNOME desktop environment, yet avoiding USE flags bloat. Any other DE is free to join and create own DE-specific subprofile if needed. - create 'KDE' (or 'kde') and 'GNOME' (or 'gnome') subprofiles within 'desktop' profile and move any desktop specific things there. This should in theory allow us to not add 'recommended' IUSE defaults to desktop specific packages, but keep those settings in profile - making profile effectively 'out of the box' solution for those who need it. If you have any comments, suggestions, important notices regarding this change, please keep discussion in gentoo-desktop mailing list. Thanks -- regards MM Three months later... Why has this not been implemented yet? Cheers, Just for the record, I will do this tomorrow. Thanks -- Theo Chatzimichos (tampakrap) Gentoo KDE Team signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Remove dev-status of mips profiles
On Thu, 25 Feb 2010 11:30:32 +0100 Torsten Veller ml...@veller.net wrote: * Torsten Veller t...@gentoo.org: Can we please move the mips profiles from dev to exp in profiles/profiles.desc? Based on the current feedback I'll change it not earlier than friday next week if nobody objects. Did you get feedback from anyone on m...@? -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] [RFC] News item: 2010-03-01 MythTV 0.22 Upgrade Database Corruption
I think this is good to go, let's get some comments from the list. Ben -- Forwarded message -- From: Richard Freeman ri...@gentoo.org Date: 24 February 2010 16:57 Subject: Re: [gentoo-dev] Re: Pending mask of Qt3 and MythTV To: gentoo-dev@lists.gentoo.org How about this revised news item: Title: MythTV 0.22 Upgrade Database Corruption Author: Richard Freeman ri...@gentoo.org Content-Type: text/plain Posted: 2010-03-01 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: media-tv/mythtv-0.22 Due to an incompatibility between MythTV 0.21 and the default Gentoo MySQL configuration, it is likely that long-time MythTV users will have databases with a mixture of locale encodings. If you upgrade to 0.22 without following these directions carefully, you could end up with a database that contains errors that are extremely difficult to fix. Note that not all mythtv users need to modify their databases, and this should only be performed at the time of the upgrade. The guide below contains instructions that can be used to determine if this problem pertains to you. Please see the MythTV Upgrade Guide for instructions: http://wiki.mythtv.org/wiki/Fixing_Corrupt_Database_Encoding Be sure to save a database backup before upgrading. Also, be sure to upgrade any other clients/backends you are using to 0.22 at the same time. The upgrade instructions need to be followed once per database - individual client/backend upgrades do not require these steps. If you do run into problems with your upgrade, there is a forum thread where you may be able to find help: http://forums.gentoo.org/viewtopic-t-816566-highlight-.html
[gentoo-dev] Re: Remove dev-status of mips profiles
* Ryan Hill dirtye...@gentoo.org: Torsten Veller ml...@veller.net wrote: * Torsten Veller t...@gentoo.org: Can we please move the mips profiles from dev to exp in profiles/profiles.desc? Based on the current feedback I'll change it not earlier than friday next week if nobody objects. Did you get feedback from anyone on m...@? No, I don't think so. Nonetheless mips was CC'ed on the last mail. I also got no reply to the keywording bugs waiting for mips. -- Thanks
