Re: [Nix-dev] Commit access

Hi, On 29/02/16 17:29, Eelco Dolstra wrote: > Obviously we do not have such clearly delineated responsibilities at the > moment. > So what we need is something like the Linux kernel's MAINTAINERS file, listing > who is responsible for what topic. Examples of subsystems would be: [snip] I've

Re: [Nix-dev] Commit access

>Can we skip the discussion about changing VCS ? It's related but really >tangent to the actual thread. Yes, sorry, should probably have done two replies, with one of them off-list. I am not advocating switching the VCS for NixPkgs now. Initially I just explained why I am not doing anything

Re: [Nix-dev] Commit access

Re: automated LibreOffice UI tests: this promises to be complicated. >>I rank reasonableness of notions used in UI as >> monotone > mercurial > SVN > git >> >> I am currently undecided about fossil, although it is definitely in the >> left half of the chain. >> > >I guess, I'll have to take a

Re: [Nix-dev] Commit access

On 03/01/2016 12:35 AM, Herwig Hochleitner wrote: > For me, whenever I have to use github, I'm like "ugh, why can't i use magit You can fetch the PRs as branches; the refspec is refs/pull/*/head. Then, if you merge them into master by hand, the github PR will auto-close. You can't well see the

Re: [Nix-dev] Commit access

> This is kind of where things are at with hydra channels. Hydra currently *polls* master periodically, whereas with this github *pushes* to hydra/travis/etc, and they git push back to master if the PR passes. This distinction is really important if we want to never break master. The catch is

Re: [Nix-dev] Commit access

2016-03-01 1:06 GMT+01:00 Michael Raskin <7c6f4...@mail.ru>: > > Last time I breaked a thing (and it was recently), it was my commit and > I actually used the resulting binary for some time. Didn't notice the > open dialog was broken. So the question is about price-vs-quality, > testing doesn't

Re: [Nix-dev] Commit access

2016-03-01 0:21 GMT+01:00 ben...@gmail.com : > I would love to see a workflow involving a merge queue, where normally > humans should never push directly to master nor click merge on pull > requests, > This is kind of where things are at with hydra channels. > but instead: >

Re: [Nix-dev] Commit access

>> I do read the patch before; and in many cases I do know what the fallout >> will be. >Sorry, I have to call you on that. Everybody programmer thinks that they >can tell what code does (and they often can), but bugs, you know. Last time I breaked a thing (and it was recently), it was my commit

Re: [Nix-dev] Commit access

2016-03-01 0:17 GMT+01:00 Michael Raskin <7c6f4...@mail.ru>: > > I do read the patch before; and in many cases I do know what the fallout > will be. > Sorry, I have to call you on that. Everybody programmer thinks that they can tell what code does (and they often can), but bugs, you know. Yes,

Re: [Nix-dev] Commit access

I would love to see a workflow involving a merge queue, where normally humans should never push directly to master nor click merge on pull requests, but instead: 1. developer opens pull request 2. travis runs tests, posts results as usual 3. someone with approval/commit rights comments: "nixbot:

Re: [Nix-dev] Commit access

>What does concern me slightly, is the number of merge commits, that I see >in master. Those are usually created by just pressing the merge button. >When actually reviewing stuff, people tend to locally rebase/apply, test to >various stages, and then push. In github, this is visible by "commited

Re: [Nix-dev] Commit access

IMO the mention bot already does a great job at getting notified without having to watch the whole repo. The next thing would be to get a more reliable and fast CI for the PRs. Right now there are too many false negatives which trains us to ignore the red. Waiting for hours for something small to

Re: [Nix-dev] Commit access

Before nix made me dust off my curlies and semicolons again, I have been active in the clojure community. This is relevant to the discussion, because in clojure, we have pretty much the exact opposite contribution policy from nix: Every single contributed patch has to go by Rich Hickey, after

Re: [Nix-dev] Commit access

On Mon, Feb 29, 2016 at 11:41 AM, Guillaume Maudoux (Layus) wrote: > But on the other hand, I like the ability to submit a pull-request that > adds a package, a NixOS module and documentation while also bumping the > version of some dependencies. It makes it clear that one

Re: [Nix-dev] Commit access

Another -1 for multiple repos. We've been fairly good at abstraction and refactoring, and this would serious impair our abilities with regard to both. On Mon, Feb 29, 2016 at 10:02 AM, stewart mackenzie wrote: > Clear support for Layus' points. > > I'll mention another point

Re: [Nix-dev] Commit access

Clear support for Layus' points. I'll mention another point more clearly. Eschew hierarchy & consensus Adopt the Advice Process: Before making a decision seek advice from expertise, then seek advice from those you'll affect. Neither group can veto your decision. Maintainers who do not do this

Re: [Nix-dev] Commit access

>But on the other hand, I like the ability to submit a pull-request that >adds a package, a NixOS module and documentation while also bumping the >version of some dependencies. It makes it clear that one bunch of >changes are related. > >Having different repos brings the difficulty to make

Re: [Nix-dev] Commit access

Le 29/02/16 18:28, Thomas Tuegel a écrit : > On Mon, Feb 29, 2016 at 10:29 AM, Eelco Dolstra > wrote: >> Then when you make a PR, you should look up the responsible maintainer and >> assign the PR to them. Having every PR assigned to somebody should also help >>

Re: [Nix-dev] Commit access

On Mon, Feb 29, 2016 at 10:29 AM, Eelco Dolstra wrote: > Then when you make a PR, you should look up the responsible maintainer and > assign the PR to them. Having every PR assigned to somebody should also help > prevent them from falling through the cracks. If we

Re: [Nix-dev] Commit access

>Then when you make a PR, you should look up the responsible maintainer and >assign the PR to them. Having every PR assigned to somebody should also help >prevent them from falling through the cracks. I would say that making sure every part of NixPkgs and NixOS has a maintainer distinct from

Re: [Nix-dev] Commit access

Hi, On 29/02/16 15:15, Matthias Beyer wrote: >> This is a tree-like model like it is used in other distributions and big >> projects like the kernel or git itself. I originally proposed such a model way back when we switched to Git, but it was not well received :-) Having a fairly high number

Re: [Nix-dev] Commit access

On Mon, Feb 29, 2016 at 8:15 AM, Matthias Beyer wrote: > As this discussion seems to happen outside of the mailinglist, I resend this, > so > everyone on the ML knows: > > On 28-02-2016 15:23:48, Matthias Beyer wrote: >> On 24-02-2016 11:43:22, Michael Raskin wrote: >> > I

Re: [Nix-dev] Commit access

As this discussion seems to happen outside of the mailinglist, I resend this, so everyone on the ML knows: On 28-02-2016 15:23:48, Matthias Beyer wrote: > On 24-02-2016 11:43:22, Michael Raskin wrote: > > I have fixed and ran the vanity counter script. > > > > My impression is: if any of the

[Nix-dev] Commit Access

Hi, May I please have commit access, mainly to better maintain my packages. My Github username is rushmorem. Kind regards, Rushmore ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Commit access request (Again: Why don't these peoplehave commit access)

2 - I am seriously studying to port Mate-Desktop and Trinity Desktop, two huge and confused projects to me. I am doing some hacking here and there, and when they became stable, I will do a huge and serious pull-request! Let me know if you need help, I packaged a fair portion of gnome3 so

Re: [Nix-dev] Commit access request (Again: Why don't these peoplehave commit access)

Well, I will speak for myself: 1 - Particularly I need to learn a lot about Nixpkgs culture. I really like it, but when the thing is easy as a GNU Hello package, I just use NixOS Monitor to updatetest. My biggest contribution was, until now, mpv player and maybe Altcoins (alas, I need to update

Re: [Nix-dev] Commit access request (Again: Why don't these people have commit access)

I guess I should use this opportunity to ask for commit access! I have been reluctant in the past to ask since I'm somewhat young contributor and even if it wouldn't be the case I still usually want to be sure that I did everything right though PR review. Nevertheless I want to go though my

Re: [Nix-dev] Commit access request (Again: Why don't these people have commit access)

On 20-01-2015 00:46:11, Nikolay Amiantov wrote: Nevertheless I want to go though my packages and do version bumps in the near future, and I believe this (and things like grammar fixes) is kind of patches that should be applied more directly than usual, to bother less contributors so that they

Re: [Nix-dev] Commit access request (Again: Why don't these peoplehave commit access)

I guess we should encourage merge fast policy for PRs like that, though from my experience it is already the case -- if it's just a version bump of a package which wouldn't trigger a libreoffice build or so (though libreoffice depends on everything so it's a bad metric ^_^), it usually would be

Re: [Nix-dev] Commit access request (Again: Why don't these people have commit access)

For this kind of thing the contributor involvement is mostly mechanical and (as I imagine) just requires someone going though all PRs, checking if Travis succeeds and the change is really trivial and merging them en masse. This happens from time to time, but using commit access for this if

Re: [Nix-dev] Commit access request (Again: Why don't these peoplehave commit access)

Doesn't that usually apply to big things that most people skip reviewing due to contributor's good standing and tl;dr (though it shouldn't be like this, too... '^_^)? On 01/20/2015 01:02 AM, Matthias Beyer wrote: On 20-01-2015 01:00:30, Michael Raskin wrote: Nevertheless I want to go though my

Re: [Nix-dev] Commit access

2012/6/27 Eelco Dolstra eelco.dols...@logicblox.com firefox: Updated to 14.0 Please-please-please let's use present imperative as Git (and many other projects) do? Something like firefox: Update to 14.0. I don't know why, but many projects prefer it, and I've read somewhere that imperative

Re: [Nix-dev] Commit access

Eelco Dolstra eelco.dols...@logicblox.com writes: Since there appears to be strong^Wpassionate support for having direct commit access to the main Nixpkgs/NixOS repositories, it's clear we should stick to the existing development model at the moment. So if you want commit access, please

Re: [Nix-dev] Commit access

Hi Kirill, On 27/06/12 03:18, Kirill Elagin wrote: firefox: Updated to 14.0 Please-please-please let's use present imperative as Git (and many other projects) do? Something like firefox: Update to 14.0. Good point, +1. -- Eelco Dolstra | LogicBlox, Inc. |

Re: [Nix-dev] Commit access

Quoting Antono Vasiljev (2012-06-27 14:18:34) Eelco Dolstra eelco.dols...@logicblox.com writes: Since there appears to be strong^Wpassionate support for having direct commit access to the main Nixpkgs/NixOS repositories, it's clear we should stick to the existing development model at the

[Nix-dev] Commit access

Hi all, Since there appears to be strong^Wpassionate support for having direct commit access to the main Nixpkgs/NixOS repositories, it's clear we should stick to the existing development model at the moment. So if you want commit access, please let me know your GitHub username and I'll add you