> that things can be improved without fracturing the already-small group.
It looks like the main project will be conservative enough to be simple to pull... A small fork will probably only change things that bother someone. Overall, this makes believable that the fork will be able to pull all changes from the remaining project, and the old part will be able to pick any changes from the fork that it agrees with. I think that all arguments that explain why this exchange will not be feasible should be mentioned - this can both uncover different values and help to motivate people on keeping the community less split. > a) Those who have concerns need to explicitly bring them up in a way > aimed toward fixing the problem while taking into account the reasons it > happened in the first place, rather than trying to place blame. Particularly > important here is that people recognize that any change will have a cost and > that different people in the project will have different opinions on the > relative weighting of the costs and benefits. Unfortunately, after the history with parallel builds I have no idea what happens. I cannot comprehend what values/fears lead to promoting what finally got committed. > b) Those who propose alternatives need to be willing to step up and do > the work necessary to implement those alternatives themselves. For example, > if you think too many emails to the list get dropped with no response, you > need to be willing to respond to as many of the emails as possible. I think it is a bad example - many emails going unreplied are a piece of evidence that we need not to discuss every step. So people who say that many ignored email are bad are those very people who say that we don't have to have to reply to everything. Maybe just try everything and simply keep all unproblematic changes. My personal pet grudge about gnutls upstream says that probably everything less destructive than GNU TLS update is not too problematic unless someone explicitly complains. _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev