[Nix-dev] Improving the Developer Experience in the Nix Community

[Shea Levy]

On Jun 27, 2012, at 10:48 AM, Lluís Batlle i Rossell <viric at viric.name> wrote:

> On Wed, Jun 27, 2012 at 04:32:33PM +0200, Petr Rockai wrote:
>> Shea Levy <shea at shealevy.com> writes:
>>> That's why I opened this thread, because we have people with different
>>> values but no one is really coming out and saying "this is what I
>>> want, this is why what's here now is bad".
>> 
>> I am more or less a bystander and not really active, but this caught my
>> attention (and the thread above). Above all, the main reason I am not
>> active is that it seems that submitting patches is a hit-or-miss
>> affair. They tend to get blackholed about as often as not. So I don't
>> submit any: I just locally fork any package that I need to change, and
>> in addition I keep a number of extra packages that way; basically, I
>> maintain a private overlay in /etc/nixos.
>> 
>> Now if there was a simple and documented way to submit patches
>> (*especially* new packages) that would actually work, it would probably
>> make my life easier, even as a bystander, by reducing the size of the
>> overlay significantly.
> 
> Well, I think that in SVN, it was easier for those who got commit access to
> put any change into the common repository, than to keep it apart.
> 
> With the movement to git, I think it's easier than before to keep an independant
> fork. Thus there should be more incentives to put the changes in common (easy
> commit access, reply to patches submitted, thanking and encouraging
> contributions by social dialog, ...), or more people will keep their work apart
> just to lower the effort.
> 

Hydra is a big one. Also I think in general having a change be 'official' and 'upstream' is a decent motivator. But I think the ability to keep things separately is actually a positive change in some respects, and probably some things that would have been committed now won't be. It's all a matter of finding the right balance.

> I think there should also be some some patch quality driven by example, too.
> For example, a committer should not be required to submit with
> 'longDescription', if current committers don't add longDescription in their
> commits (and other similar cases). The previous commits done by the usual
> committers should be an indication of the quality expected by those in the
> commiters round. I've the impression we have required to non-committers far more
> than what usual comitters do, making them rework their patches. This makes usual
> comitters look like people with some arbitrary advantage, not based on commit
> quality.
> 

This is definitely true and important. Whatever standards we have, they should be applied across the board, even if the standard is hard to easily quantify. Generally this requires that a) we actually have a commonly accepted set of standards (working on it!) and b) those who know the standards and the reasons for them be vigilant even toward well-established committers.

> And by commit quality I don't mean whether patches have a longDescription or
> not; it's about the usefulness of the commits to the rest of the community. So,
> a measure hard to describe by following guidelines alone.
> 
> Regards,
> Lluís.