[collectd] Collectd Release Process Proposal

[Pavel]

18.07.2019 14:20, Matthias Runge пишет:
> Pavel, yes and no. The reason why we have this discussion here is, that
> previous(*) most active developers are now busy with other stuff.

They found time to implement very strict checks to stop development, and 
went into the sunset.

Excellent, isn't it?

>
> You wouldn't see the noise here, if there wasn't any interest or if 
> there weren't companies interested both using and also having people 
> contribute to collectd. It is not the question if someone contribute, 
> but the question: how do we organize that.

You have permissions to do this on existing Github project, or you plan 
to do FORK?

As we have no any feedback from Owner, I don't think you have options to 
implement your interests or do any even minor changes in project policies.

> The code-owners proposal octo proposed last year, and which we tried, 
> is part of it. We were facing a decreasing number of people doing code 
> reviews. Part of the issue is, that only a few people are really 
> familiar with certain code, which makes "code-ownership" more 
> appealing, since that also defines subject matter experts for plugins.

While project requires to increase number of people, doing code reviews, 
project implements _restrictions_ what nobody _except_ some people 
(called "code owners") could take such responsibility - i.e. _decreases_ 
number of people, doing code reviews.
Declaration does not match implementation.

As you can see, as result, that proposal breaks all what it could to break.


> The implementation should be fine tuned in such a way, that "trusted 
> contributors" could also push the merge button for code involving 
> these certain plugins, which were owned by code-owners.

Did you ever looking into CODEOWNERS file?
"could also push the merge button for code involving these certain 
plugins, which were owned by code-owners" task can be easily solved by 
appending @trusted-contributors into each line.

But that was not done intentionally, I think.

N.B. - Even implemented, this does not solve the problem when 
"@trusted-contributors" unable to merge own code, i.e. becomes 
"@untrusted-contributors".

> iirc, there is this workaround to force-merge the code via command line,
> but that would also circumvent CI checks, but I agree, this is 
> different from pushing a merge button.

There is no such possibility. After "project policy changed", 
command-line merges/updates/pushes/force-pushes/etc also became not 
permitted for @trusted-contributors.

>
> Matthias
>
>
>
> (*) whatever previous means here, that can be months, years,...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.verplant.org/pipermail/collectd/attachments/20190718/b5d5aec3/attachment-0001.html>