Re: bug#61894: [PATCH RFC] Team approval for patches

[bokr@bokr.com]

Hi,
tl;dr:
    If you want to expand the list of committers rapidly,
    would it make sense to have a sand-box repo for new committers
    which trusted committers could channel cherry-picks from?

    Pick your bugaboo, but I consider plausible that some
    volunteering committers are there on paid job assignment
    serving some agenda which you can't easily discover.

    Well, that can be good and normal with FLOSS-enlightened emplayers,
    but one can imagine not-so-benevolent assignments...
    (pick your concept of benevolence :)

On +2023-03-02 12:04:44 +0100, Andreas Enge wrote:
> Hello,
> 
> in the current situation I think the suggestion is putting the horse before
> the cart. In a first step before adding policy, we should make the teams
> functional. While working on core-updates, I have been realising we are
> already spread too thin: Some important languages have teams with one or
> two members, who would effectively become bottlenecks. Other software has
> no team (Qt/KDE). All in all, I also think we have too few committers.
> Adding policy might completely stall the project...
> 
> If for every trivial update of a Python package we need not only submit a
> patch to the bugtracker, wait for QA, get back to the patch, resign it,
> push it and close the bug, but additionally wait for one of the two Python
> team members to have a look at it (or let an additional week pass),
> incentives to participate will tend to zero.
> 
> Your suggested policy can help against commits of too bad quality; but I
> do not think this is our problem, our problem is rather a lack of fast
> progress.
> 
> So I think we need to add committers, add committers to teams, encourage
> teams to engage in work, and if everything works smoothly, maybe add policy.
> 
> Andreas
> 
> 
--
Regards,
Bengt Richter