[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Updating my git work-in-progess branch?

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Updating my git work-in-progess branch?
Date: Sat, 16 Mar 2019 02:18:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 3/15/19 5:06 PM, Corvus Corax wrote:
> Only maintainers had the ability to merge into "master" or
> "next" ("master" was always frozen between releases, so we merged into
> "next" for new features to be tested until the next release cycle,
> while developers would regularly merge "next" back into their dev
> branches or rebase into a new branch to stay up to date)

Most of what is discussed in this threat is in principle fine with me,
but this is not. I would like to avoid setting up such hierarchies among
developers. We're trying to build decentralized/egalitarian systems for
liberal societies, so we should avoid building them with authoritarian

So I would prefer a policy where *either* _everybody_ can merge to
master (with Git access, which is generally granted to anyone who has a
plausible need and signed the CA), *or* _nobody_ can merge to master
(because merges to master are done automatically by the CI when certain
tests pass!).

For now, I've never seen serious problems with the 'everybody' policy,
and would strongly prefer CI-based automation to solve the issue in a
principled way instead of adding some hierarchy.  Similarly, if we at
some point grow to the point where peer-review/sign-off becomes
necessary (and feasible), it should be again that in principle any 2nd
dev can sign-off, and not just a selected few (of course in practice it
is more likely that someone familiar with the affected subsystem will DO
the sign-off, but it should be self-organizing and not imposed).

my 2 cents


reply via email to

[Prev in Thread] Current Thread [Next in Thread]