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

[ng0]

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.

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




> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers