Eelco Dolstra eelco.dols...@logicblox.com writes:
Hi all,
I've completed the migration of Nixpkgs and NixOS to GitHub. This means that
the reposities
https://github.com/NixOS/nixpkgs
and
https://github.com/NixOS/nixos
are now the official Nixpkgs and NixOS repositories,
Well, I think, those who used to have commit access to SVN should get push
access to git. And they will be accepting pull-requests into the main tree.
They have to be responsible enough to read pull-request diffs carefully
and, if needed, ask colleague for help with review (GitHub has all those
Excerpts from Florian Friesdorf's message of Mon Jun 18 18:14:48 +0200 2012:
pth processing is not the issue, the issue is that some packages (like
matplotlib) do not create them as part of their install.
I don't know. I just ran a a simple gtk sample - and it worked (after
making sure gtk is
Hi Eelco,
On Jun 21, 2012, at 12:51 AM, Eelco Dolstra eelco.dols...@logicblox.com wrote:
Hi all,
I've completed the migration of Nixpkgs and NixOS to GitHub.
Hooray!
Please use GitHub's integrated bug tracker. It has the advantage that you
can
refer to or close issues from commit
I wonder if it is possible to give svn committers (we are known to be
pairwise distinct, I guess) right to accept any pull requests but their
own.
An interesting idea. Might not require a technical limitation, just a social
one. Get a warning if you accidentally merge your own and then
On Jun 21, 2012, at 9:30 AM, Eelco Dolstra eelco.dols...@logicblox.com wrote:
Also note that Nixpkgs shoould ship bleeding edge versions unless
there is some compelling reason.
Shouldn't?
~Shea
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
On 21/06/12 09:37, Shea Levy wrote:
Also note that Nixpkgs shoould ship bleeding edge versions unless
there is some compelling reason.
Shouldn't?
Indeed :-)
--
Eelco Dolstra | LogicBlox, Inc. | http://www.st.ewi.tudelft.nl/~dolstra/
___
nix-dev
Hi Eelco,
- A centralised workflow where people commit directly into the
master. This is basically what we did with Subversion. The downside
is a lack of review.
I am very much in favor of this approach because it forces the least
amount of administrative overhead on regular contributors
On Thu, Jun 21, 2012 at 10:59:22PM +0200, Peter Simons wrote:
Hi Eelco,
- A centralised workflow where people commit directly into the
master. This is basically what we did with Subversion. The downside
is a lack of review.
I am very much in favor of this approach because it forces
Hi!
Eelco Dolstra eelco.dols...@logicblox.com skribis:
I've completed the migration of Nixpkgs and NixOS to GitHub. This means that
the reposities
Congratulations, and thanks!
[...]
A hybrid policy is of course also possible. I.e. uncontroversial changes
(such
as minor package
- A centralised workflow where people commit directly into the
master. This is basically what we did with Subversion. The downside
is a lack of review.
I am very much in favor of this approach because it forces the least
amount of administrative overhead on regular contributors while
Hi,
On 21/06/12 17:16, Michael Raskin wrote:
- A centralised workflow where people commit directly into the
master. This is basically what we did with Subversion. The downside
is a lack of review.
I am very much in favor of this approach because it forces the least
amount of
Hi!
Michael Raskin 7c6f4...@mail.ru skribis:
I have an irrational
feeling that GNU TLS update is too often major even when version says
otherwise
For the record, I agree it’s probably irrational. ;-)
AFAIK, the main issue stems from running several builds in parallel on
the same physical
I am very much in favor of this approach because it forces the least
amount of administrative overhead on regular contributors while still
leaving the door open for non-regular contributors to submit patches via
pull requests. Personally, I do not want to open a pull request for
every little
Hi,
On 21/06/12 17:28, Michael Raskin wrote:
What problems are you talking about, and how would other approaches make
them worse?
Noticeable part of major feature proposals get neither positive nor
negative review and get buried by inaction before the next person who
could benefit of
Hi,
On 21/06/12 05:49, Kirill Elagin wrote:
Right now NixOS needs fast development. And small mistakes are not that fatal
—
NixOS is all about just reverting back if something goes wrong.
One slight complication here is that since GitHub doesn't disable
non-fast-forward commits, every
Noticeable part of major feature proposals get neither positive nor
negative review and get buried by inaction before the next person who
could benefit of the proposed changes appears.
That's bad, but the alternative can't be to just let everybody potentially poor
quality changes just because
On Fri, Jun 22, 2012 at 01:39:04AM +0400, Michael Raskin wrote:
Noticeable part of major feature proposals get neither positive nor
negative review and get buried by inaction before the next person who
could benefit of the proposed changes appears.
That's bad, but the alternative can't
Hi,
On 21/06/12 03:34, Mathijs Kwik wrote:
So I'm all in favor of having people just commit whatever they want
(once they've proven they somewhat know what they're doing). If others
don't like certain commits, roll them back and have some discussion.
That's the policy we've had with SVN
Michael Raskin 7c6f4...@mail.ru wrote:
(like in the case with the
parallel builds)
What's the story with parallel builds?
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
Hi,
On 21/06/12 17:07, Ludovic Courtès wrote:
A hybrid policy is of course also possible. I.e. uncontroversial changes
(such
as minor package upgrades in Nixpkgs) can go directly into the master, while
other things should be done in a branch and submitted for review. This of
course
(like in the case with the
parallel builds)
What's the story with parallel builds?
There was a proposal to introuce off-by-default support for parallel
builds on multicore computers. There was a patch that allowed user to
choose whether he wants to do the risky thing and use parallel builds.
Hi Eelco,
Noticeable part of major feature proposals get neither positive nor
negative review and get buried by inaction before the next person
who could benefit of the proposed changes appears.
That's bad, but the alternative can't be to just let everybody
potentially poor quality
2012/6/22 Eelco Dolstra eelco.dols...@logicblox.com
One slight complication here is that since GitHub doesn't disable
non-fast-forward commits, every committer actually *can* cause data loss
in the
repository.
You mean force push, right? This can be solved by keeping a reference repo
Eelco Dolstra eelco.dols...@logicblox.com skribis:
On 21/06/12 17:07, Ludovic Courtès wrote:
A hybrid policy is of course also possible. I.e. uncontroversial changes
(such
as minor package upgrades in Nixpkgs) can go directly into the master, while
other things should be done in a branch
On Jun 21, 2012, at 5:30 PM, Eelco Dolstra eelco.dols...@logicblox.com wrote:
Hi,
On 21/06/12 05:49, Kirill Elagin wrote:
Right now NixOS needs fast development. And small mistakes are not that
fatal —
NixOS is all about just reverting back if something goes wrong.
One slight
26 matches
Mail list logo
