New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC 0009] Nix rapid release #9

Closed
wants to merge 8 commits into
base: master
from

Conversation

Projects
None yet
9 participants
@shlevy
Member

shlevy commented Apr 4, 2017

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy
Member

shlevy commented Apr 4, 2017

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 4, 2017

Member

(I really wish I had commit access here so I could request reviewers etc....)

Member

shlevy commented Apr 4, 2017

(I really wish I had commit access here so I could request reviewers etc....)

@vcunat

This comment has been minimized.

Show comment
Hide comment
@vcunat

vcunat Apr 4, 2017

Member

👍 for the principle at least (I haven't read details yet).

Member

vcunat commented Apr 4, 2017

👍 for the principle at least (I haven't read details yet).

@Profpatsch

This comment has been minimized.

Show comment
Hide comment
@Profpatsch

Profpatsch Apr 4, 2017

Member

+1, one addition: Release nix 1.12 as nix 2.0.0 and do semver from there.

Member

Profpatsch commented Apr 4, 2017

+1, one addition: Release nix 1.12 as nix 2.0.0 and do semver from there.

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 4, 2017

Member

@Profpatsch good idea, pushed.

Member

shlevy commented Apr 4, 2017

@Profpatsch good idea, pushed.

@vcunat

This comment has been minimized.

Show comment
Hide comment
@vcunat

vcunat Apr 4, 2017

Member

The release number policy seems a mostly independent issue to me, and I wouldn't like to get blocked on that. For example, version 2.0.0 might suggest backward-incompatible changes in the nix language, but that's not really planned AFAIK.

Member

vcunat commented Apr 4, 2017

The release number policy seems a mostly independent issue to me, and I wouldn't like to get blocked on that. For example, version 2.0.0 might suggest backward-incompatible changes in the nix language, but that's not really planned AFAIK.

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 4, 2017

Member

It's not completely independent, but I'm not averse to changing it if that's the only concern.

Member

shlevy commented Apr 4, 2017

It's not completely independent, but I'm not averse to changing it if that's the only concern.

@domenkozar

This comment has been minimized.

Show comment
Hide comment
@domenkozar

domenkozar Apr 4, 2017

Member

I'm very much in favor of this :)

Member

domenkozar commented Apr 4, 2017

I'm very much in favor of this :)

@Profpatsch

This comment has been minimized.

Show comment
Hide comment
@Profpatsch

Profpatsch Apr 4, 2017

Member

For example, version 2.0.0 might suggest backward-incompatible changes in the nix language, but that's not really planned AFAIK.

Completely revamping the CLI interface (which is a major interface change) and rewrite of major parts in C++ (trimming 40MB from the package manager size) should be enough for a 2.0 I think.
Also there hasn’t been a release in over a year, so there’s probably lots of breaking changes apart from that.

Member

Profpatsch commented Apr 4, 2017

For example, version 2.0.0 might suggest backward-incompatible changes in the nix language, but that's not really planned AFAIK.

Completely revamping the CLI interface (which is a major interface change) and rewrite of major parts in C++ (trimming 40MB from the package manager size) should be enough for a 2.0 I think.
Also there hasn’t been a release in over a year, so there’s probably lots of breaking changes apart from that.

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 4, 2017

Member

The old interface still exists, FWIW.

Member

shlevy commented Apr 4, 2017

The old interface still exists, FWIW.

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 4, 2017

Member

@domenkozar Co-author?

Member

shlevy commented Apr 4, 2017

@domenkozar Co-author?

@shlevy shlevy requested a review from edolstra Apr 4, 2017

@zimbatm zimbatm changed the title from Add nix-rapid-release rfc to [RFC 009] Add nix-rapid-release rfc Apr 4, 2017

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 7, 2017

Member

@zimbatm This RFC clearly has community support, but no one has stepped up to be a coauthor. Frankly I think that requirement just creates more work than needed and requires RFC authors to be pests 😦 . Any chance we can remove it?

Member

shlevy commented Apr 7, 2017

@zimbatm This RFC clearly has community support, but no one has stepped up to be a coauthor. Frankly I think that requirement just creates more work than needed and requires RFC authors to be pests 😦 . Any chance we can remove it?

@Ekleog

This comment has been minimized.

Show comment
Hide comment
@Ekleog

Ekleog Apr 7, 2017

I don't really think 3 days' notice is enough to gather all counter-arguments that could potentially arise, but I guess that's orthogonal to the coauthor requirement (that said, if noone is stepping up to coauthor, given the really basic requirements for it, maybe it's not that much wanted by the community? -- anyway this discussion about removing coauthor should go somewhere, like in comments in a RFC to remove the requirement)

Then, here are two issues with this, to me. First, I think words like "Personally" should not appear in a RFC. The final text should be the One True Source of Wisdom once accepted, so personal opinion should not matter. But the real issue is that this RFC is too extreme in my opinion.

Stability of a program as defined by "ability to make a release" greatly varies depending on the project. Having master always building and passing the test suite is not an issue but clearly not enough, as test suites always let things through. I think that having a commit on master always meaning a release is just too much, for it means every PR has to be completely bug-free before being released.

That said, I think having a faster release cycle would indeed be useful. But there is a need to actually do something consistent, that lets bugs introduced by new PRs be discovered by the testers running off master branch (or even by manual functional testing, just before a release). An intermediate solution may be to simply tag all issues with a milestone, and as soon as all the issues tagged with the next milestone are solved it can be released.

This, assuming not too many features are tagged for the next milestone, means a fast release cycle (hopefully one new feature per release at most, serious issues can even get a bugfix release by just setting them as the only issue for the next milestone), better tracking of what still needs to be done for next release, yet still allows bugs to be discovered on master before the release, and also to be fixed before it by making the release depend on them.

What do you think about it?

Ekleog commented Apr 7, 2017

I don't really think 3 days' notice is enough to gather all counter-arguments that could potentially arise, but I guess that's orthogonal to the coauthor requirement (that said, if noone is stepping up to coauthor, given the really basic requirements for it, maybe it's not that much wanted by the community? -- anyway this discussion about removing coauthor should go somewhere, like in comments in a RFC to remove the requirement)

