On 11/22/2016 12:06 AM, Alice Ferrazzi wrote: > On Sat, Nov 19, 2016 at 12:55:09AM -0800, Daniel Campbell wrote: >> 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. > > What about maintainers that are away without writing it in their > maintainer bug ? > After how many days of no replay can be fair to touch their package ? > >> >> -- >> Daniel Campbell - Gentoo Developer >> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net >> fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 >> > > > We have a formal dev-away practice, requiring little more than literally:
ssh m...@dev.gentoo.org; echo "Away for vacation. Back in a week" > ~/.away; exit A dev can add more details to the file if they want to. If they're gone and can't be reached at all, then I think a week is enough time for a developer to check their mail and get (or make) enough time to either update their dev-away status or otherwise indicate how they feel about a change that needs their feedback. Maybe the maintainer-bug case is different if we're talking proxy-maintainers, but that's a good question; one that maybe p-m should make on its own before we aim for a global, concrete policy. I think the requirement for contact is all we should really settle on formally; the rest being handled in wetware where it belongs. :) -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
