gnunet-developers
[Top][All Lists]
Advanced

[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 21:17:48 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 3/16/19 11:39 AM, Schanzenbach, Martin wrote:
> 
> 
>> On 16. Mar 2019, at 02:18, Christian Grothoff <address@hidden> wrote:
>>
>> 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
>> methods.
> 
> Sorry I need to hijack this for a fundamental disagreement on the above:

Let me begin by saying that I appreciate your pushback, especially given
that Lynx is MIA these days ;-)

> Having quality gates and separation of responsibility between individuals is 
> important. Else it will just be chaos and, inevitably, conflict or a 
> crippling search for consensus.

Careful here. I'm not arguing against quality gates or responsibilities.
I thought I made it clear that ideally some CI would be a quality gate,
running a suite of tests (QA!) and merging only once the standard has
been satisfied. You can think of it as automating the oversight, and
hopefully executing it more flawlessly and faster than manual processes
could.

Also, policies on how who can merge to branches doesn't eliminate
responsibilities. Someone making a release will still be responsible for
some additional QA, someone maintaining a subsystem will still be
responsible for design decisions, direction and review. But I prefer
those more fluent competency-related relationships to be directly
between humans, and not enforced by the technology.

> And, yes, this implies hierarchies with respect to specific responsibilities.
> The reason for this is that not everybody has the same skill set / interest 
> for specific tasks.

Sure, competency/skill-set hierarchies (merit-based) are acceptable. But
do we need the VCS to enforce them? Can the CVS determine them? Are
branches the right granularity for this? cadet, dht, reclaim, rps --
four subsystems, different people here with different competencies on
each of them. I don't think branches on "GNUnet" have any chance of
capturing this, and the picture is constantly evolving and we shouldn't
waste our time trying to "document" our competencies in Gitolite rules
--- especially as long as there are zero problems.

> Any other organisational form is not really based in reality but purely 
> idealogical and bound to fail because
> it will result in having not the most capable, but loudest and most audacious 
> individuals slowing down everything because competency will not be valued.

Agreed, but I was not talking about competency-based hierarchies. What I
want to minimize is "admin" hierarchies, where people that are
reasonably competent can't do things because policies put in gatekeepers
that can then block things -- be it because they are lazy, mean,
overburdened or have other priorities.

> There will be people responsible for CI, releases, features etc. because that 
> is what they primarily want to do.

Yep, and I want such CI people to prevent *me* from pushing stupid
commits to master that break things. And I do not want to be the
bottleneck for you (or anyone else) from getting their CI-passing
well-considered changes into master. And I want people other than me
doing releases, and deciding on features without _worrying_ what I might
think. Naturally, if someone cares I may provide my feedback, but if
things depend on a few people at the top (which is inherent with an
-administrative- hierarchy), then I don't see how this can work
_especially_ with mostly volunteers.

> There will be a significant knowledge and skill gap between them depending on 
> their area of expertise.
> This gap implicitly defines a hierarchy.

Indeed, emphasis on _implicitly_. I'm fine with such implicit
hierarchies, I'm not fine encoding them in Gitolite rules which does
tend to cement them.

> Not having such gates or boundaries between responsibilities in my opinion 
> will prevent new users from joining. Because either the existing dev base 
> trusts them (ultimately) with all tools or not.

Again, I'm not against gates, but they should be technical (i.e. unit
tests, CI, static analysis, maybe 2nd developer peer-review,
subsystem-level peer-review), but not project-global branch-level.

> Gaining this trust seems to be to be very subjective at that point. It would 
> be better to have new devs prove themselves, for example by demonstrating 
> that they have read coding guidelines or are capable of writing code or know 
> their way around documentation or CI and _then_ giving them respective access 
> and responsibilities.

As I said, ideally _nobody_ gets to go around the rules because of who
they are, and everybody has to stick to the _automated_ QA --- which can
obviously cover coding guidelines as well.  My recently broken emacs
setup introducing tabs should amply demonstrate that I cannot be trusted
to follow the rules without such "oversight". And I'd much rather focus
on improving QA automation than spend time reviewing patches.

> Before that, working with limited access rights (e.g. pull requests, patches) 
> seems a lot more reasonable.
> Trust in and respect of an individuals skill set can only ever be earned, 
> never be given out on a whim, I think this is fairly logical?

