n...@n0.is transcribed 16K bytes: > I'd have to cut lots of context, so I'll be excused for top posting: > > Certain parts of the code base would not allow hirachical structural > access if we wanted it to happen. > Documentation, which is code on it own, encoding knowledge about > the software etc, when it reaches the size of what we have now > can not rely on 1 or 2 people alone. Even more so when those > 2 people aren't working on it full time (at least 5 days / week). > Everyone should be invited to document to their best ability > what they know about the code. Comments could be treated the > same way - document verbosely under the assumption that either > you one day can no longer continue writing due to whatever > circumstances or someone with no prior exposure and no one > to explain details to them needs to make sense of the code > together with the documentation. > > Florian Dold transcribed 16K bytes: > > I agree with what you've said about not encoding hierarchies in > > gitolite. I also think that either nobody or everybody should be able > > to merge into master. > > > > The model of "nobody should push to master" is great if you have the > > right tooling on the server, but breaks GPG signing of commits by the > > author, AFAICT. > > /git admin head on/ > Makes sense, and setting up gpg signing on the server would create > a centralized point of trust we'd just have to take for granted as > guarded etc (I have no idea how our current/next location of the > server is organized nor should I have to care in the ideal case). > > > However, I very strongly disagree with what you said earlier about git > > rebasing, there seems to be some misunderstanding there. > > > > Rebasing a feature branch *on top of another branch* certainly doesn't > > require a force push. However, rebasing to clean up my own messy > > history of some work in progress *does* requires a force push! > > > > Maybe this is a terminology issue, because "git rebase" is used for both > > of these things ("merge"-via-rebase and WIP history cleanup). > > > > Let's say I'm working on my feature branch $foo, branching off from > > commit $xyz. Now after I've made some progress, I want to clean up my > > history, because there were a lot of useless "add/remove debug code" or > > "WIP" commits. If I squash/change the last N commits, I either need to > > abandon this particular feature branch to push my WIP to a new branch > > $foo2, or I need to merge my (possibly incomplete) feature into master. > > The latter is unacceptable, and the former creates lots of branches, > > one for every history cleanup I'm doing on my WIP. > > > > Especially with gitolite it's pretty trivial to allow force pushes only > > to branches following a pattern such as "wip/$name", I do not see any > > reason to not allow this. Force pushes to all other branches should be > > reserved for admins and avoided if at all possible. > > I think I would prefer a scheme of wip/$username/{branchnames} to be > force-pushable by $username with the knowledge that first this would > be communicated and second if people interact with each others branches > that they would talk about it first to prevent any technical difficulties > for each other (this however is out of the responsibilities and abilities > for gitolite ;)). > > Triage is good and would be good if people could do it for themselves > instead of occasionally checking which branch is either very inactive > or really not used at all anymore.
http://gitolite.com/gitolite/namespaces This is for a supposedly old outdated branch. TL;DR: does the job we want it to do, but I would not want to use this if rumours about this branch being outdated are true. I will look into the generic framework of repo.or.cz to see if we could just pull in changes from their actively used, well tested deployments. > /git admin hat off/ > > > But please, don't take away my ability to push/save work-in-progress, > > without having to clutter the whole repo with useless wip-flo-consensus1 > > wip-flo-consensus2 wip-flo-consensus3 and so on that I need to ask some > > admin to remove. > > > > - Florian > > > > On 3/16/19 9:17 PM, Christian Grothoff 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 ;-). > > > > > >>> > > >>> 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 > > >> > > > > > > > > > _______________________________________________ > > > GNUnet-developers mailing list > > > GNUnet-developers@gnu.org > > > https://lists.gnu.org/mailman/listinfo/gnunet-developers > > > > > > > > > > > _______________________________________________ > > GNUnet-developers mailing list > > GNUnet-developers@gnu.org > > https://lists.gnu.org/mailman/listinfo/gnunet-developers > > > _______________________________________________ > GNUnet-developers mailing list > GNUnet-developers@gnu.org > https://lists.gnu.org/mailman/listinfo/gnunet-developers > _______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers