Oh boy... pointy clicky interfaces are not my forte apparently :-/ Fixing
and sending update.
On Fri Dec 19 2014 at 11:23:20 AM Domen Kožar do...@dev.si wrote:
Shouldn't that be 20th December (tomorrow)?
On Thu, Dec 18, 2014 at 5:24 PM, Wout Mertens wout.mert...@gmail.com
wrote:
more
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20141220T12Z
DTEND:20141220T13Z
DTSTAMP:20141219T114424Z
ORGANIZER;CN=Wout Mertens:mailto:wout.mert...@gmail.com
UID:48v00n6pkmmhabikkidtu1f...@google.com
On 12/18/2014 01:33 PM, Eelco Dolstra wrote:
There have been a number of fixes to CUPS in the last few days. It was
pretty broken. Printing now works for me, including my USB printer at
home. I'm not using gutenprint, though.
Sorry, I missed Reply All' button previously -- update had indeed
Hi,
On 18/12/14 17:18, Wout Mertens wrote:
As a summary answer to all the answers, I think we should adopt a change log
as
described at http://keepachangelog.com/
We already have a place to document breaking changes, namely the NixOS release
notes in nixos/doc/manual/release-notes. I'm not
On Fri Dec 19 2014 at 3:02:34 PM Eelco Dolstra eelco.dols...@logicblox.com
wrote:
On 18/12/14 17:18, Wout Mertens wrote:
As a summary answer to all the answers, I think we should adopt a change
log as
described at http://keepachangelog.com/
We already have a place to document breaking
Hi,
On 19/12/14 15:10, Wout Mertens wrote:
We already have a place to document breaking changes, namely the NixOS
release
notes in nixos/doc/manual/release-__notes. I'm not in favour of having
multiple,
out-of-sync locations to keep this info.
Right, but those are not
Maybe we can think of a way to single-source (as in port the source changes
into two outputs, the .md file and the release notes)?
I'll be happy to help if I can :-)
On 19 Dec 2014, at 15:15, Eelco Dolstra eelco.dols...@logicblox.com wrote:
Hi,
On 19/12/14 15:10, Wout Mertens wrote:
stewart, the breaking changes are configuration definitions for the
unstable master branch, those can change I hope :)
On Fri Dec 19 2014 at 3:44:19 PM stewart mackenzie setor...@gmail.com
wrote:
This might sound a bit off-base, but could we please consider not
introducing feature breaking
Mikey, well given Eelco's comment it seems best to generate a CHANGELOG.md
from the XML file, but then I wonder if we should have one at all (apart
from the nice location).
The goals would be:
- Allow programmatic extraction of important changes between the current
nixos system and the one
Ah indeed thank you for the correction. Though my suggestion is to
adopt C4 in its entirety. There would be no unstable master branch. At
all times there is only one branch, that being master, and the stable
APIs as part of this master branch remain stable, to be depricated and
eventually made
Given that NixOS evolves rapidly compared to Rust (as a language), it's
going to be really hard to achieve that (without slowing down development
by orders of magnitude).
Note that API in NixOS is not defined, but if you're looking at it as NixOS
modules and packages, we're changing the API
A new thread is spawned.
I disagree that it would slow down development.
Issues would be merged much faster.
Regarding feature requests: The logic goes that you implement the
feature yourself. Don't nag core dev to satisfy your fanciful flights.
They'll burnout. Besides it'll increase community
Nix commit 524f89 changed libstore to use fork + unshare instead of
clone(2). The problem is that, in doing so, it also removed use of
CLONE_NEWPID and thus, (1) the build process no longer has PID 1, and
(2) build processes end up in the global PID space.
Adding CLONE_NEWPID to the unshare(2)
The minimal idea is: maintainers dont do 'deep' code reviews. They
just glance over the patch and make sure it qualifies as a correct
patch, as defined by C4. After travis goes green they hit merge.
If a bug gets in, its not their fault. The community responds quickly
with a fixing patch.
Main
The part that breaks occam's razor principle is: The community responds
quickly with a fixing patch.
On Fri, Dec 19, 2014 at 4:45 PM, stewart mackenzie setor...@gmail.com
wrote:
The minimal idea is: maintainers dont do 'deep' code reviews. They
just glance over the patch and make sure it
I disagree I've closed patches because I cant be bothered arguing
about the nitty gritty. If patches are merged quickly and efficiently
the contributor gets an endorphin boost which is addictive. This
creates a positive feedback loop in that you get more participation.
Sure, but who is going to be the janitor? Merging patches without any
responsibility means someone needs to do the dirty work.
On Fri, Dec 19, 2014 at 4:55 PM, stewart mackenzie setor...@gmail.com
wrote:
I disagree I've closed patches because I cant be bothered arguing
about the nitty gritty.
Checking that the patch is correct then hitting the merge button is
hardly dirty work, but its better than deep code review maintainers
burning out, whom tend to become a tad nasty. Causing a vicious cycle.
Who does the dirty work? Those people whom are affected by the
introduced problem. Whom
On 19/12/2014 17:21, stewart mackenzie wrote:
Checking that the patch is correct then hitting the merge button is
hardly dirty work, but its better than deep code review maintainers
burning out, whom tend to become a tad nasty. Causing a vicious cycle.
Who does the dirty work? Those people
Hi,
On 18/12/14 17:32, Ludovic Courtès wrote:
Thus, I think Nix commit 49fe95 (which introduces monitor-fd.hh, which
uses std::thread just for convenience) should be reverted, along with
the subsequent commits to that file; then commit 524f89 can be reverted.
I really don't want to get rid
Can't you unshare in the parent then setns back after fork?
On Dec 19, 2014, at 18:20, Eelco Dolstra eelco.dols...@logicblox.com wrote:
Hi,
On 18/12/14 17:32, Ludovic Courtès wrote:
Thus, I think Nix commit 49fe95 (which introduces monitor-fd.hh, which
uses std::thread just for
Hi,
On 19/12/14 19:41, Shea Levy wrote:
Can't you unshare in the parent then setns back after fork?
In a multi-threaded program, that sounds incredibly racy :-)
(Though it's not clear to me whether unshare() works on the current process or
the current thread. Manpage says process...)
--
Hi,
Eelco Dolstra eelco.dols...@logicblox.com skribis:
On 18/12/14 17:32, Ludovic Courtès wrote:
Thus, I think Nix commit 49fe95 (which introduces monitor-fd.hh, which
uses std::thread just for convenience) should be reverted, along with
the subsequent commits to that file; then commit
On Fri, Dec 19, 2014 at 10:31 PM, Ludovic Courtès l...@gnu.org wrote:
Hmm, I’m not convinced about the whole threads-for-convenience approach
à la Java. (I think the ideal is a single-threaded event loop; of
course we want to avoid IoC, and this is where FRP or monads come in.)
It is
On Fri, Dec 19, 2014 at 7:20 PM, Eelco Dolstra eelco.dols...@logicblox.com
wrote:
Hi,
On 18/12/14 17:32, Ludovic Courtès wrote:
Thus, I think Nix commit 49fe95 (which introduces monitor-fd.hh, which
uses std::thread just for convenience) should be reverted, along with
the subsequent
25 matches
Mail list logo
