[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Florian Dold
Subject: Re: [GNUnet-developers] Updating my git work-in-progess branch?
Date: Sat, 16 Mar 2019 22:32:48 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

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.

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.

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
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]