On Fri, Jun 01, 2007 at 02:22:58PM +0100, Ian Jackson wrote: > Anthony Towns writes ("Two GR concepts for dicussion"): > > I think the process should involve: > > [...] > This sounds like a good idea to me.
> One thing that would be really helpful would be an ability for a > Maintainer of this kind to make updates without review iff it can be > shown to be safe. (Where `safe' means `the Maintainer gets to screw > over people who run this program, but not anyone who doesn't.) I think if we have multiple developers recommending them they ought to be beyond the stage of fucking things up to the degree that this level of inspection of what they are uploading is necessary. > I'm not sure exactly what the criteria would be but basically you'd > diff the previous and new packages and allow only certain kinds of > changes (eg, changes to existing programs in /usr/bin would be fine). In what ways can maintainers of packages generally screw over users of other packages? Don't people notice fairly soon and certainly before the packages are out of unstable? I imagine this is easier with library packages with many dependent packages but I can't imagine those would often be maintained by DMs. As long as there is an easy way to remove keys from the DM keyring I'm not convinced this is a real problem. If you want reviews of every package from a DM then we should just leave things as they are and force packages to be sponsored in. The ideas behind the DM keyring, as I see them, are to capture new blood, to let people contribute in a more meaningful way and to stop people getting so frustrated by the NM process by giving them a little bit more responsibility and trust earlier on. I think complicating it further goes against that and makes it much less interesting. Simon. -- Just another wannabie | <sl> benj: mais il y a des | Just another fool ----------------------+ thumbnails en 1600x1200 ;) +------------------- This message was brought to you by the letter V and the number 49. htag.pl 0.0.22 -- http://www.earth.li/projectpurple/progs/htag.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]