| 1 |
On 06/22/2013 11:01 AM, hasufell wrote: |
| 2 |
> On 06/22/2013 03:42 AM, Robin H. Johnson wrote: |
| 3 |
>> On Fri, Jun 21, 2013 at 09:06:30PM -0400, Mike Frysinger wrote: |
| 4 |
>>> On Friday 21 June 2013 20:26:03 Robin H. Johnson wrote: |
| 5 |
>>>> On Fri, Jun 21, 2013 at 08:17:38PM -0400, Mike Frysinger wrote: |
| 6 |
>>>>>> I'm not going into review systems here at all, I'm simply trying to |
| 7 |
>>>>>> have a policy of what changes are welcomed/blocked WITHOUT interaction |
| 8 |
>>>>>> from the listed maintainer(s) of a given package/herd. |
| 9 |
>>>>> |
| 10 |
>>>>> add a new field to metadata.xml that declares the state. make it an enum: |
| 11 |
>>>>> ANYTHING_GOES (the default) |
| 12 |
should reflect the circle of entities to do the change ... ANYBODY? Just |
| 13 |
to not confuse it with an type of change. |
| 14 |
>>>>> REQUIRES_HERD |
| 15 |
>>>>> REQUIRES_MAINTAINER |
| 16 |
>>>> |
| 17 |
>> So we have: |
| 18 |
>> Who = {ANYTHING_GOES, REQUIRES_DEV, REQUIRES_HERD, REQUIRES_MAINTAINER} |
| 19 |
>> What = {NONE, TRIVIAL, MINOR_FEATURES, VERSION_BUMP, MAJOR_FEATURES} |
| 20 |
>> |
| 21 |
>> So most of my packages might be coded with: |
| 22 |
>> <nmu-policy who="REQUIRES_DEV" what="VERSION_BUMP" /> |
| 23 |
>> <nmu-policy who="REQUIRES_HERD" what="MAJOR_FEATURES" /> |
| 24 |
>> |
| 25 |
>> - If you're a developer, you can do trivial fixes, add minor features, |
| 26 |
>> bump the version. |
| 27 |
>> - If you're in the herd, you can add major features. |
| 28 |
>> |
| 29 |
> |
| 30 |
> Sounds cool. |
| 31 |
> |
| 32 |
> I don't think we need a GLEP or council vote on that. |
| 33 |
ack. |
| 34 |
|
| 35 |
But in every single metadata? Can I get a script for my 160 personal |
| 36 |
edits, pls? |
| 37 |
|
| 38 |
And what's a sane default? |
| 39 |
Let's take a amount to time (~2month) for responsive people to mark |
| 40 |
their preferences and default to EVERTHING_GOES/ANYBODY. |
| 41 |
|
| 42 |
And we lost the timeout dimension. An "Feel free to bump my stuff" |
| 43 |
override in devaway works for single maintained packages, how to |
| 44 |
interpret these data for teams and multiple maints? AWOL people... |
| 45 |
|
| 46 |
Bottom line: I think we need more of a culture of mutual trust than a |
| 47 |
ton of metadata. |
| 48 |
|
| 49 |
- Respect the right of an maintainer to take a few days until responding |
| 50 |
(except QA, security, major skrew ups), |
| 51 |
- Honor the effort other people put into packages you don't care to much. |
| 52 |
- Take a look at the package/ebuild complexity to estimate the |
| 53 |
maintainers affection. |
| 54 |
- Ask for an second opinion aka peer-review. |
| 55 |
|
| 56 |
(And yes I've failed at every single point at least once). |
| 57 |
|
| 58 |
-- |
| 59 |
Michael Weber |
| 60 |
Gentoo Developer |
| 61 |
web: https://xmw.de/ |
| 62 |
mailto: Michael Weber <xmw@g.o> |
Archives