Then, here are two issues with this, to me. First, I think words like "Personally" should not appear in a RFC. The final text should be the One True Source of Wisdom once accepted, so personal opinion should not matter. But the real issue is that this RFC is too extreme in my opinion.

Stability of a program as defined by "ability to make a release" greatly varies depending on the project. Having master always building and passing the test suite is not an issue but clearly not enough, as test suites always let things through. I think that having a commit on master always meaning a release is just too much, for it means every PR has to be completely bug-free before being released.

That said, I think having a faster release cycle would indeed be useful. But there is a need to actually do something consistent, that lets bugs introduced by new PRs be discovered by the testers running off master branch (or even by manual functional testing, just before a release). An intermediate solution may be to simply tag all issues with a milestone, and as soon as all the issues tagged with the next milestone are solved it can be released.

This, assuming not too many features are tagged for the next milestone, means a fast release cycle (hopefully one new feature per release at most, serious issues can even get a bugfix release by just setting them as the only issue for the next milestone), better tracking of what still needs to be done for next release, yet still allows bugs to be discovered on master before the release, and also to be fixed before it by making the release depend on them.

What do you think about it?

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 7, 2017

Member

@Ekleog

I don't really think 3 days' notice is enough to gather all counter-arguments that could potentially arise, but I guess that's orthogonal to the coauthor requirement

Yeah, I wasn't expecting everyone to chime in in 3 days! Just that a bunch of people have expressed lots of support for this one. I don't think it's really a reflection of how much interest there really is, but maybe I'm wrong there.

anyway this discussion about removing coauthor should go somewhere, like in comments in a RFC to remove the requirement

Yeah, I wanted to open up an issue but this repo has them disabled 😮 Not sure this really merits an RFC... And who would coauthor it? 😁

First, I think words like "Personally" should not appear in a RFC. The final text should be the One True Source of Wisdom once accepted, so personal opinion should not matter.

Fair point, I'll remove that bit.

Having master always building and passing the test suite is not an issue but clearly not enough, as test suites always let things through.

This is always true and why we have bug fixes and PR authors should be careful to manuall test and think of corner cases. I don't think we get significant extra test coverage by having long release cycles.

I think that having a commit on master always meaning a release is just too much, for it means every PR has to be completely bug-free before being released.

That's removed now, if there has been a big feature merge recently we can hold off until testing can happen if need be.

That said, I think having a faster release cycle would indeed be useful. But there is a need to actually do something consistent, that lets bugs introduced by new PRs be discovered by the testers running off master branch (or even by manual functional testing, just before a release).

I'm not sure what this means/how it differs from my idea

An intermediate solution may be to simply tag all issues with a milestone, and as soon as all the issues tagged with the next milestone are solved it can be released.

In my experience these just grow, and aren't maintained well.

