On Mon, Jan 19, 2015, at 04:26 PM, Georges Dubus wrote:
> I'm under the impression that none of the proposal inspired by outside
> project seem to fit NixOS, because NixOS is a very different project : it
> is a huge and complex linux distro.
>
> The first consequence is that it is impossible to
On 20-01-2015 00:34:22, Michael Raskin wrote:
>
> >On the huge stream of changes part: Is it actually that much already?
> >How many packages are there per week, for example? I don't think it is
> >_that_ much, ...
> >
> >For example, there are currently 25 PRs on github with the tag
> >"new-packa
On 19-01-2015 22:26:00, Georges Dubus wrote:
>I'm under the impression that none of the proposal inspired by outside
>project seem to fit NixOS, because NixOS is a very different project : it
>is a huge and complex linux distro.
>
>The first consequence is that it is impossible to
I'm under the impression that none of the proposal inspired by outside
project seem to fit NixOS, because NixOS is a very different project : it
is a huge and complex linux distro.
The first consequence is that it is impossible to have expert on each part
on NixOS, because each tiny part requires
On 20-01-2015 00:10:29, Michael Raskin wrote:
> >* One (or two, or three,... but ideally just one) maintainers have
> > the responsibility that the new-packages branch actually _builds_
> > and should never commit broken packages onto it. If they fail with
> > this, they are bad.
On 19-01-2015 10:15:16, stewart mackenzie wrote:
> I request that we come up with a detailed and carefully thought out
> contribution guideline which evolves and grows.
I guess that would be the best idea, but I'm just a "Users voice" if
you want to name it this way.
So, be careful, Users voice a
On 01/19/2015 07:17 PM, Michael Raskin wrote:
To find out if a makefile is parallel-safe, we need to try it with
parallel building enabled. This can only be done package-per-package,
[...]
I see. What I said is only true for packages with enableParallelBuilding
= true;
Vladimir
smime.p7s
(Slight topic digression: parallel make.)
On 01/19/2015 06:59 AM, Michael Raskin wrote:
This is also the
reason why we have no idea which of the packages are safe to build in
parallel except for the few packages where someone explicitly tried.
Perhaps I don't understand you, but hydra.nixos.or
> Marc I think it's the general case of more complex PRs. PR that change too
> much or add too much tend to be delayed. Not only because they are harder
> to test, but also harder to agree on by more peopl
Well - I did take care - I added the new cups version as "opt-in".
It was your choice. You we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 19 Jan 2015 00:33:04 +
Marc Weber wrote:
>
> - I have patches pending for apache http and nginx making them more
> configurable (eg allowing to set the IP to listen to)
>
Do you mean listen address per virtual host ? That would be re
I request that we come up with a detailed and carefully thought out
contribution guideline which evolves and grows.
It should keep pychopaths under control, expand bottlenecks and make
this development process fun!
I've suggested Pieter Hintjens C4 and ensuing private discussions made
it clear th
Marc I think it's the general case of more complex PRs. PR that change too
much or add too much tend to be delayed. Not only because they are harder
to test, but also harder to agree on by more people.
Easy PR are in fact faster to be pushed.
Increasing the number of committers is certainly good.
I can only speak for myself:
In the past the community or some members didn't accept what I did for
various reasons. That's why I did no longer run for 'commit' access
since then.
A summary with some cases (some time has passed, maybe my memory is no
longer that accurate - but it should give an id
On Sun, Jan 18, 2015 at 07:53:35PM +0100, Moritz Ulrich wrote:
> Pascal Wittmann writes:
>
> > On 01/18/2015 06:19 PM, Nathan Bijnens wrote:
> >> While I don't mind that we expand the number of people with commit access,
> >> I firmly oppose doing changes directly on master, any change should fir
Pascal Wittmann writes:
> On 01/18/2015 06:19 PM, Nathan Bijnens wrote:
>> While I don't mind that we expand the number of people with commit access,
>> I firmly oppose doing changes directly on master, any change should first
>> be a PR. If there're more people who can close a PR, those PRs will
> Michael Raskin <7c6f4...@mail.ru> writes:
>> While I don't mind that we expand the number of people with commit access,
>> I firmly oppose doing changes directly on master, any change should first
>> be a PR. If there're more people who can close a PR, those PRs will be open
>> for a shorter
On 01/18/2015 06:19 PM, Nathan Bijnens wrote:
> While I don't mind that we expand the number of people with commit access,
> I firmly oppose doing changes directly on master, any change should first
> be a PR. If there're more people who can close a PR, those PRs will be open
> for a shorter amount
While I don't mind that we expand the number of people with commit access,
I firmly oppose doing changes directly on master, any change should first
be a PR. If there're more people who can close a PR, those PRs will be open
for a shorter amount of time.
Nathan.
---
nat...@nathan.gs | nathan.gs
<
I firmly support Michael Raskin, expanding maintainers widens the bottleneck.
Kind regards
Stewart
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
19 matches
Mail list logo
