[Nix-dev] [proposal] Policy how to handle controversial commits

[Domen Kožar]

Fundamentally broken is most of the times opinionated. If a committed
package update breaks 1 reverse dependency, is it fundamentally broken?
What if that number is 10000? Where is the line?

At the end we're talking about the same workflow. I'm not saying it should
always be reverted, disagreeing developer might just push a trivial fix
instead. I'm saying that if a developer is unhappy about the commits he/she
can revert and discuss the implementation.

Essentially it's a veto against a change that should be used with caution.

On Wed, Feb 25, 2015 at 1:04 PM, Shea Levy <shea at shealevy.com> wrote:

> I don’t think we need 24 hour windows or anything. Don’t revert something
> that is just broken for trivial concerns if the other dev is actively
> responding, but don’t wait if something is fundamentally broken. My
> workflow here would be “see bad commit, revert, open discussion on the
> revert commit”. Why do we need anything more formal?
>
> On Feb 25, 2015, at 6:52 AM, Domen Kožar <domen at dev.si> wrote:
>
> Hi all,
>
> this is a follow-up on the discussion about a set of controversial
> commits[0]. By controversial I mean that two or more developers don't agree
> on the implementation.
>
> Let's ignore the context of disagreement and anything else not relevant to
> the commits in question that are already in any of the official branches
> (in case of NixOS, master or release-XX.XX).
>
> Assumptions:
>
> - core developers have commit access and don't have to open pull requests
> for all the changes they make
>
> Proposal:
>
> If two or more developers disagree on the implementation of a commit or
> sets of commits, commit(s) in question can be reverted after 24h (since the
> start of the discussion) by any party and pull requests can be opened to
> address the issue with different approaches.
>
> 24h window is open so that the developer that committed has time to fix
> trivial issues.
>
> Main motivation is that discussion and review is important. If commits are
> already in official branches that means that developers will base their
> work on top of that, which might result into different kinds of problems
> later on.
>
> PS: a typical commit that falls into this category is a change that breaks
> many other packages
>
> PS2: please assume the current workflow we have in nixpkgs. This proposal
> is not how to change the workflow, but how to handle issues that come up
> during it's practice
>
> [0] http://lists.science.uu.nl/pipermail/nix-dev/2015-February/016381.html
>
>
> Domen
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150225/911902f2/attachment.html