Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.07.18 at 10:13, <lars.kurth@xxxxxxxxxx> wrote:
> On 03/07/2018, 08:00, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>     Fundamentally the problem can as well be seen when looking at any
>     of the stable branches: The variety of authors there is significantly
>     more narrow than for what goes into master. I understand people
>     mostly care about their features, but there ought to be a certain
>     level of responsibility beyond that by everyone. For example, I'd
>     sort of expect it to be the rule rather than the exception that
>     people look at nearby code or code they clone, and address issues
>     they see. At the risk of repeating myself, a large number of the
>     security issues found results from paying attention to nearby code
>     (also during code review). Looking over the list of reporters there
>     very well supports my statement above regarding feature
>     submission authors vs bug fix ones.
> 
> That is understood: if the project leadership agrees, then this is no issue, 
> as committers essentially are the gate keepers for what goes in. So in other 
> words, if committers are mainly focussing on getting a release out, 
> necessarily even if master is open during hardening, development would still 
> be slower than before. I don't think any contributors would have an issue 
> with this.

You didn't get one of my main points then: It is _contributers_ whom
I'd expect to focus more on stabilization (in general, not just during
freezes).

>     Which reminds me of a related question: How do we define
>     maintainership? Is it really enough to ack a few patches here and
>     there to be considered a maintainer? To me, code maintenance
>     also (and perhaps first of all) means actively looking after the
>     code. And yes, I'm aware that an implication of the implication
>     here might be the undesirable situation of us having more
>     unmaintained code in the tree and/or even larger bodies of code
>     in even fewer hands. So it is (as almost always) a matter of
>     weighing pros and cons.
>     
> What would speak against elevating the more active maintainers to committers 
> (maybe on probation for a fixed time period, not yet responsible for THE 
> REST). Would this help in your view?

I don't think so, no. We need more active maintainers, not more
committers.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel