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

[Schanzenbach, Martin]

> On 16. Mar 2019, at 21:17, Christian Grothoff <address@hidden> wrote:
> 
> 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 ;-).

I think we agree in all points.

My point essentially was that I think the "all or nothing" model is actually 
more restrictive than the fork/pull request model on gitlab/hub which makes a 
much clearer distinction between "project dev" and "outsider".
Then again, there is not much we can do about it anyway because the CA stuff 
is, well, bureaucratic ;)
I am not even sure how we could enforce it technically.
Also, I like the change to allow user namespaces! (see later mails by fdold and 
ng0)


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

signature.asc
Description: Message signed with OpenPGP