What do you think about it?

Personally I think just a delay/testing window manually imposed when a change is worrisome is a better approach.

Member

shlevy commented Apr 7, 2017

@Ekleog

I don't really think 3 days' notice is enough to gather all counter-arguments that could potentially arise, but I guess that's orthogonal to the coauthor requirement

Yeah, I wasn't expecting everyone to chime in in 3 days! Just that a bunch of people have expressed lots of support for this one. I don't think it's really a reflection of how much interest there really is, but maybe I'm wrong there.

anyway this discussion about removing coauthor should go somewhere, like in comments in a RFC to remove the requirement

Yeah, I wanted to open up an issue but this repo has them disabled 😮 Not sure this really merits an RFC... And who would coauthor it? 😁

First, I think words like "Personally" should not appear in a RFC. The final text should be the One True Source of Wisdom once accepted, so personal opinion should not matter.

Fair point, I'll remove that bit.

Having master always building and passing the test suite is not an issue but clearly not enough, as test suites always let things through.

This is always true and why we have bug fixes and PR authors should be careful to manuall test and think of corner cases. I don't think we get significant extra test coverage by having long release cycles.

I think that having a commit on master always meaning a release is just too much, for it means every PR has to be completely bug-free before being released.

That's removed now, if there has been a big feature merge recently we can hold off until testing can happen if need be.

That said, I think having a faster release cycle would indeed be useful. But there is a need to actually do something consistent, that lets bugs introduced by new PRs be discovered by the testers running off master branch (or even by manual functional testing, just before a release).

I'm not sure what this means/how it differs from my idea

An intermediate solution may be to simply tag all issues with a milestone, and as soon as all the issues tagged with the next milestone are solved it can be released.

In my experience these just grow, and aren't maintained well.

What do you think about it?

Personally I think just a delay/testing window manually imposed when a change is worrisome is a better approach.

@Ekleog

This comment has been minimized.

Show comment
Hide comment
@Ekleog

Ekleog Apr 7, 2017

Ekleog commented Apr 7, 2017

@edolstra edolstra changed the title from [RFC 009] Add nix-rapid-release rfc to [RFC 009] Nix rapid release Apr 10, 2017

@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Apr 11, 2017

Member

@shlevy the co-author is more interesting for long RFCs, it's to avoid having 1000 comments on typo and such when the important bit is the content. At the end of day it's just a process to help us.

I feel like this RFC is a reaction to 1.12 taking ages to be released. This is probably better solved by defining what's left to do to get 1.12 out of the door no?

Who is the release manager for nix, @edolstra? What are the steps required to get it released?

Member

zimbatm commented Apr 11, 2017

@shlevy the co-author is more interesting for long RFCs, it's to avoid having 1000 comments on typo and such when the important bit is the content. At the end of day it's just a process to help us.

I feel like this RFC is a reaction to 1.12 taking ages to be released. This is probably better solved by defining what's left to do to get 1.12 out of the door no?

Who is the release manager for nix, @edolstra? What are the steps required to get it released?

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 11, 2017

Member

@zimbatm It's not just about 1.12, it's been the norm for all previous nix releases and makes it difficult to solve problems that involve upstreaming features.

Member

shlevy commented Apr 11, 2017

@zimbatm It's not just about 1.12, it's been the norm for all previous nix releases and makes it difficult to solve problems that involve upstreaming features.

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Apr 11, 2017

Member

@shlevy I really ought not to be coauthor as I've never contributed to Nix itself and will be traveling in May, but if no one steps up I'll do it. It's very important that this happen.

Member

Ericson2314 commented Apr 11, 2017

@shlevy I really ought not to be coauthor as I've never contributed to Nix itself and will be traveling in May, but if no one steps up I'll do it. It's very important that this happen.

@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Apr 11, 2017

Member

@shlevy since this is a process-type RFC it should probably also identify who is in charge of release management. Who has the power to do it and who is volunteering to do it, what are the responsibilities, ... Otherwise the RFC will be discussed and there will be nobody to implement it.

Member

zimbatm commented Apr 11, 2017

@shlevy since this is a process-type RFC it should probably also identify who is in charge of release management. Who has the power to do it and who is volunteering to do it, what are the responsibilities, ... Otherwise the RFC will be discussed and there will be nobody to implement it.

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 11, 2017

Member

@zimbatm I'm happy to do it, and I would not be surprised if there are others if not me, but only @edolstra can decide that.

Member

shlevy commented Apr 11, 2017

