| bvt: | diana_coman: thanks for the investigation! | [15:35] |
| diana_coman: | bvt: no worries; and let me know if there's any other weird you notice! | [16:17] |
| jfw: | bvt, comment in mod queue. | [16:18] |
| jfw: | diana_coman: thanks for refreshing that genesis/patch distinction. One part I'm not quite following is http://ossasepia.com/2020/04/21/ossasepia-logs-for-31-Mar-2020#1023434 , let me see how to put it. | [16:33] |
| ossabot: | Logged on 2020-03-31 04:41:08 diana_coman: jfw: basically the cut(s) you propose would be patches /branches (if several cuts are really worth it) on that genesis, to my mind. | [16:33] |
| jfw: | most Linux distributions (and BSDs too) have taken this dual role of a base system maintained by the distributor, and a sort of glue layer for smoothing over the large differences in third-party software build and installation methods or otherwise adapting it to better fit the goals of the distributor; that is, a ports/portage/package manager of some sort. | [16:36] |
| diana_coman: | whaack: comment in modq | [16:37] |
| jfw: | I do not see the scope of Gales Linux to include "maintenance of all software that someone might wish to install on it", but to indeed include smoothing over installation of such to the extent it's needed. Hence the base/ports distinction. An alternative could be "genesis all that third party stuff and do the porting work there" | [16:39] |
| jfw: | but that to my mind would still be separate trees. If someone needs gcc 6 for the latest c++ standard, I don't see why I must either refuse or impose that whole weight upon all users of the tree. | [16:40] |
| diana_coman: | jfw: if someone wants gcc6 (or whatevers), that someone can branch your OS tree wherever to add the thing; and then they can maintain that branch, what's the problem exactly? | [16:41] |
| jfw: | They then need to backport / regrind any other work done on the main branch | [16:42] |
| diana_coman: | essentially each user maintains their own OS anyway; they can choose to just follow the "branch" of someone (be it yours, it's still a branch) or make their own or whatevers | [16:42] |
| diana_coman: | jfw: yes, they need to do exactly that; so what? | [16:42] |
| diana_coman: | there is a cost to branching, certainly; what's the problem with that again though? | [16:42] |
| jfw: | Does "an OS" mean all software installed on the machine, in your view? | [16:43] |
| jfw: | I don't quite see why that cost is necessary. | [16:44] |
| diana_coman: | tbh I think it's precisely a benefit, not a problem; ie making it clear that bringing in all dead cats one found in the street just because "cute/might meaow better" has a cost + setting that cost precisely on the one bringing them in. | [16:44] |
| diana_coman: | jfw: how do you see it so that it's "not necessary"? | [16:45] |
| diana_coman: | and moreover, what is the exact distinction you see between "trunk" and "branch" to start with? | [16:46] |
| diana_coman: | or whatever, "main branch". | [16:46] |
| jfw: | Not necessary, because I think it's possible to have stable interfaces such that people developing different programs can do so independently. In Gales this interface is filesystem layout + linux syscalls | [16:48] |
| diana_coman: | jfw: do you mean there that people can run code without getting it under V? | [16:49] |
| jfw: | that'd be their choice, nothing in the machine prevents it though. | [16:50] |
| diana_coman: | sure they can, but a. why would you *want* to not get it under V b. why is that your concern to start with ie what people might do on their own machine? | [16:51] |
| diana_coman: | I'm not saying anywhere that you should actively prevent it or anything; people can do whatever they want, stab themselves in the eye as many times as it takes, what. | [16:52] |
| diana_coman: | and sure, maintain stable interfaces in your distro, why not | [16:52] |
| jfw: | a. I don't; b. it's not | [16:53] |
| jfw: | not sure where I said otherwise too | [16:53] |
| diana_coman: | so then I don't get what was the question/trouble | [16:53] |
| jfw: | answering re trunk/branch: it's in the mind of the beholder I suppose, but I'd typically see trunk as the more active or central of a number of branches of interest | [16:55] |
| diana_coman: | jfw: quite in the eye of the beholder and moreover note that it can change + your "more active" evaluation might return something other than someone else's anyway (maybe you don't even consider x,y,z maintainers etc) | [16:56] |
| diana_coman: | possibly the trouble there is that you are mixing maintainers (ie public vpatches for whatever they are using) with private users (whose whatever they are using you can't see); and you seem to prefer to avoid having to interact too much with maintainers because you perceive it as a cost on them, such interaction; but I think the benefits far outweigh the costs (and not only because of "won't add shit to have more to regrind" but ... | [16:58] |
| diana_coman: | ... specifically because it makes *sense* to talk closely to maintainers, what) | [16:58] |
| diana_coman: | I suppose there might be a cost perceived on you too there, ie "now I change this and then ~all maintainers will be mad at me for having to regrind" ? | [17:00] |
| jfw: | either mad, or they simply ignore and the system fragments | [17:00] |
| diana_coman: | jfw: but a. you *talk to them* so that they are aware of how great and needed the change you make is for their branch too, right? so: b. if they ignore it because it's not worth it then...it's not worth it, you know? c. if they ignore it because they are idiots/lazy/not maintaining that branch anymore, then they are not worth the trouble and so what | [17:02] |
| diana_coman: | I don't get that "the system fragments"; it's code and it's there; anyone can take it, change something and it "fragments", no? | [17:03] |
| diana_coman: | but yes, if you don't want the branches to diverge, you run around and keep everyone in the loop (at least everyone you *want* in the loop) | [17:04] |
| diana_coman: | in the process finding both people you want in the loop and otherwise those you don't want in the loop; benefits all around. | [17:04] |
| jfw: | it's a big change in approach to swallow; I'm pondering. | [17:05] |
| diana_coman: | well yes, it is a change, certainly, but uhm, what's the point of recreating open source only with some V inconvenience or what, lol | [17:06] |
| diana_coman: | anyways, no rush, do ponder, do ask & talk, it's all for the best. | [17:06] |
| diana_coman: | jfw: it's I suppose a stark (and apparently unexpected) part of the point of V - *own* the damned thing. | [17:09] |
| diana_coman: | jfw: come to think of it - for as long as there are those stable interfaces, wouldn't it work perfectly fine anyway for maintainers to keep if they so wish the thing as a separate tree and otherwise simply "graft" their genesis on your tree at whatever point? ie the cost of a "regrind" might not even be all that big perhaps? (I'm not fully clear on the details so whether/if/in what case this is possible as such or not) | [17:12] |
| jfw: | So we've got, say, GCC, GNAT, python, sbcl, php, for starters; with a bunch of programs built on each, and users and maintainers with markedly different degrees of commitment to each. In tree structure A, all are included in one very large trunk; nobody's happy with the patch weight from the parts they don't use. In structure B, each language is on its own branch - but this simply doens't work if | [17:13] |
| jfw: | you want to use multiple. So there's structure C where various maintainer branches emerge containing different subsets of the languages, with substantial duplication | [17:13] |
| diana_coman: | jfw: go on. | [17:14] |
| jfw: | that cost does reflect a sorry state of code proliferation, but is the reality for now and quite a bit of foreseeable future | [17:18] |
| jfw: | Could this 'grafting' be seen as ~ pressing one tree in some subdir of another tree? If so, seems to be indeed what I have in mind | [17:19] |
| diana_coman: | jfw: for one thing I think your option C *anyway* happens, it's only less visible atm (~everyone has exactly that on their own computer and moreover, on different computers, no?) | [17:19] |
| diana_coman: | for another thing, you can make a point of a minimal set and if that is indeed so, then naturally the branching will happen *on top* of it but still, I don't see how would it even be possible for it to not happen | [17:20] |
| jfw: | it's indeed the case and less visible, that is, one selects a set of software to include on a given machine, a process that doesn't presently require any regrinding / signing | [17:22] |
| diana_coman: | jfw: admiteddly my concept of grafting is not fully formed but what I had in mind would be along the lines of genesis + whatever number of vpatches on top; as long as those touch only their own stuff, "grafting" it is a matter of going from empty predecessor for genesis to non-empty predecessor; I suppose the manifest file is the one that would force regrind in that it has to propagate though. | [17:26] |
| jfw: | hm, what does an empty predecessor mean? | [17:27] |
| diana_coman: | jfw: genesis is a vpatch on an empty dir, no? | [17:28] |
| jfw: | right | [17:28] |
| jfw: | oh I see | [17:28] |
| diana_coman: | tbh I can even see this done via script, not like a big pain in itself; basically V does not introduce trouble - it only makes it harder to ignore the trouble that there IS in fact, heh; as long as things are kept neat and tidy, there's very little additional cost that is imposed by v itself, come to think of it. | [17:30] |
| jfw: | there is this convention that's developed - though I hadn't been following it - of putting all code in a top-level dir named for the project, with manifest inside that. A graft, then, could mean a patch type that essentially lists (project, branch hash) to combine | [17:30] |
| jfw: | could possibly be done even with existing V - just add a line to each manifest. | [17:33] |
| diana_coman: | well yes, I'm not suggesting to change existing V, no, lolz. | [17:33] |
| diana_coman: | I meant a script to add that line (presumably if you have a huge tree, you might want to) | [17:33] |
| jfw: | I guess I'm catching up slowly then :) | [17:35] |
| diana_coman: | this grafting thing is anyway not fully clear even to me and I'm not even sure it IS a thing anyway; but at any rate, my main point is to make full use of V precisely because it forces things in the clear and that is gold. | [17:37] |
| diana_coman: | (at which point I realise that I ended up the V-champion too, good god). | [17:38] |
| jfw: | I'm trying to figure out what that yggdrasil thing is or what full use of V really means basically. | [17:40] |
| jfw: | since it seems I can't genesis gales without doing so! | [17:41] |
| diana_coman: | jfw: I doubt it's possible to know ALL in advance, because some things will surely become clear only with use; even so far things evolved gradually, e.g. manifest file | [17:41] |
| diana_coman: | jfw: my "full use of V" above means - at all junctures aim to work *with* V rather than avoiding/sidelining it and if that creates some apparent problem/trouble, then discuss and weigh it seriously because chances are that the problem is not with V but with what you are trying to do and "doesn't fit" | [17:43] |
| diana_coman: | or how you are trying to do it | [17:43] |
| diana_coman: | jfw: I suppose the V answerarium might be useful here. | [17:46] |
| jfw: | I'd recently started on that even; will give it another go | [17:48] |
| diana_coman: | jfw: and you know, comment & ask there if anything's not clear, it's the primary source anyway. | [17:49] |
| jfw: | right. | [17:50] |
| diana_coman: | (that being said, the full process outlined there is based on a republic existing.) | [17:51] |
| jfw: | thanks for the feedback diana_coman; I'll bbl. | [18:09] |
| whaack: | diana_coman: I saw your comment on the publication of my logs just now. I provided some context for the logs in a previous article that I linked to in the article that contains the data (albeit perhaps not clearly and prominently enough). I can see that the previous | [19:43] |
| whaack: | article is missing some important information regarding describing the data; I will prioritize adding those. | [19:43] |
| jfw: | Another case I catch myself X11 copy/pasting: typing out full vpatch file names (including .vpatch suffix but not patches/ prefix, thus not tab-completable) for v.pl press | [22:35] |
Comments feed: RSS 2.0