[Nix-dev] 6 month C4 adoption period

[Shea Levy]

stewart mackenzie <setori88 at gmail.com> writes:
>  Having @globin close the PR without a complete understanding

From the discussion there, globin understood your change perfectly well
and his closure was appropriate.

> Notice eelco saying lowprio is needed yet [1] has landed in mainline.

You are the one failing to understand what happened here. lowPrio is
needed for beta/unstable packages exposed to nix-env. I pushed that
commit because rustBeta and rustUnstable are package *sets*, not
packages, which lack recurseIntoAttrs and thus aren't exposed to
nix-env. Thus, the lowPrio was doing nothing. But this has *nothing* to
do with your original PR or the issue you were dealing with there, and
only came up because I was trying to demonstrate to you how lowPrio
actually worked.

> If you guys are not prepared to break apart this forming 'in
> crowd' with the C4, then what are your procedures on removing cultivated
> bad maintainers, or will you just let this become a systemic problem?

Show us a real example of a bad maintainer or even a maintainer behaving
badly, then we can discuss solving that problem. But note that "discuss
solving the problem" is not the same as "accept the solution you propose
without justification". If there is an issue with maintainer
behavior/incentives, and I don't really think there is in the sense you
are saying, then it does not automatically follow that we must adopt C4.

> Shall I reciprocate with the same level of rudeness I receive
> when submitting a patch?

In all of the discussions relating to this, you are the only one I've
seen being rude so far.

> Then to have another PR created [1] by the person who didn't take the time
> or energy to even read or understand the C4.

I think your links were messed up here, both of the PRs in your link
list were created by you. If, however, you are referring to the commit
where I removed the lowPrio from rustUnstable and rustBeta: I read the
link you provided. It did not immediately strike me as useful nor did it
provide justification for itself. I gave you every opportunity to
clarify, and you were rude and implied I was blind to the obvious. I
disagree with you, that is not the same as not taking the time or energy
to engage with you.

> This Moritz is the straw breaking the camel's back

What, where did moritz come into this conversation?

> Having people go around running algos on your level of
> commitment is such utter and total bullshit.

Can you point to an example of this happening? If it is actually
occurring, I agree it's bullshit and should be stopped if possible.

> Maybe I should just stop interacting with
> the nix crowd? Would you prefer that? If you'll let me maintain 1, only 1
> package on nixpkgs - a nix shell I'm developing. That's it I promise. I
> won't touch any other code. (See how mental that is?)

No one asked you to make this promise, so don't blame us for how
"mental" you think it is.

> Think about it for a second, when has the legal system ever passed laws to
> limit it's own power?

Who do you think signs constitutions?

> Passing the C4 will limit even Eelco's power. Imagine
> every single maintainer not being able to merge their own commits.

That sounds like a very inefficient state of affairs, with no clear benefit.


> The way lethalman handled this PR of mine is exactly the correct way [3]
> except there should have been no dialogue or at least reducing as much
> upfront consensus as possible

Why do we have PRs at all if they're just going to be merged automatically?

> Indeed, this is exactly what @globin should have done, cause I would
> have fixed it if it was broken, why? Cause that bit of code is in my
> L1 cache not @globin's. If for example I broke it and didn't fix it
> again, revert my commit.

globin saw, correctly, that your patch was broken. Why should it be
merged if it is known to be wrong?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160831/9aee0f80/attachment.sig>