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

[ng0]

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