@zimbatm I'm happy to do it, and I would not be surprised if there are others if not me, but only @edolstra can decide that.

@zimbatm zimbatm changed the title from [RFC 009] Nix rapid release to [RFC 0009] Nix rapid release Apr 13, 2017

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 19, 2017

Member

@edolstra Can you chime in here? This one seems to need your goahead

Member

shlevy commented Apr 19, 2017

@edolstra Can you chime in here? This one seems to need your goahead

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 27, 2017

Member

@edolstra can we expect a response either way from you here?

Member

shlevy commented Apr 27, 2017

@edolstra can we expect a response either way from you here?

@aneeshusa

This comment has been minimized.

Show comment
Hide comment
@aneeshusa

aneeshusa May 5, 2017

Big +1 from me on this RFC, especially having master more "release-ready" at all times - I work on other projects where this makes it much nicer to develop. I also think the RFC process can help with larger changes to Nix itself and help avoid regressions.
For Nix 1.12 (or 2.0) specifically, I would consider fixing NixOS/nix#1356 necessary before release.

aneeshusa commented May 5, 2017

Big +1 from me on this RFC, especially having master more "release-ready" at all times - I work on other projects where this makes it much nicer to develop. I also think the RFC process can help with larger changes to Nix itself and help avoid regressions.
For Nix 1.12 (or 2.0) specifically, I would consider fixing NixOS/nix#1356 necessary before release.

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Jun 3, 2017

Member

I will say, if #14 is passed, I will have a much more enjoyable time implementing it were this RFC policy.

Member

Ericson2314 commented Jun 3, 2017

I will say, if #14 is passed, I will have a much more enjoyable time implementing it were this RFC policy.

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Jun 7, 2017

Member

One compromise position might be to have a staging branch for DB schema transitions.

Member

Ericson2314 commented Jun 7, 2017

One compromise position might be to have a staging branch for DB schema transitions.

@Ekleog

This comment has been minimized.

Show comment
Hide comment
@Ekleog

Ekleog Jun 13, 2017

OK, so re-reading this thread, everyone seems to agree this RFC is needed, except me saying sometimes a bit of time between development of a new feature and a release may help.

Having re-read the RFC, I still think it's much better than the status quo, and would like to withdraw my negative comments (the thing I think I was opposed to was having a release on each master commit, the current state of the RFC looks great to me).

With this move made there seem to be no longer any negative comment.

Could we move forward, then? (I'm thinking having long-lived RFCs where everyone agrees is not a good thing for future RFCs to come up: it reduces the motivation of people to actually make them)

PS: I'm assuming @edolstra's not answering this thread is an implicit way to tell the community “you made the RFC process, now use it and stop relying on me so much”. Which would mean we should go forward and land this RFC if we actually want it implemented. If I'm wrong, please, by all means say it.

Ekleog commented Jun 13, 2017

OK, so re-reading this thread, everyone seems to agree this RFC is needed, except me saying sometimes a bit of time between development of a new feature and a release may help.

Having re-read the RFC, I still think it's much better than the status quo, and would like to withdraw my negative comments (the thing I think I was opposed to was having a release on each master commit, the current state of the RFC looks great to me).

With this move made there seem to be no longer any negative comment.

Could we move forward, then? (I'm thinking having long-lived RFCs where everyone agrees is not a good thing for future RFCs to come up: it reduces the motivation of people to actually make them)

PS: I'm assuming @edolstra's not answering this thread is an implicit way to tell the community “you made the RFC process, now use it and stop relying on me so much”. Which would mean we should go forward and land this RFC if we actually want it implemented. If I'm wrong, please, by all means say it.

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Jun 14, 2017

Member

@Ekleog I don't think that's a fair way to interpret @edolstra's lack of response here. I've been explicitly chastised for adding release tags to the nix repo without his say up until now and he is the primary active developer on the project. I don't see a way to proceed with this issue in particular without his say-so. And it would take 2 minutes for him to leave a comment suggesting that we should go ahead based on community consensus here.

Member

shlevy commented Jun 14, 2017

@Ekleog I don't think that's a fair way to interpret @edolstra's lack of response here. I've been explicitly chastised for adding release tags to the nix repo without his say up until now and he is the primary active developer on the project. I don't see a way to proceed with this issue in particular without his say-so. And it would take 2 minutes for him to leave a comment suggesting that we should go ahead based on community consensus here.

@domenkozar

This comment has been minimized.

Show comment
Hide comment
@domenkozar

domenkozar Jun 14, 2017

Member

Imho, the right way to go is to have a release manager, the same way we did for NixOS.

Member

domenkozar commented Jun 14, 2017

Imho, the right way to go is to have a release manager, the same way we did for NixOS.

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Jun 14, 2017

Member

Happy to do that or find someone to do it, but that process itself will require at least initial signoff from @edolstra

Member

shlevy commented Jun 14, 2017

Happy to do that or find someone to do it, but that process itself will require at least initial signoff from @edolstra

@Ekleog

This comment has been minimized.

Show comment
Hide comment
@Ekleog

Ekleog Jun 14, 2017

@shlevy You are right about the 2 minutes required to leave a comment suggesting we should go ahead based on community consensus, but what stuns me is that he actually changed the PR title on Apr 10 (meaning he noticed and read it), yet left no comment... Obviously, I may be wrongly interpreting it, and you have much more experience than me :)

Ekleog commented Jun 14, 2017

@shlevy You are right about the 2 minutes required to leave a comment suggesting we should go ahead based on community consensus, but what stuns me is that he actually changed the PR title on Apr 10 (meaning he noticed and read it), yet left no comment... Obviously, I may be wrongly interpreting it, and you have much more experience than me :)

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Jun 16, 2017

