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


_______________________________________________
collectd mailing list
collectd@verplant.org
https://mailman.verplant.org/listinfo/collectd

Reply via email to