[RFC 0009] Nix rapid release #9
Conversation
|
(I really wish I had commit access here so I could request reviewers etc....) |
|
👍 for the principle at least (I haven't read details yet). |
c38e290 to
2151699
Compare
|
+1, one addition: Release nix |
|
@Profpatsch good idea, pushed. |
|
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. |
|
It's not completely independent, but I'm not averse to changing it if that's the only concern. |
|
I'm very much in favor of this :) |
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. |
|
The old interface still exists, FWIW. |
|
@domenkozar Co-author? |
|
@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? |
|
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? |
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.
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? 😁
Fair point, I'll remove that bit.
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.
That's removed now, if there has been a big feature merge recently we can hold off until testing can happen if need be.
I'm not sure what this means/how it differs from my idea
In my experience these just grow, and aren't maintained well.
Personally I think just a delay/testing window manually imposed when a change is worrisome is a better approach. |
|
On 04/07/2017 09:23 PM, Shea Levy wrote:
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.
Well, I've had experience with uncovering bugs introduced after the last
release while testing a new feature I was implementing on another big
community-based project, so I guess it's actually useful.
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
Well, that was just stating that people who test corner cases of a new
commit on master can find a bug in a previous commit of master, and hope
it's not released yet.
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.
If it's strictly defined as in "when a release is made, a number of
features for the next release is picked from the open issues list, then
nothing else than *important* bugfixes can be added to the milestone",
and not adding any feature before the release, then it wouldn't grow,
would it? And it doesn't require any maintenance over just closing the
issues and picking which ones to work on ahead of time, which anyway is
necessary.
It would be a kind of "feature freeze": at release time, the features
for the next release are already selected.
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.
Unfortunately worrisome changes are maybe not the only important ones.
Like, I've sometimes unwillingly written code that looked innocuous, did
little, but as the project was huge (like nixpkgs is), it had a
side-effect on a completely unrelated part of the code. This kind of bug
introduction is what can hopefully be found by someone working on
another feature that would touch this part of the code.
Then of course, the number of features added between two releases would
have to be small, in order not to have something too slow to move
forward, but it would give at least a view of why the next release is
not out yet, which is what I think we maybe need most (I'm pretty sure
there is a valid reason), and a way to know what to fix in order to get
it out.
It would be a kind of improved TODO-list, in my mind.
That said, I'll let someone else chime in on this topic, as obviously
I'll be biased towards my idea, and I think I explained it clearly
enough for it to be understood :)
|
|
@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? |
|
@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. |
|
@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. |
|
@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. |
|
@edolstra Can you chime in here? This one seems to need your goahead |
|
@edolstra can we expect a response either way from you here? |
|
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. |
|
I will say, if #14 is passed, I will have a much more enjoyable time implementing it were this RFC policy. |
|
One compromise position might be to have a |
|
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 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. |
|
Imho, the right way to go is to have a release manager, the same way we did for NixOS. |
|
Happy to do that or find someone to do it, but that process itself will require at least initial signoff from @edolstra |
|
@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 :) |
- First two bullets are made more strict - Downside is elaborated - General word-smithing
|
I offered a few changes, mainly making the first two bullets stricter. What do you all think? |
|
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.) |
|
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. |
|
@edolstra Can you please let us know what further info/changes/commitments would be necessary to enable to you make a decision on this? |
|
Given 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. |
|
@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 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. |
|
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:
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 |
|
|
Rendered: https://github.com/shlevy/rfcs/blob/nix-rapid-release/rfcs/0009-nix-rapid-release.md