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 |
> |