> On 16. Mar 2019, at 21:17, Christian Grothoff <christ...@grothoff.org> wrote: > > On 3/16/19 11:39 AM, Schanzenbach, Martin wrote: >> >> >>> On 16. Mar 2019, at 02:18, Christian Grothoff <christ...@grothoff.org> >>> 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 >>> GNUnet-developers@gnu.org >>> https://lists.gnu.org/mailman/listinfo/gnunet-developers
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers