[gentoo-dev] Re: [gentoo-core] Keywords policy
On 3/10/08, Ryan Hill [EMAIL PROTECTED] wrote: Jeroen Roovers wrote: On Mon, 10 Mar 2008 16:26:19 +0100 Wulf C. Krueger [EMAIL PROTECTED] wrote: No, we didn't because the whole thing is p.masked for a reason. It, KDE 4.0.1, is broken crap that should not yet be re-keyworded. OK then. and I am not going to cross-post this to -dev@, btw: why the hell did you decide to put broken crap in the tree? It should never have left your repository, it seems. It's package masked and unkeyworded, which is a big hint that it's under development. So Jer should just implicitly know not to keyword it? Why not make it explicit? That is all I am really asking for here. If you still wonder why I started rekeywording for HPPA, then let this be the final answer. It was no fault of mine - I did it on purpose. No keywording error - I was going to finish all the dependencies if you hadn't asked me not to (because by then you were claiming KDE team reserves the right to drop keywords at will and without notifying arch teams, as opposed to current policy. The repoman bug / missing feature left a few stones unturned, sadly, but I was going to do all of KDE 4. You're still not getting this. The KDE team did not _want_ these ebuilds keyworded. That's why they _weren't_ keyworded. That's why there was no bug filed, saying hey we dropped these keywords because they _did not want_ you to add them back yet. When the ebuilds were of sufficient quality that they could be tested, then a bug is filed, the ebuilds are tested, and then re-keyworded. Right, but you did not make your want known, so how is Jer to know? Maintainers have every right to drop keywords if they think changes to their package are drastic enough to require re-evaluation by an architecture team. It's how we keep big fat calamity from befalling our users. Yes, they need to inform the arch teams to re-add their keywords. No that request does not need to come immediately if they're not ready for it. A simple rule to go by: Dropped keywords on package.masked packages are not dropped keywords. If that package comes out of package.mask and still lacks your keyword and no bug is filed, then yes, then you have a legitimate beef. This is simply the way things work from my point of view as a maintainer and a arch dev for a oft keyword-dropped arch. RIght but if everyone is not following the same rules you get...well...this exact situation. The whole point of this discussion is not to assign blame, it is to figure out what we should change so this doesn't happen again as it obviously upset lots of folks. -Alec -- fonts, gcc-porting, by design, by neglect mips, treecleaner,for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-core] Keywords policy
Alec Warner wrote: On 3/10/08, Ryan Hill [EMAIL PROTECTED] wrote: You're still not getting this. The KDE team did not _want_ these ebuilds keyworded. That's why they _weren't_ keyworded. That's why there was no bug filed, saying hey we dropped these keywords because they _did not want_ you to add them back yet. When the ebuilds were of sufficient quality that they could be tested, then a bug is filed, the ebuilds are tested, and then re-keyworded. Right, but you did not make your want known, so how is Jer to know? I don't really want to get into the specifics of this situation but wanted to raise a question of policy. My understanding is that arch teams shouldn't keyword anything without the OK of the maintainer - usually in the form of a STABLEREQ bug. When I get stable requests from users I don't act on them until I hear from the maintainer for this reason. I know that at one point there was discussion of having a ~maint/maint keywords that would be used just to indicate the intent of the maintainer for each package. Then all the usual keyword-comparison tools could be used to detect packages that are ready for keywording. I would be pretty annoyed as a maintainer if I started getting a deluge of bug reports and complaints from end users who didn't intend to run broken software if somebody unmasked or keyworded something that I didn't intend anybody to be using aside from a few brave souls willing to risk everything to try out some new software. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [Fwd: Re: [gentoo-core] Keywords policy]
Bo Ørsted Andresen wrote: On Tuesday 11 March 2008 16:55:11 Ferris McCormick wrote: Now that I've said I'm tired of this thread, let me add to it. I'd like to add one more point, namely: * Please explain in the ChangeLog what you are doing and why. In this case, if I look at kdelibs for example, what I see is Version bump to KDE 4.0.1 which looks pretty harmless. A couple lines explaining that it is package.masked because it doesn't actually work might have been helpful. Do you really think that should go into the ChangeLog of all 208 packages? Personally I would have thought the package.mask message would be sufficient... considering you can do the following: $ echangelog Version bump to KDE 4.0.1. This is a major version change, please review package.mask for details. and for the other 207 packages you do $ !echan it sounds more like laziness on the part of the KDE team. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer: Tobias Klausmann (klausman)
Congratulations Tobias. You're a worthy addition to Gentoo. And a lot of thanks to Petteri who's taking over my work while I'm stranded. Denis. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer: Tobias Klausmann (klausman)
Am Montag, den 10.03.2008, 23:02 +0100 schrieb Lars Weiler: * Petteri Räty [EMAIL PROTECTED] [08/03/10 23:13 +0200]: One of those people working on those weird paper weights. This time our monkey comes from the world of alphas. Tobias hails from Germany (there seems to be no end). Finally! Nice to see you here as well :-) Indeed! Welcome aboard, Tobias :) wkr, just another Tobias ;) -- Gentoo Linux - Die Metadistribution http://www.mitp.de/1769 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Re: [gentoo-core] Keywords policy
(Probably off topic? I think Richard said something he didn't intend.) On Tue, 2008-03-11 at 11:24 -0400, Richard Freeman wrote: Alec Warner wrote: On 3/10/08, Ryan Hill [EMAIL PROTECTED] wrote: You're still not getting this. The KDE team did not _want_ these ebuilds keyworded. That's why they _weren't_ keyworded. That's why there was no bug filed, saying hey we dropped these keywords because they _did not want_ you to add them back yet. When the ebuilds were of sufficient quality that they could be tested, then a bug is filed, the ebuilds are tested, and then re-keyworded. Right, but you did not make your want known, so how is Jer to know? I don't really want to get into the specifics of this situation but wanted to raise a question of policy. My understanding is that arch teams shouldn't keyword anything without the OK of the maintainer - usually in the form of a STABLEREQ bug. When I get stable requests from users I don't act on them until I hear from the maintainer for this reason. Um, not really --- this is too broad. Some packages are not keyworded because no one has ever tried them. We occasionally get keyword requests of the form Please add ~sparc keyword to because I've been using it and it works fine in response to which we do add the keyword if it does work. No maintainer action involved, because the maintainer apparently doesn't know if the package works on sparc or not anyway. A STABLEREQ is a different matter, masked packages are a different matter, but not just keywording. --- snip --- Regards, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] Keywords policy
Ferris McCormick wrote: Um, not really --- this is too broad. Some packages are not keyworded because no one has ever tried them. We occasionally get keyword requests of the form Please add ~sparc keyword to because I've been using it and it works fine in response to which we do add the keyword if it does work. No maintainer action involved, because the maintainer apparently doesn't know if the package works on sparc or not anyway. A STABLEREQ is a different matter, masked packages are a different matter, but not just keywording. If the package were already keyworded ~arch on a few other archs I wouldn't hesitate to add ~amd64 if it worked on amd64. However, if a package were ~arch on several archs I would not keyword it stable amd64 without the maintainer's input (or at least lack of response in the case of an inactive maintainer). I don't think maintainers need to be bugged all the time, but they should be asked about making an ebuild stable for the first time, or unmasking/etc. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-core] Keywords policy
Alec Warner wrote: On 3/10/08, Ryan Hill [EMAIL PROTECTED] wrote: Jeroen Roovers wrote: On Mon, 10 Mar 2008 16:26:19 +0100 Wulf C. Krueger [EMAIL PROTECTED] wrote: No, we didn't because the whole thing is p.masked for a reason. It, KDE 4.0.1, is broken crap that should not yet be re-keyworded. OK then. and I am not going to cross-post this to -dev@, btw: why the hell did you decide to put broken crap in the tree? It should never have left your repository, it seems. It's package masked and unkeyworded, which is a big hint that it's under development. So Jer should just implicitly know not to keyword it? Why not make it explicit? That is all I am really asking for here. How much more explicit can you make it than dropping every arch's keywords and putting it in package mask? The problem here is that Jeroen decided that this was a violation of the keyword policy and blindly added his keywords back. Fair enough, everyone makes a mistake from time to time. But after more than a few people have tried to explain why this was a mistake, he still refuses to admit it and claims the keywords were dropped illegally. I'm just pointing out that this is not the case, and never has been. If a maintainer package masks an ebuild, you don't mess with it without talking to them. This is coming straight from the handbook. If you still wonder why I started rekeywording for HPPA, then let this be the final answer. It was no fault of mine - I did it on purpose. No keywording error - I was going to finish all the dependencies if you hadn't asked me not to (because by then you were claiming KDE team reserves the right to drop keywords at will and without notifying arch teams, as opposed to current policy. The repoman bug / missing feature left a few stones unturned, sadly, but I was going to do all of KDE 4. You're still not getting this. The KDE team did not _want_ these ebuilds keyworded. That's why they _weren't_ keyworded. That's why there was no bug filed, saying hey we dropped these keywords because they _did not want_ you to add them back yet. When the ebuilds were of sufficient quality that they could be tested, then a bug is filed, the ebuilds are tested, and then re-keyworded. Right, but you did not make your want known, so how is Jer to know? Maintainers have every right to drop keywords if they think changes to their package are drastic enough to require re-evaluation by an architecture team. It's how we keep big fat calamity from befalling our users. Yes, they need to inform the arch teams to re-add their keywords. No that request does not need to come immediately if they're not ready for it. A simple rule to go by: Dropped keywords on package.masked packages are not dropped keywords. If that package comes out of package.mask and still lacks your keyword and no bug is filed, then yes, then you have a legitimate beef. This is simply the way things work from my point of view as a maintainer and a arch dev for a oft keyword-dropped arch. RIght but if everyone is not following the same rules you get...well...this exact situation. The whole point of this discussion is not to assign blame, it is to figure out what we should change so this doesn't happen again as it obviously upset lots of folks. As far as I know this is policy. It has worked so far, but if something needs to change then so be it. -- fonts, gcc-porting, by design, by neglect mips, treecleaner,for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: OpenPGP digital signature
