On 11/17/2016 01:07 PM, Robin H. Johnson wrote: > On Thu, Nov 17, 2016 at 03:05:41PM +0100, Kristian Fiskerstrand wrote: >>> Isn't it implied that any stabilisation is approved by the maintainer? >>> Has it ever been acceptable to go around stabilising random packages? >>> >> >> Explicit > Implicit when we're updating things anyways. >> >> There are scenarios where e.g Security is calling for stabilization , >> I'll add some info to the draft security GLEP with some requirements for >> when this can happen without maintainer involvement as well.. >> >> Ultimately maintainer is responsible for the state of the stable tree >> for the packages they maintain and should be taking proactive steps for >> this also for security bugs, it doesn't "always" happen like that..... > > The interaction of this proposal and the prior discussion of allow > maintainers to document the maintenance policy of given packages is > where it would really come into play. > > Using two packages for examples: > app-admin/diradm: I am the upstream author as well as the package > maintainer. I care about it being marked stable. I'd prefer the normal > policy of other people asking me (with timeout) before touching it. > > app-admin/cancd: It's a very obscure package that I put in the tree > because I needed it, but I haven't personally used it in many years. > I fix the packaging if it's broken only. > I'm inclined to mark it with 'anybody-may-bump/fix/stabilize'. > Agreed. For most of my packages, I really don't mind since we're all working on Gentoo together, but it'd be super helpful if I was simply notified in the event that a package I maintain has gotten a security bump, patch, or stabilization. Sure, 'git log' and 'git blame' can explain a few things, but if I was going to edit a package, I have the maintainer's e-mail available right there in metadata.xml. To me it's a courtesy that should be a requirement by default, while devs that don't care can use whatever means we agree upon to indicate that they don't care. This creates a "contact first" practice, which it seems we want to encourage. If someone isn't responsive and/or away, that complicates things, but if it's a security concern or the last blocker in a big stabilization effort (looking at you, tcl 8.6...), then it makes sense to just go ahead and make the bumps necessary. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6