Member

I offered a few changes, mainly making the first two bullets stricter. What do you all think?

Member

Ericson2314 commented Jun 16, 2017

I offered a few changes, mainly making the first two bullets stricter. What do you all think?

@vcunat

This comment has been minimized.

Show comment
Hide comment
@vcunat

vcunat Jun 17, 2017

Member

I'm afraid the efforts are doomed unless/until Eelco shows some support. (I don't know if that might be helped by someone pledging some effort to make the releases happen.)

Member

vcunat commented Jun 17, 2017

I'm afraid the efforts are doomed unless/until Eelco shows some support. (I don't know if that might be helped by someone pledging some effort to make the releases happen.)

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Jun 18, 2017

Member

I'm willing to commit to reasonable efforts (including ensuring test coverage, making a timeline, tracking down bugs, etc.) to get the next release out and set us up to move on to a rapid release model if approved.

Member

shlevy commented Jun 18, 2017

I'm willing to commit to reasonable efforts (including ensuring test coverage, making a timeline, tracking down bugs, etc.) to get the next release out and set us up to move on to a rapid release model if approved.

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Jun 25, 2017

Member

@edolstra Can you please let us know what further info/changes/commitments would be necessary to enable to you make a decision on this?

Member

shlevy commented Jun 25, 2017

@edolstra Can you please let us know what further info/changes/commitments would be necessary to enable to you make a decision on this?

@Ekleog

This comment has been minimized.

Show comment
Hide comment
@Ekleog

Ekleog Jun 30, 2017