I don't see this so much as a trust issue, as long as the access that we
give out prevents damage.  The reason why fewer people have gitolite
admin is that those people could do actual damage.  But without force
pushes, and with Git hooks sending e-mail notifications, and with
(ideally) patches being read by people on the mailinglist, and with
various unit tests and integration tests in place, the _accidental_
damage unskilled individuals could do should be very limited, and the
damage _malicious_ individuals can do cannot be limited by forcing them
to 'earn trust by demonstrating technical prowess first' either.

> Anyway, no matter how you implement this process or even leave it as it 
> stands it will _always_ create a hierarchy. Of authority and of competence. 
> Those two are extremely difficult if not impossible to separate in social 
> interactions.

I'm not trying to eliminate the social hierarchy arising from merit. I'm
only arguing against encoding it in an access control policy -- with
exception to those bits of the infrastructure where too open access
could cause significant recovery work.

> This is also why I think giving git access to contributors immediately is 
> folly. You don't even know if more that this initial contribution will be 
> provided. Onboarding new devs should only happen if there is clear intent to 
> continuously contribute.

Well, making some first contribution(s) and signing the CA is usually a
good indicator that there is some intent to continuously contribute. I
may change my mind on that once handling CAs becomes a burden, but I'd
rather have a developer superfluously "onboarded" (mostly harmless) than
frustrate one by some (inherently subjective, ill-defined) vetting process.

> This is also why I find the fork+pullrequest vs project dev separation on 
> git{lab,hub} to be very effective as it takes into account all of the above.

For me, this sets the incentives completely wrong. Now you want to be
"dev" because you become recognized (and "powerful"). You draw a clear
line: inside and outside. Devs defend their decisions against non-devs,
devs automatically have more sway. Let's all go on Github to show on our
LinkedIn resume how many projects we are 'dev' on to earn more Microsaft
points.</sarcasm>  Oh, wait, did I just violate the COC set by the devs
by using sarcasm? Sorry for that, I guess I can screw joining the Circle
(thanks, Dave Eggers).

Maybe I'm a bit over the top here, but I really have bad feelings about
applying this corporate model for GNUnet.

> And if you are completely honest, we have such hierarchies. And you are at 
> the top. Now, you may reject this by saying "I am fine" with doing this or 
> that and saying that you happily give other devs access to do anything. But 
> the fact remains that people will ask _you_ for permission and advice 
> primarily.

Asking for my advice or opinion is always fine. But I do indeed reject
people asking for my _permission_.

> Because you are the most capable and powerful individual within this project. 
> No ideological mindset will change this fact. Even if you give the world 
> access to every aspect of GNUnet then there will be friendly contributors who 
> will still ask the more competent devs (e.g. you) for advice and permission. 
> The only difference in this case would be that destructive people will 
> eventually sabotage something.

As I said, asking for advice is fine. As for destruction, of course we
should limit access to actually destructive (git force push, branch
deletion, root, etc.) capabilities more tightly. But even there I worry
_more_ about things like what happened to i2p after jrandom disappeared
(nobody could update DNS for like a decade...) than about actually
(overtly) destructive actions. Moreover, I am not sure a permission
hierarchy is effective at stopping active sabotage by the kinds of
adversaries we are likely to have, and it might in fact be something
malicious actors would use to _their_ advantage.  After all, hierarchies
is something certain adversaries tend to understand well...

> Some basic readings in social/group psychology is enough if you need 
> background to support my thoughts on this. You cannot not have hierarchies.
> I sincerely urge anyone related to this project not to conflate the project 
> goal (decentralised/egalitarian system) with proper work organisation.
>

Sure. But can we please separate technical organization (access control
rules, branch management, etc.) from social organization?  And while
we're at it, please don't always think of me as being eternally present.
While I have no intention of stopping anytime soon, we need to strive to
make everybody redundant, me in particular. Which is why it is so
important that the system administration is put on more shoulders, and
that more people give talks, and that more people worry about how to
organize the process (again special thanks to Martin for pushing back
against me here) ;-)

I hope I've clarified a bit what I had in mind. Feel free to convince me
that I'm totally wrong ;-).

>>
>> 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
>>
>> -Christian
>>
>> _______________________________________________
>> GNUnet-developers mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnunet-developers
> 

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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