IRC channel logs
2022-06-01.log
back to list of logs
<zimoun>Although I push for broad Guix adoption, time to time, I have the same feeling about Guix. Hard to use in production… a regular Guix contributor must be around to make it work for simple cases; when it is not the case for Conda or regular distros. Arf. <rekado>I think a lot of this comes down to a lack of actionable monitoring <rekado>cuirass still isn’t quite good enough to tell us why something broke <rekado>so we can’t easily ensure that packages build fine <rekado>“it’s hard to know what is expected to work” is what I sometimes feel wen using Guix <zimoun>to me, it would help if the code would not be pushed to master and in the same time end-user directly pulling this code. <zimoun>I hit one issue, I prepare a fix, I submit, patch applied, I pull, well the initial issue is fixed but in the mean time another can appear… <zimoun>Few people are working with Debian unstable or Sid. Only the powerful Debian users. In Guix, we are all using an equivalent of Debian unstable. <zimoun>it is luck that the build succeeded and it is really easy to break <rekado>yes, I think sometimes the attitude towards the master branch is a little too loose. <rekado>there are times when I’m just fixing problem after problem with some Python things that I don’t care about and that nobody cared about enough to keep from breaking. <rekado>I would like there to be … proper CI <rekado>push, let it be built, apply automatically when nothing broke. <rekado>but when it comes to *features* and the ability to implement a reproducible vision I think it’s all worth it. <rekado>there are use cases that are certainly not straight-forward in Guix, but we’ve got all the tools. <rekado>it would be great to connect them better and make them easier <rekado>it should totally be possible to do this without the 100 lines of code I ended up writing <rekado>but: it’s incredible that it *can* be done with the infrastructure that we’ve got, and that the result is reproducible and can be relied upon <zimoun>I agree. To me, the main issue is social and how we self-organize. <zimoun>IMHO, all patches touching guix/ should go to master, all about gnu/ to staging. Every 2-3 months, we merge staging to master. <zimoun>Or maybe even shorter than 2-3 months. <zimoun>in any organization at scale, you have a “stable” / production thing and another “unstable” / test thing. <zimoun>master should be “stable” and staging “unstable”. <zimoun>Powerful Guix users can follow this new staging (equivalent to the current master). Regular users follow the new master which just works (modulo bugs ;-)) <zimoun>I mean, bug fixes concerning Guix proper. <rekado>I think there’s value in getting new packages into Guix more quickly than 2-3 months. <civodul>zimoun: yeah, i read that Julia article some time ago; i share your uneasiness regarding occasional breakage in Guix <civodul>but yeah, there's a tension between liveliness and "correctness" <rekado>but I think that the very fact that 1.3.0 is now about a year old also points to a failure in how we self-organize. <civodul>FWIW, Nixpkgs has always had the same problem <civodul>i've felt "failure to organize" the hard way over the last few months TBH <civodul>i think we must do as we always did: move forward <civodul>(it's a problem that "moving forward" always seems to fall on the same shoulders, but ranting won't help) <rekado>they need to be visible, I guess, so that contributors can find them <rekado>the “same shoulders” problem is odd. The discussion / rants about the state of KDE is just one step away from solving the problem: someone’s gotta take ownership of the problem and do something about it. <civodul>but that one isn't really a problem in my view <civodul>the problem is when for several months there were a couple of active committers <rekado>but some people seem to be passionate enough about it to request that *someone* do *something* about it. <rekado>review consistency is really weak. <rekado>I’m totally guilty of that, but there’s a limit to what I can do. <civodul>yes, there's a limit to what each of us can do <civodul>and there's no guilt to be had: each one contributes in some way <civodul>but we should collectively arrange to better distribute the less rewarding tasks <rekado>I often think that there have been really good suggestions about how mumi could be changed to assist these tasks, sending out emails to recent contributors to a module, etc <rekado>I’m very grateful to Arun, who has picked up mumi and made it better <civodul>Arun can be a driving force behind this <rekado>because I just can’t do all this hacking any more :( <civodul>that's okay, there's life beyond the good hack :-) <rekado>gotta make some pizzas now (and snack on some excellent fromage) <zimoun>breakage in self-organization cannot be solved without discussion (or ranting) and it is not up to one person championing a task. <rekado>re teams: I’ll try to submit a simple patch for the website later tonight. <zimoun>The issues I am talking are not new. Julien raises the issue on 2018, Mark on 2021 (for the most recent), civodul about release process on 2020, Björn on 2019, ng0 on 2017, etc. Many things in these threads are improving. But some issues are still visible because we are all using an equivalent to Debian unstable. <civodul>zimoun: ranting is counterproductive though, really :-) <civodul>what we need is committed people who push proposals forward <civodul>zimoun: discussing has nothing to do with ranting <civodul>reading a rant is exhausting, at least for me <civodul>i just feel bad when i read a rant, i don't feel energized to go ahead and do something <civodul>criticizing si different from ranting, too <civodul>we need to be critical about what we're doing, no doubt <civodul>but we can be critical without ranting IMO :-) <civodul>anyhow, the proposal above is interesting, but as you noted in the last paragraph, it looks like a déjà vu :-) <civodul>what would be new and definitely helpful in this proposal is the time-based schedule <civodul>but so far we failed collectively to do that <rekado>I wonder why that is and how it can be improved <civodul>rekado: they put less energy into the Hurd joke than we did :-) <civodul>re schedule, i think there are at least two problems: (1) having a person clearly identified as responsible, and (2) having a person committed <civodul>someone who's hacking on the thing cannot be the timekeeper <civodul>or it'll always be "let's make this one last change" <rekado>in the past it always seemed to me that release activity was usually pretty “reactive”. The release went out and *then* the activity started, because only *then* people noticed that their packages were broken. <rekado>it’s not for lack of communication <civodul>well, there's a lack of clarity/readability <civodul>if you're not following on a daily basis like the three of us, it's hard to tell what the status is, what's cooking, etc. <rekado>it’s not a great feeling that stuff will be broken because nobody else is going to care about the things I care about. <rekado>so whenever a release was coming up I *had* to get involved and make sure it’s not a huge disaster for me post release. <drakonis>shift the channel model to "stable, unstable, experimental" and provide a mechanism to explicitly choose the channel in which you're importing a module from <rekado>I think teams would help here too <civodul>yeah, though it could quickly become stale <civodul>we need to push all this and tweak it as we go <rekado>whoever “manages” the release could talk to the team “managers” <rekado>drakonis: this is essentially what zimoun proposed <civodul>meta-problem: organizational matters would require serious commitment from several people <zimoun>My feedback about being kind of time-keeper for release: it is frustating without commit access. Because I was waiting after people when I could do it. <civodul>and that's somewhat incompatible with hacking duties <rekado>drakonis, zimoun: to me this model has a very real up-front cost, whereas the current way “only” costs us on the side. <civodul>zimoun: interesting (i was glad you took that role back then!) <rekado>drakonis: often you can’t very well port a fix to a stable branch; it’s easier to upgrade the package. <zimoun>civodul: for instance, many trivial patches could be pushed but it is annoying to ping people asking them, again and again. *rekado sends email to guix-devel about guix-mentors@gnu.org list/alias <drakonis>being able to explicitly resolve which channel you're using procedures from would help with this <drakonis>it would also help if the three layers did not overlap too much <drakonis>the point would be to have a way to accept changes and make them available to users without needing to go through staging or core-updates <zimoun>Moreover, civodul I agree that « (1) having a person clearly identified as responsible, and (2) having a person committed » could a problem. I think it is important that a release manager (or a team) is clearly identified as such. <drakonis>having packages and services moved down the channel tower as they're known to be usable as opposed to having to maintain a huge branch that overlays on top of another <zimoun>drakonis: channels and branches are the same thing from a “guix pull” point of view. <drakonis>yes, but i mean the organization of such <drakonis>since the point wouldnt be making a channel that's a mirror of another but with changes on top <drakonis>which is the case with master, core-updates and staging <drakonis>the current guix channel model is predicated on having a large single repository such as guix on the bottom and then all of the extras on top of it <drakonis>doing this would enable pushing larger changes into a channel suited for that and let users and contributors consume it without the burden of running the branches for the main repository <drakonis>i'm not sure if i'm being clear with my intentions here <drakonis>anyways, what i mean is that core-updates and staging are not meant for consumption, this model would sidestep that issue <drakonis>simply by not having the burden of having to run the entirety of either branches in order to get some bigger changes <zimoun>Guix = guix proper + packages + extra. Well, extra is what we name channels, and it is decoupled from “guix proper + packages”. However “guix proper + packages” cannot be decoupled. <drakonis>now, i'm not saying to decouple guix proper + packages <zimoun>“guix proper + packages” is a branch of a Git repo. <drakonis>but what matters here is adding a couple layers to the process to make it cleaner <zimoun>So if you put “guix proper + packages” where packages are massive rebuild (core-updates) in a channel (another Git repo), then what is the difference with 2 branches with the same repo? <zimoun>could you define layers? What can of object it would be? <drakonis>unstable: a layer for non critical changes that may or may not cause unexpected behavior <drakonis>once that's dealt with, it can be graduated to stable <zimoun>I do not understand what “layer” mean here. <drakonis>a layer as in a channel on top of base guix for aiding with the process <drakonis>so far the branches for base guix have been all or nothing affairs <drakonis>collecting changes over a period of time to then merge back into master <zimoun>so you decouple “guix proper” and “packages”, no? <drakonis>no, its mainly about having an easier time moving patches to stable <drakonis>and at the same time, make it easier to test patches <drakonis>since you don't pull in a branch with a large set of patches that might break things unrelated to what you want <zimoun>ah, I understand but I do not see how it could work. The patches are not autonomous by themselves but on the top of a commit in a specific branch. <rekado>yay, found a bug in the containerization code of the GWL <rekado>this is from before the move to parameterized processes <rekado>containers need to know the location of inputs and outputs so these locations can be mounted <rekado>but with parameterized processes the process doesn’t actually know these locations until it receives them as arguments <rekado>the old containerization code doesn’t use the arguments, so it only mounted the correct directories by accident. <drakonis>i wonder if pijul would be nice for this experiment <civodul>rekado: oh, didn't know GWL was using call-with-container (right?), sounds fun <rekado>yes, it uses call-with-container, but I added this only because I could, not because there’s a great use case for it. <rekado>Olivier submitted a patch to run the examples in a container, and that’s how I detected the bug <zimoun>drakonis: yeah, pijul and “patches theory” could be nice