Gentoo Archives: gentoo-dev

From: Alice Ferrazzi <alicef@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Stabilisation procedure
Date: Sat, 26 Nov 2016 15:06:01
Message-Id: 20161126150517.GA11069@alitoo
In Reply to: Re: [gentoo-dev] Re: Stabilisation procedure by Daniel Campbell
1 On Fri, Nov 25, 2016 at 11:47:35PM -0800, Daniel Campbell wrote:
2 > On 11/22/2016 12:06 AM, Alice Ferrazzi wrote:
3 > > On Sat, Nov 19, 2016 at 12:55:09AM -0800, Daniel Campbell wrote:
4 > >> On 11/17/2016 01:07 PM, Robin H. Johnson wrote:
5 > >>> On Thu, Nov 17, 2016 at 03:05:41PM +0100, Kristian Fiskerstrand wrote:
6 > >>>>> Isn't it implied that any stabilisation is approved by the maintainer?
7 > >>>>> Has it ever been acceptable to go around stabilising random packages?
8 > >>>>>
9 > >>>>
10 > >>>> Explicit > Implicit when we're updating things anyways.
11 > >>>>
12 > >>>> There are scenarios where e.g Security is calling for stabilization ,
13 > >>>> I'll add some info to the draft security GLEP with some requirements for
14 > >>>> when this can happen without maintainer involvement as well..
15 > >>>>
16 > >>>> Ultimately maintainer is responsible for the state of the stable tree
17 > >>>> for the packages they maintain and should be taking proactive steps for
18 > >>>> this also for security bugs, it doesn't "always" happen like that.....
19 > >>>
20 > >>> The interaction of this proposal and the prior discussion of allow
21 > >>> maintainers to document the maintenance policy of given packages is
22 > >>> where it would really come into play.
23 > >>>
24 > >>> Using two packages for examples:
25 > >>> app-admin/diradm: I am the upstream author as well as the package
26 > >>> maintainer. I care about it being marked stable. I'd prefer the normal
27 > >>> policy of other people asking me (with timeout) before touching it.
28 > >>>
29 > >>> app-admin/cancd: It's a very obscure package that I put in the tree
30 > >>> because I needed it, but I haven't personally used it in many years.
31 > >>> I fix the packaging if it's broken only.
32 > >>> I'm inclined to mark it with 'anybody-may-bump/fix/stabilize'.
33 > >>>
34 > >> Agreed. For most of my packages, I really don't mind since we're all
35 > >> working on Gentoo together, but it'd be super helpful if I was simply
36 > >> notified in the event that a package I maintain has gotten a security
37 > >> bump, patch, or stabilization. Sure, 'git log' and 'git blame' can
38 > >> explain a few things, but if I was going to edit a package, I have the
39 > >> maintainer's e-mail available right there in metadata.xml. To me it's a
40 > >> courtesy that should be a requirement by default, while devs that don't
41 > >> care can use whatever means we agree upon to indicate that they don't care.
42 > >>
43 > >> This creates a "contact first" practice, which it seems we want to
44 > >> encourage. If someone isn't responsive and/or away, that complicates
45 > >> things, but if it's a security concern or the last blocker in a big
46 > >> stabilization effort (looking at you, tcl 8.6...), then it makes sense
47 > >> to just go ahead and make the bumps necessary.
48 > >
49 > > What about maintainers that are away without writing it in their
50 > > maintainer bug ?
51 > > After how many days of no replay can be fair to touch their package ?
52 > >
53 > >>
54 > >> --
55 > >> Daniel Campbell - Gentoo Developer
56 > >> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
57 > >> fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
58 > >>
59 > >
60 > >
61 > >
62 > We have a formal dev-away practice, requiring little more than literally:
63 >
64 > ssh me@××××××××××.org; echo "Away for vacation. Back in a week" >
65 > ~/.away; exit
66 >
67 > A dev can add more details to the file if they want to. If they're gone
68 > and can't be reached at all, then I think a week is enough time for a
69 > developer to check their mail and get (or make) enough time to either
70 > update their dev-away status or otherwise indicate how they feel about a
71 > change that needs their feedback.
72 >
73 > Maybe the maintainer-bug case is different if we're talking
74 > proxy-maintainers, but that's a good question; one that maybe p-m should
75 > make on its own before we aim for a global, concrete policy.
76
77 yes, i was talking about maintainer-bug and not about dev-away practice.
78 The Maintainer Bug is referred here:
79 https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Bugs_and_Maintainership_Requests#Maintainer_Bug
80
81 >
82 > I think the requirement for contact is all we should really settle on
83 > formally; the rest being handled in wetware where it belongs. :)
84
85 sure keeping in contact can be good but not in all case always plausible.
86
87 > --
88 > Daniel Campbell - Gentoo Developer
89 > OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
90 > fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
91 >

Attachments

File name MIME type
signature.asc application/pgp-signature