| *** sambishop [~sambishop@95.145.138.222] has quit [Quit: Leaving] | 05:49 | |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has joined #baserock | 07:25 | |
| *** sambishop [~sambishop@82-68-191-81.dsl.posilan.com] has joined #baserock | 07:39 | |
| *** franred [~franred@82-68-191-81.dsl.posilan.com] has joined #baserock | 07:53 | |
| jjardon | persia: then seems I hit a bug because I couldn't build the same system I was building when I have internet connection | 07:54 |
|---|---|---|
| jjardon | Sam suggested that maybe the problem is that in the previous build morph was taken the cache from the server | 07:54 |
| persia | Pulling cache from the server should have updated the local cache. | 08:05 |
| persia | Did you change the version of morph? | 08:05 |
| *** mwilliams_ct [~mikewilli@access.ducie-dc1.codethink.co.uk] has quit [] | 08:24 | |
| *** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:32 | |
| *** ssam2 [~ssam2@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:41 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 08:41 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 245 seconds] | 08:52 | |
| jjardon | ssam2: put "\e[3~": delete-char in /etc/inputrc ;) | 09:18 |
| jjardon | persia: no | 09:19 |
| persia | Odd. I don't understand why you didn't have a good local cache for everything that wasn't changed for your update. | 09:19 |
| ssam2 | jjardon: AWESOME | 09:21 |
| ssam2 | I notice in Fedora I have a bunch of stuff in /etc/inputrc | 09:22 |
| ssam2 | I think we should add that to fhs-dirs in Baserock so all the keys work :) | 09:22 |
| persia | +1 | 09:22 |
| * Kinnison worries that fhs-dirs is somehow becoming base-files | 09:22 | |
| persia | Perhaps it ought be split? | 09:24 |
| persia | Anyway, shouldn't /etc/inputrc be installed by readline? | 09:24 |
| jjardon | persia: I think so but AFAIK its not in the system because is GPLv3 | 09:24 |
| persia | If readline isn't in the system, what is expected to parse /etc/inputrc ? | 09:25 |
| ssam2 | happy to rename fhs-dirs to base-files, or come up with some other place | 09:25 |
| ssam2 | I just want delete to work :) | 09:25 |
| *** ssam2 [~ssam2@82-68-191-81.dsl.posilan.com] has quit ["Leaving"] | 09:25 | |
| *** ssam2 [~ssam2@82-68-191-81.dsl.posilan.com] has joined #baserock | 09:25 | |
| Kinnison | is that the non-chorded ^D ? | 09:25 |
| ssam2 | I don't know | 09:26 |
| persia | ssam2: I'd suggest that /etc/inputrc belongs in whatever chunk contains the library parsing it. | 09:26 |
| ssam2 | the one that says "Delete" on my keyboard | 09:26 |
| persia | Kinnison: No, that's "backward-word" | 09:26 |
| ssam2 | persia: true, and I guess adding 'readline' fixes this because it installs that file | 09:26 |
| ssam2 | but that seems to be impossible to get past the review process | 09:27 |
| persia | Or if you're using something else as a readline library, stick it there. | 09:27 |
| *** ssam2 [~ssam2@82-68-191-81.dsl.posilan.com] has quit [Remote host closed the connection] | 09:41 | |
| *** ssam2 [~ssam2@82-68-191-81.dsl.posilan.com] has joined #baserock | 09:42 | |
| ssam2 | fay: yes, it's the one from last week | 09:42 |
| ssam2 | sorry, I found the magic "exit xchat suddenly" keypress | 09:42 |
| ssam2 | oops, also this is the wrong channel | 09:42 |
| petefoth | ssam2: welcome to my world :) | 09:47 |
| ssam2 | it'd be appreciated if those with personal branches in morph.git and definitions.git that have been merged and/or are no longer deleted could delete them | 10:36 |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 10:37 | |
| persia | Now that richard_maw has demonstrated success with a non-branch based merge process, is there a reason to continue to permit personal branches in those repos? | 10:43 |
| persia | For cases where a branch is really desireable, presumably one could provide a ref to another repo containing personal branches/ | 10:43 |
| persia | (could even be g.b.o/baserock/personal-branches/definitions.git if that is a sensible hosting location for personal branches) | 10:43 |
| petefoth | so long as the proposed new process is adequately documented for new and returning users | 10:43 |
| * Kinnison notes that ssam2 probably meant "Feature branches" not "personal branches" | 10:44 | |
| Kinnison | it's just that for now, we tend to namespace our feature branches under baserock/username/ | 10:44 |
| ssam2 | persia: I've not seen that demo, is it a recent mail to baserock-dev@ ? I'm still catching up | 10:44 |
| ssam2 | Kinnison: yes, I meant the extant branches which can currently be described as either of those things | 10:44 |
| * Kinnison nods | 10:45 | |
| persia | ssam2: I think it was about a week ago or so: sending some stuff that needed git-am to process. | 10:45 |
| Kinnison | ssam2: persia is referring to where richard_maw did some Baserocking outside of his work persona | 10:45 |
| ssam2 | persia: oh, I know what you mean. yes, it's possible to use git-am | 10:45 |
| persia | Kinnison: namespacing makes sense: I'm just wondering if those ought be put in the same repo, rather than a repo with explcit indications that it contains random code by random folk. | 10:46 |
| ssam2 | on gcc 4.8: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2013-March/001777.html | 10:46 |
| Kinnison | persia: For core-developed feature branches I strongly believe they should be in the core repositories | 10:47 |
| persia | I don't believe there to be a workable semantic value for "core" to use in that statement currently. | 10:47 |
| persia | But I probably disagree with you more fundamentally, because I believe that you're envisioning a system where some developers are more equal to others. | 10:48 |
| * Kinnison currently defines it as "entities with personae who have access to keys permitting them to push to those repositories" | 10:48 | |
| persia | And in a peer-reviewed codebase, I think that's something that should be explicitly avoided. | 10:48 |
| Kinnison | I appreciate this is perhaps an "old school" definitions | 10:49 |
| persia | An an example of the sort of odd behaviours this generates: I know of at least two cases where employees (at different firms) were let go because they "failed to gain core" in some project. | 10:49 |
| persia | This is despite them being active in upstream, well respected, and landing all the goals of the companies in question. | 10:50 |
| Kinnison | ssam2: regarding your confusion over why adding the SHA is useful on the tag -- it's because we're using upstream tag names and upstream can (and will, and perhaps more importantly HAVE) move tags. | 10:50 |
| Kinnison | persia: boggle | 10:50 |
| persia | Yes. | 10:50 |
| persia | So I'm actively against any definition of "core" you try to suggest, but I don't believe there is one now, so haven't started that argument :) | 10:50 |
| Kinnison | :-) | 10:51 |
| Kinnison | I see | 10:51 |
| * Kinnison will ponder on that one | 10:51 | |
| radiofree | is there a bugzilla or something for baserock? | 10:52 |
| ssam2 | Kinnison: but the old tag will be in the history of the baserock- tag, so we'll be able to detect if the upstream tag has changed anyway | 10:52 |
| persia | radiofree: No Send mail to the mailing list for now. | 10:52 |
| * paulsherwood mutters GitLab under his breath | 10:53 | |
| persia | ssam2: You've convinced me that adding short-sha provides no benefit. Thank you! I like more readable names. My only remaining worry is whether we can have a convention that lets those developing a definitions set have confidence they can avoid a tag name collision. | 10:54 |
| * paulsherwood wonders what the convincing argument is | 10:55 | |
| persia | That a local tag has the SHA of the upstream tag in it's history, so it's trivially derivable without humans needing to remember arbitrary hex sequences. | 10:56 |
| ssam2 | it has the SHA1 of the commit that the upstream tag pointed to | 10:57 |
| ssam2 | but that should be enough, I think? | 10:58 |
| paulsherwood | ??? | 10:58 |
| persia | Aside from the possibility of collisions, I think so. | 10:58 |
| paulsherwood | what is 'local tag'? | 11:00 |
| persia | A tag a system integrator makes in a shared definitions.git from which they wish to generate reproducible builds. | 11:01 |
| paulsherwood | ok. so two years later, some new integrator (or saboteur) moves the tag, by accident or on purpose... how would we spot that? | 11:04 |
| persia | Ah, so embedding the shortsha in the name of the tag serves to confirm the tag has not moved? | 11:05 |
| paulsherwood | yes. i thought i'd said that, twice :) | 11:06 |
| persia | Somehow I forgot today, and was swayed. Thank you for reminding me. | 11:06 |
| * persia is no longer convinced we can do without the shortsha | 11:06 | |
| * paulsherwood cheers :) | 11:06 | |
| paulsherwood | now for ssam2 :) | 11:06 |
| ssam2 | can't gitano rules prevent people from moving the tag? | 11:07 |
| persia | 1) We can't guarantee everyone stores their definitions.git in gitano, and 2) wouldn't that block moving tags for other purposes for other repos? | 11:08 |
| paulsherwood | possibly if we are mandating gitano. but what's the real overhead for doing it as i suggest? belt-and-braces just seems better to me | 11:08 |
| ssam2 | Including sha name in tag is more robust, I agree | 11:09 |
| ssam2 | I think we could mandate Gitano for people who want protection against the fairly rare case of an integrator forcepushing a tag, if we wanted | 11:10 |
| ssam2 | I can't get my head around the exact overhead of your solution, I think actually trying it is probably the only way to know | 11:10 |
| ssam2 | I have the impression I'd have to type hex strings a lot, but maybe I'm wrong | 11:10 |
| paulsherwood | can i count that as a +1? | 11:11 |
| ssam2 | a +1 to try it out, certainly :) | 11:11 |
| * paulsherwood uses cut and paste a lot | 11:11 | |
| paulsherwood | we could have morph do the tagging, trivially... | 11:11 |
| ssam2 | that would help a lot | 11:12 |
| persia | `morph commit`? | 11:12 |
| persia | We're still not protected against tag deletion, but we aren't protected against branch deletion now, so this isn't a regression. | 11:14 |
| paulsherwood | persia: i think this is more like 'morph publish' | 11:17 |
| persia | I like that, not least because by using "publish", we avoid semantic confusion. | 11:19 |
| paulsherwood | yes, i'm thinking we should actively avoid clashing with git commands, but that's a bigger discussion | 11:20 |
| persia | Interesting, the idea being that git+morph fit together well, but never use the same verb? | 11:22 |
| * persia especially likes that this means doing away with all the morph verbs that don't seem to make sense | 11:23 | |
| paulsherwood | yes, possibly. but it needs more thought. and at least one of our customers has already flagged that he'd prefer to see only morph commands, no git commands in the workflow | 11:23 |
| persia | That's just a framing issue. | 11:24 |
| paulsherwood | but arguably that may be as a result of the current commands/naming | 11:24 |
| paulsherwood | yes | 11:24 |
| paulsherwood | while we're on, i'd like to eradicate 'morphology' from the project vernacular | 11:25 |
| persia | What do you suggest as an alternative? | 11:26 |
| paulsherwood | definition | 11:26 |
| ssam2 | I think it'd be possible to more-or-less transparently wrap Git, by having Morph act as a 'filter' around Git commands, passing through any arguments it doesn't recognise to the underlying Git commands. I don't have time to think about this now, but I think it's a possible approach to investigate when we do look at solving this | 11:26 |
| persia | ssam2: Why would one do that? Wouldn't it be easier to just implement new verbs with git-foo? | 11:27 |
| persia | (e.g. git-build, git-deploy, etc.) | 11:27 |
| ssam2 | persia: we need to override some, e.g. 'git push' so that it handles 'git-fat' transparently | 11:27 |
| persia | I'm not advocating this, but it seems less fraught with danger than wrapping git | 11:27 |
| persia | I still don't think it should do that :) | 11:27 |
| straycat_ | radiofree, biff | 11:30 |
| radiofree | straycat_: hi | 11:46 |
| radiofree | i linked to your branch, you only need the one commit now (for the filename stuff) | 11:46 |
| radiofree | that gets past .morph.morph | 11:46 |
| radiofree | however i still can't build because of that "Failed to compute build graph: Problem with serialise-artifact" after that | 11:47 |
| straycat_ | Right, that'll be my general lack of sleep kicking in | 11:51 |
| rjek | This morning I got up thinking I could sleep for another month or so. | 11:52 |
| straycat_ | Either you're trying to build some definitions that aren't on your trove or some other recent change has also broken serialise-artifact. | 11:53 |
| radiofree | hmm | 11:54 |
| radiofree | oooh i see | 11:54 |
| radiofree | my definitions branch isn't pushed anyway, does that cause problems? | 11:54 |
| straycat_ | Shouldn't, since build branches are pushed, I mean that your definitions have a ref that's not on your trove. | 11:56 |
| radiofree | hmm i wouldn't have thought that's the case, i'll double check though | 11:57 |
| radiofree | ah well actually i built all of this stuff on my development machine using the same trove, so i guess it is all there? | 11:57 |
| persia | Do you have any unpushed commits in your defintions? That would create a SHA not on the trove. | 11:57 |
| Kinnison | ssam2: So your suggestion is that the baserock/$UPSTREAMTAG is now no longer just a ref anchor for the same object as $UPSTREAMTAG but instead is somewhere we merge to? | 11:58 |
| * persia doesn't like this interpretation | 11:58 | |
| radiofree | persia: no | 11:58 |
| radiofree | i used morph branch if that makes any difference | 11:59 |
| persia | It shouldn't. | 11:59 |
| ssam2 | Kinnison: my suggestion is we don't have -2361436 on the end of the tag name, no other changes. Maybe I'm missing something | 11:59 |
| straycat_ | When you used morph branch, was your trove-host and trove-id set to the same trove that the distbuild network is using? | 11:59 |
| radiofree | straycat_: yep | 12:00 |
| Kinnison | ssam2: The intention was that baserock/$UPSTREAMTAG was simply a way to anchor the tagged objects in a namespace upstream can't mess with | 12:01 |
| ssam2 | that makes sense | 12:01 |
| ssam2 | and if upstream change their tag, ours won't change, so we'll notice that they changed it | 12:01 |
| straycat_ | radiofree, Hrm, then I don't know. :/ | 12:01 |
| Kinnison | ssam2: if you omit the -SHA bit then if upstream move what $UPSTREAMTAG points out, baserock/$UPSTREAMTAG will have to either migrate (losing history) or merge (potentially confusing) | 12:01 |
| ssam2 | why can't it just stay the same? | 12:02 |
| persia | That's the "merge" case, which is confusing | 12:02 |
| ssam2 | no it isn't | 12:02 |
| ssam2 | it's the "continue to use the old tag" case | 12:02 |
| radiofree | straycat_: i just did a morph checkout of the definitions branch i want to use, save trove etc as the distbuild network | 12:02 |
| Kinnison | ssam2: I'd be confused | 12:02 |
| radiofree | still the same problem | 12:02 |
| Kinnison | ssam2: because I'd expect baserock/$UPSTREAMTAG to == $UPSTREAMTAG | 12:03 |
| ssam2 | the average baserock user will be confused about the existence of the tags regardless of the policy, until they learn the policy | 12:03 |
| persia | ssam2: Sorry: terminology: I interpreted Kinnison's "merge" as having a single repo containing both the moved upstream tag and the unmoved baserock tag, rather than having anything to do with `git merge`. | 12:03 |
| ssam2 | the fact that you decided on one policy and would be confused if we chose a different one is neither here nor there | 12:04 |
| ssam2 | i'm happy with either solution, btw, we don't need a long debate | 12:04 |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Quit: ZNC - http://znc.in] | 13:09 | |
| *** pedroalvarez [~quassel@ec2-54-191-112-126.us-west-2.compute.amazonaws.com] has quit [No Ping reply in 180 seconds.] | 13:14 | |
| *** pedroalvarez [~quassel@ec2-54-191-112-126.us-west-2.compute.amazonaws.com] has joined #baserock | 13:15 | |
| Mode #baserock +cnt by kornbluth.freenode.net | 13:15 | |
| *** ssam2 [~ssam2@82-68-191-81.dsl.posilan.com] has joined #baserock | 13:15 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 13:34 | |
| jjardon | yay! Thanks ssam2 (and other reviewers) for the GTK3 merge! :) | 13:34 |
| persia | Is there a gtk3 test system defined somewhere? | 13:35 |
| jjardon | But I have a concern, I do not thing the stratum model is workin (at least for me). For example: to build a new GNOME component I need a new fuse or systemd, things that are in foundation, so I have to rebuild _a lot_ of stuff. The same happen with GLib, that its in foundation as well | 13:36 |
| jjardon | persia: no, but Im using that stratum in a gnome system Im working on | 13:36 |
| persia | Cool. If you can share, I'd like to give it a try when it works. | 13:37 |
| jjardon | spoiler: gtk3-demo runs here ;) | 13:37 |
| jjardon | I can create a super basic X system (or even wayland) so you can take a look | 13:38 |
| persia | No rush. I won't have time to play with it that soon anyway: lots of upcoming travel. | 13:38 |
| persia | On strata: I think that it's a good concept, but perhaps the current strata haven't had the benefit of enough different types of systems? | 13:39 |
| *** tiagogomes [~tiagogome@185.25.241.217] has joined #baserock | 13:39 | |
| persia | I like the idea of several associated bits of software being managed together and built together, because dealing with interdependency maps for some things is incredibly painful (e.g. KDE). | 13:40 |
| jjardon | yeah, or maybe we should think how to divide the strata in different ways | 13:40 |
| liw-orc | I seem to have forgotten to update the ref for morph when I merged a patch from richard_maw to morph -- any objections to me updating that ref? | 13:40 |
| persia | I'm not sure we can decde that a priori, but rather only by the process of adding more chunks, and seeing what logical strata develop from the associated interdependencies. | 13:40 |
| persia | liw-orc: which ref? | 13:40 |
| liw-orc | the ref in tools.morph | 13:41 |
| persia | Yes. To what value to do you wish to update it? 9a9445c47f25d919483a6e798e789dbf32e9310f ? | 13:41 |
| liw-orc | to head of master in morph.git, so yes | 13:41 |
| persia | Do you think it makes sense to update the morph ref in cross-bootstrap.morph at the same time? | 13:42 |
| Kinnison | please | 13:42 |
| liw-orc | sure | 13:43 |
| persia | +1 from me if both are updated, or if there's a really good reason not to update the cross-bootstrap morph (but in that case I'd like a ML post for documentation). | 13:43 |
| * liw-orc updates | 13:44 | |
| jjardon | persia: the problem is that for example I need a new GLib (quite common thing) but I should not not need to rebuild X at all for that | 13:45 |
| persia | That makes sense. For that matter, some folk will want X and not GLib. | 13:46 |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Quit: ZNC - http://znc.in] | 13:46 | |
| persia | My thought is that it is probably reasonable to split/reorganise strata when the current structure is difficult, and point out how it is difficult for each difficulty in the patch series on the mailing list. | 13:47 |
| persia | Sometimes a little excess inconvenience will be worth the conceptual simplicity, but I suspect we'll want lots more strata then we have today. | 13:48 |
| * persia suspects that users would find it convenient to be able to just write system definitions, without needing to fuss much about strata definitions except in special cases | 13:48 | |
| persia | Thinking about this a bit more, I wonder if our ccache configuration is usefully capturing everything: if it works properly, rebuilding extra chunks in a stratum should be really fast. | 13:51 |
| liw-orc | assuming they're using C or another language ccache supports, and that there is no other parts of the build that take a lot time in the build | 13:51 |
| liw-orc | for a lot small things, most of the overhead is in the configure phase | 13:51 |
| persia | Ah, so while ccache helps, extra rebuilds are still painful enough to try to avoid. | 13:52 |
| jjardon | another though is: why we should rebuild everything? If I update systemd to a new version of a stable branch everything should still working fine without a rebuild | 13:53 |
| persia | Depends on build system interdependencies as well as runtime interdependencies. | 13:55 |
| persia | Some software might enable different features with a different version of systemd, so the rebuild creates a different object. | 13:56 |
| jjardon | I cant image a different way if we want to have an image ready as soon as possible after a commit is done (ie less than 5 minutes) | 13:56 |
| persia | Key is wanting a trusted image. There's lots of solutions that can produce working images in minutes from commit. | 13:56 |
| jjardon | persia: is a stable branch, no new features, only bugfixes | 13:57 |
| persia | There's very few solutions that can assure that one can reproduce that image at all (let alone with the level of warrant in baserock) | 13:57 |
| persia | I believe that sometimes folk make mistakes and sometimes there are regressions. Were that never true, I'd agree. | 13:57 |
| jjardon | ok, but then you have to renounce to CD | 13:58 |
| persia | Why? | 13:59 |
| jjardon | if you cant build a final product in a moderate amount of time for every change you make | 13:59 |
| persia | I think we can. I think strata need some reorganisation. I don't think we want one-stratum-per-chunk. | 14:00 |
| persia | And I'm willing to trade *some* speed for assurance: there's a huge gap between "as soon as possible" and "not in a moderate amount of time". | 14:00 |
| jjardon | ok, what amount of time you think? Im talking here to have feedback about a change in less than 5 min | 14:01 |
| persia | For me, it's hardware dependent. | 14:02 |
| persia | And I don't believe Baserock should have specific hardware expectations. | 14:02 |
| persia | In the event that you have lots of fast hardware with unthrottled IO, I suspect it takes less than 5 minutes for nearly any operation. | 14:03 |
| jjardon | Do not think is hardware dependent. I think its a problem of not building things are not needed to build | 14:03 |
| persia | On a Tegra 2 laptop with no distbuild, I expect it takes more than 5 minutes even trying "as soon as possible". | 14:03 |
| jjardon | also, not everyone has very powerful hardware, I talking about my laptop or a normal desktop | 14:04 |
| jjardon | persia: and its not only compiling, its creating the images and test them | 14:05 |
| jjardon | every commit should output a final product, thats how I understand CD | 14:05 |
| persia | Yes. So the Tegra 2 laptops did all their IO over USB2. This is part of why I picked this as an example. | 14:05 |
| *** radiofree [quassel@unaffiliated/radiofree] has joined #baserock | 14:05 | |
| persia | A CD process needs to have infrastructure driving the CD, and the hardware selected to do this needs to be fast enough to keep up with the commit stream. | 14:06 |
| persia | I don't think the actual time matters that much, as long as every commit results in product. | 14:06 |
| *** radiofree [quassel@unaffiliated/radiofree] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.] | 14:08 | |
| *** radiofree [quassel@unaffiliated/radiofree] has joined #baserock | 14:09 | |
| *** radiofree [quassel@unaffiliated/radiofree] has quit [Client Quit] | 14:10 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 14:13 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Remote host closed the connection] | 14:25 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 14:25 | |
| jjardon | persia: ok, so tell me how can I work in a system where I track master of several components and every time I build, everything gets rebuilded because little changes in one of the modules | 14:33 |
| persia | Split the stata differerntly. Make sure you have harware reources to mee your time goals. Maybe do some proviling to determine optimisation cndidates. | 14:37 |
| * ssam2 wonders about how much persia's proposed design costs in terms of electricty bills | 14:45 | |
| ssam2 | *electricity | 14:45 |
| jjardon | persia: if the solution is to split the strata differently, whats the point to have strata in the first term? Mmm maybe make sense to have a strata per chunk in low level component and bigger strata when you go up in the stack | 14:57 |
| jjardon | Maybe foundation should be splitted completely: xorg should not depend on glib or fuse, but only in the components it needs. I think that would speed up things quite a lot | 15:00 |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has quit [Remote host closed the connection] | 15:05 | |
| radiofree | yes it is a bit maddening at the moment | 15:10 |
| * jjardon search google for maddening | 15:11 | |
| paulsherwood | jjardon: not sure if we discussed this before, but if you are finding that you need to keep building foo and bar chunks, and they are triggering lots of rebuilds, you could consider having new versions foo-new and bar-new, in a new top-level stratum - do your work on them, then replace the originals when done? | 15:33 |
| paulsherwood | (me has done this, and it works for some use-cases at least) | 15:33 |
| jjardon | paulsherwood: yeah, but id like a more general solution | 15:34 |
| jjardon | Also is not the same: if im working in gtk i do not want to rebuild wayland and xorg every time a commit in glib is done | 15:35 |
| paulsherwood | can't have glib-new over the top, and make your gtk point to that? | 15:36 |
| paulsherwood | i agree a general solution is required | 15:36 |
| jjardon | That was an example, what if instead glib only they are several modules? | 15:40 |
| paulsherwood | make them all -new? | 15:40 |
| jjardon | I will take a look and see if foundation can be splitted in a way it saves as much as possible rebuilds | 15:41 |
| jjardon | paulsherwood: that its a lot of work that will not benefit other people | 15:41 |
| jjardon | Or maybe we are envision baserock differently? I see it as a tool where i can work with moving parts, so its easy to keep up to date, not where everything is static | 15:43 |
| *** tiagogomes [~tiagogome@185.25.241.217] has quit [Ping timeout: 240 seconds] | 15:50 | |
| paulsherwood | jjardon: that's the idea, yes. i think in some respects we achieve that well already, but there's still lots to do | 16:20 |
| * ssam2 longs for a 'morph what-changed-such-that-you-think-you-need-to-rebuild-everything-above-eglibc' command | 16:36 | |
| ssam2 | I guess once again, CD will mitigate this issue | 16:37 |
| *** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving] | 16:41 | |
| petefoth | ssam2: another requirement for which CI will be the silver bullet - hurrah! | 16:45 |
| jjardon | petefoth: does not CD include CI ? | 17:07 |
| *** ssam2 [~ssam2@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving] | 17:18 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 17:18 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has quit [Quit: Leaving] | 18:08 | |
| *** sambishop [~sambishop@82-68-191-81.dsl.posilan.com] has quit [Ping timeout: 255 seconds] | 19:10 | |
| persia | jjardon: CD does not require CI, but it's best practice. Consider a git repo with a post-commit deploy hook: this is simplistic CD, but means that the broken versions also get deployed. | 23:56 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!