Given nixpkgs has to be compatible with stable nix (per policy), not having nix 1.12 blocks a number of potential changes (like the use of encryption as per RFC #5 when it's accepted, or nixos-prepare-root that would make for a cleaner implementation of #12, for the two that I can think of).

So having nix 1.12 released and then trying to release a bit more often would most likely help, even though obviously it doesn't mean to let bugs sink in a release, and this process of releasing often while not letting partially written modifications in is (I think) described here.

EDIT: This was initially an answer to @0xABAB's post from 2017-07-01, which appears to have been deleted since then. I will not repost it here, given he apparently wants it to not be readable, but this would make my comment unreadable without the details.

Ekleog commented Jun 30, 2017

Given nixpkgs has to be compatible with stable nix (per policy), not having nix 1.12 blocks a number of potential changes (like the use of encryption as per RFC #5 when it's accepted, or nixos-prepare-root that would make for a cleaner implementation of #12, for the two that I can think of).

So having nix 1.12 released and then trying to release a bit more often would most likely help, even though obviously it doesn't mean to let bugs sink in a release, and this process of releasing often while not letting partially written modifications in is (I think) described here.

EDIT: This was initially an answer to @0xABAB's post from 2017-07-01, which appears to have been deleted since then. I will not repost it here, given he apparently wants it to not be readable, but this would make my comment unreadable without the details.

@0xABAB

This comment has been minimized.

Show comment
Hide comment
@0xABAB

0xABAB Jul 2, 2017

@edolstra does vastly more work (apparently 9 times the number of commits of the second committer) on Nix. As such, while it would be cool if he would like to modify his way of working, we can't actually make him do this; without @edolstra there defacto is no Nix (but nixpkgs would still be viable).

I think if @edolstra doesn't ever respond, the only option is to fork.

I am not saying we should fork, because overall nix works fairly well and seems to improve over time.

This RFC is a bit like Australia and the UK voting about whether the US should invade Syria.

The way this should have been handled was sending an e-mail to @edolstra (assuming he doesn't mind those from @shlevy) asking whether he thinks it would be a good idea and if the most important stakeholder was on board (that's what the RFC process prescribes even) then it would have been a good time to ask what the rest of the community thinks about it (if at all), since defacto @edolstra's opinion is the only one which matters, due to the fact of him being the owner of the repository.

The only reason for asking the community would be to decrease the risk of alienating the community, but the risk of that is so incredibly low in that case that it doesn't seem useful to even ask.

0xABAB commented Jul 2, 2017

@edolstra does vastly more work (apparently 9 times the number of commits of the second committer) on Nix. As such, while it would be cool if he would like to modify his way of working, we can't actually make him do this; without @edolstra there defacto is no Nix (but nixpkgs would still be viable).

I think if @edolstra doesn't ever respond, the only option is to fork.

I am not saying we should fork, because overall nix works fairly well and seems to improve over time.

This RFC is a bit like Australia and the UK voting about whether the US should invade Syria.

The way this should have been handled was sending an e-mail to @edolstra (assuming he doesn't mind those from @shlevy) asking whether he thinks it would be a good idea and if the most important stakeholder was on board (that's what the RFC process prescribes even) then it would have been a good time to ask what the rest of the community thinks about it (if at all), since defacto @edolstra's opinion is the only one which matters, due to the fact of him being the owner of the repository.

The only reason for asking the community would be to decrease the risk of alienating the community, but the risk of that is so incredibly low in that case that it doesn't seem useful to even ask.

@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Jul 2, 2017

Member

I still think this RFC is a reaction to 1.12 taking ages to be released. And @edolstra is not communicating which makes it hard to know what to do next. I can only guess but I'm assuming there are two major reasons not to do the release:

  • Not enough testing. The tool is not stable enough.
  • The new UX is not ready. It's a big change which has deep implications for the future so understandably one would want to make sure it's in the right shape.

Based on those assumptions I would say that the best path forward is to (1) find and fix all remaining stability issues. (2) make a nix 1.12 release where the nix dispatcher is disabled. That would let us have the release while still maturing the nix dispatcher.

Member

zimbatm commented Jul 2, 2017

I still think this RFC is a reaction to 1.12 taking ages to be released. And @edolstra is not communicating which makes it hard to know what to do next. I can only guess but I'm assuming there are two major reasons not to do the release:

  • Not enough testing. The tool is not stable enough.
  • The new UX is not ready. It's a big change which has deep implications for the future so understandably one would want to make sure it's in the right shape.

Based on those assumptions I would say that the best path forward is to (1) find and fix all remaining stability issues. (2) make a nix 1.12 release where the nix dispatcher is disabled. That would let us have the release while still maturing the nix dispatcher.

@vcunat

This comment has been minimized.

Show comment
Hide comment
@vcunat

vcunat Jul 3, 2017

Member
  • (UX not ready): I don't think that's a reason to stop the release. The old nix-foo interface still works OK on 1.12pre* and we can explicitly say that the new nix command is experimental and possible to change completely.
Member

vcunat commented Jul 3, 2017

  • (UX not ready): I don't think that's a reason to stop the release. The old nix-foo interface still works OK on 1.12pre* and we can explicitly say that the new nix command is experimental and possible to change completely.
@vcunat

This comment has been minimized.

Show comment
Hide comment
@vcunat

vcunat Jul 3, 2017

Member
  • (not enough testing): look at Hydra:

    Hydra 0.1.1234.abcdef (using nix-1.12pre5413_b4b1f452).

    I think that's quite some testing by itself, at least for some parts of nix. It has one specific configuration, but some potential problems, e.g. recent setuid/setgid "failures" in builders, are detected that way. I've been running 1.12 on my machine where I do most of nix* stuff, as another small point.

Member

vcunat commented Jul 3, 2017

  • (not enough testing): look at Hydra:

    Hydra 0.1.1234.abcdef (using nix-1.12pre5413_b4b1f452).

    I think that's quite some testing by itself, at least for some parts of nix. It has one specific configuration, but some potential problems, e.g. recent setuid/setgid "failures" in builders, are detected that way. I've been running 1.12 on my machine where I do most of nix* stuff, as another small point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment