| *** locallycompact has quit IRC | 00:50 | |
| *** tiagogomes_ has joined #baserock | 08:53 | |
| *** ctbruce has joined #baserock | 08:53 | |
| *** rdale has joined #baserock | 08:56 | |
| *** bashrc_ has joined #baserock | 09:09 | |
| *** franred has joined #baserock | 09:46 | |
| *** gtristan has joined #baserock | 09:51 | |
| *** jmacs has quit IRC | 09:57 | |
| *** jmacs has joined #baserock | 09:58 | |
| tiagogomes_ | perryl, do you have a trove to test https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/trove-setup+branch:master+topic:lauren/git-web-filter | 10:04 |
|---|---|---|
| perryl | tiagogomes_: i've got a personal trove set up but nothing public currently | 10:05 |
| *** straycat is now known as VLetrmx | 10:08 | |
| *** ssam2 has joined #baserock | 10:11 | |
| *** ChanServ sets mode: +v ssam2 | 10:11 | |
| *** edcragg has joined #baserock | 10:17 | |
| *** jonathanmaw has joined #baserock | 10:18 | |
| rdale | i'm following the 'quick start' instructions on the baserock wiki to set up a baserock-current-build-system-x86_64 image. when i get to the step where i checkout branch baserock-15.34 of defintions and try to build it i get 'ERROR: Definitions format version 5 is not supported | 10:32 |
| rdale | '. If i run 'morph --version' i get: fad8048de66fe6aeaa0478864914bb773f51ed3e. I assume that morph is either too old, or too new to build the definitions - anyone know how i fix this? | 10:32 |
| ssam2 | ah, 15.34 is not the latest release | 10:34 |
| ssam2 | 15.47 is the latest release | 10:34 |
| rdale | ah, ok i'll try that | 10:34 |
| ssam2 | wiki must be out of date | 10:34 |
| *** toscalix has joined #baserock | 10:35 | |
| VLetrmx | ssam2, the backend gerrit uses is on a separate box (Which is a separate system that provides mariadb) ? | 10:35 |
| ssam2 | yes, we have a separate system providing a MariaDB database | 10:36 |
| VLetrmx | okay | 10:36 |
| ssam2 | which is also used by Storyboard and the OpenID provider | 10:36 |
| richard_maw | hi VLetrmx, I didn't recognise you in your new nick, looks swish | 10:37 |
| VLetrmx | lol | 10:37 |
| VLetrmx | rdale, should be fixed now | 10:40 |
| rdale | ah ok, thanks - i was about to try and fix the wiki myself | 10:40 |
| tiagogomes_ | shouldn't an entry for the last release of Baserock be added to http://wiki.baserock.org/guides/long-term-baserock-reproducibility/ | 10:46 |
| pedroalvarez | tiagogomes_: hm.. not sure, that was an investigation to see if we could rebuild all the releases we have done | 10:50 |
| *** locallycompact has joined #baserock | 10:51 | |
| VLetrmx | given we're about to remove branch-from-image and that the page reports that it's broken in the last 3 releases, the page seems a bit obsolete | 10:52 |
| tiagogomes_ | yeah, I asking because of the branch-from-image command | 10:53 |
| *** toscalix has quit IRC | 10:55 | |
| VLetrmx | ssam2, okay i'm guessing this uses fedora because we don't have mariadb in baserock? | 10:57 |
| pedroalvarez | VLetrmx: yes | 10:58 |
| tiagogomes_ | docs are boring | 11:10 |
| VLetrmx | i'm slightly confused, our README says storyboard only supports mariadb, storyboard's docs say it only supports mysql, clearly you have an instance running it with mariadb, so is http://docs.openstack.org/infra/storyboard/install/manual.html wrong? | 11:10 |
| pedroalvarez | no, our instance is broken | 11:10 |
| pedroalvarez | some features present in mysql 5.6 are not present in mariadb yet | 11:11 |
| tiagogomes_ | would anyone mind if I removed this page ? | 11:11 |
| tiagogomes_ | mm, something is missing, http://wiki.baserock.org/brdevel_script/ | 11:11 |
| VLetrmx | okay, so if our only reason for using fedora is that we didn't have time to package mariadb for baserock, we could switch the infradb over to baserock running mysql? | 11:11 |
| pedroalvarez | that would solve my problem with deploying storyboard | 11:12 |
| SotK | pedroalvarez: what version of mariadb are we using? | 11:14 |
| VLetrmx | tiagogomes_, i don't mind if that's removed, it won't work soon anyway | 11:14 |
| ssam2 | it's also a lot simpler to keep Fedora machines up to date, currently | 11:16 |
| ssam2 | 'ssh, dnf update' vs. 'ssh to remote devel machine, update morph, update definitions, morph build, morph upgrade' | 11:17 |
| ssam2 | i've no objection if someone fancies switching more infrastructure systems to Baserock, but i don't have any plans to do it | 11:17 |
| *** tiagogomes_ has quit IRC | 11:18 | |
| *** tiagogomes has joined #baserock | 11:18 | |
| SotK | pedroalvarez: also, what feature does storyboard need that isn't there? | 11:20 |
| pedroalvarez | SotK: it needs fulltext indexes | 11:28 |
| pedroalvarez | I'll check now the version of mariadb | 11:28 |
| SotK | hmm, I thought they were supported in new-ish versions of mariadb? | 11:29 |
| pedroalvarez | I think I managed to get it working once, but then tried to upgrade our database to that version (with a snapshot of it, not production one) and failed | 11:31 |
| pedroalvarez | I now just want to stop thinking about possible workarounds, and just put mysql in the storyboard instance | 11:32 |
| VLetrmx | thinking about this, i think that storyboard is broken for relying on mysql, i don't think fixing this is relevant enough for what i'm trying to do, though i do think it might be worth packaging mariadb in baserock | 11:33 |
| VLetrmx | i can probably just the existing fedora image for my purposes | 11:33 |
| SotK | pedroalvarez: sounds like you hit a place where the migrations expect mysql... there are a few places it does that which I noticed when trying to use postgresql with storyboard one time | 11:35 |
| pedroalvarez | SotK: yes, in the migration 022 and migration 042 :) and IIRC new versions of mariadb was reporting also 5.5 as version number on those migrations.. | 11:58 |
| pedroalvarez | anyway, no more databases conversations, I just hate them all now | 11:58 |
| pedroalvarez | put the data in git! | 11:59 |
| persia | In progress for gerrit, but I don't know that anyone has come up with a good way to store Storyboard info in git. | 12:13 |
| ssam2 | https://github.com/CodethinkLabs/python-consonant | 12:16 |
| ssam2 | but that is abandoned for a while | 12:16 |
| *** Lachlan1975 has joined #baserock | 12:24 | |
| SotK | heh, ssam2 beat me to linking consonant | 12:27 |
| *** paulwaters_ has joined #baserock | 12:30 | |
| persia | Reading the consonant spec, it might do the job, but the lack of sqlalchemy support means the entire data interaction layer would need to be redesigned substantially. | 12:39 |
| *** petefotheringham has left #baserock | 12:55 | |
| *** locallycompact has quit IRC | 13:03 | |
| *** locallycompact has joined #baserock | 13:04 | |
| *** tiagogomes has quit IRC | 13:04 | |
| *** jonathanmaw has quit IRC | 13:04 | |
| *** bashrc_ has quit IRC | 13:04 | |
| *** tiagogomes has joined #baserock | 13:04 | |
| *** bashrc_ has joined #baserock | 13:05 | |
| *** jonathanmaw has joined #baserock | 13:06 | |
| *** rdale has quit IRC | 13:19 | |
| *** petefotheringham has joined #baserock | 13:21 | |
| *** rdale has joined #baserock | 13:22 | |
| *** petefotheringham has quit IRC | 13:27 | |
| *** ppeetteerr has joined #baserock | 13:37 | |
| *** ppeetteerr has quit IRC | 14:00 | |
| gtristan | oh, btw the latest gnome patches are up ! | 15:20 |
| gtristan | https://gerrit.baserock.org/#/c/1502/, https://gerrit.baserock.org/#/c/1503/, https://gerrit.baserock.org/#/c/1504/... followed by https://gerrit.baserock.org/#/q/topic:fix-initial-setup-keyring | 15:21 |
| pedroalvarez | hm.. I spotted that some 'unpetrify-ref's don't exist.. | 15:31 |
| pedroalvarez | but also agree that "we are not using them" | 15:32 |
| tiagogomes | it is a documentation field | 15:32 |
| pedroalvarez | and actually having that info would be more informative than "master" | 15:32 |
| tiagogomes | it probably should be renamed to something else | 15:32 |
| pedroalvarez | context: https://gerrit.baserock.org/#/c/1505/1/strata/gnome.morph | 15:32 |
| ssam2 | i think we need a 'tracking-ref' field, for keeping track of the actual branch we care about | 15:41 |
| ssam2 | and we need to sort out a way to use tag names instead of SHA1s in the 'ref' field | 15:41 |
| richard_maw | ssam2: tags don't always resolve to the same sha1, so if you use a tag name instead of the sha1 you can't reproduce that definition in future | 15:43 |
| ssam2 | yes, this has been discussed at length on the mailing list | 15:43 |
| * gtristan has been thinking about that too, and mentioned something like that in his CI related email | 15:43 | |
| richard_maw | many times, haven't we jjardon? | 15:43 |
| gtristan | for CI, or anything which wants to automatically pull a new version, we need some declarative way to specify where we get a new version from | 15:44 |
| richard_maw | yep, for firehose this was defined in a separate config file | 15:44 |
| persia | In my head, definitions always tracks some specific commit. | 15:46 |
| persia | And CI of systems is done by submitting new definitions candidates. | 15:47 |
| gtristan | Agree that the SHA1 is ultimately the most reliable, on the other hand one could always be more lax, and if a tag-or-branch were specified, the ref could be derived from it - a snapshot of all the relevant SHA1s could always be generated at any given time | 15:47 |
| persia | The new definitions candidates should be constructed using some automated integration tool, which cares about branch names, or tags, or some other indicator. | 15:47 |
| persia | gtristan: We used to have that functionality, with "petrify" and "unpetrify": in practice, this generally meant that anything unpetrified failed to build. | 15:48 |
| persia | The lesson was that we only want to advance a small subset of things in concert. | 15:48 |
| persia | (or many parallel subsets, with integration) | 15:48 |
| gtristan | certainly agree | 15:48 |
| gtristan | any CI would want to select which chunks/strata should be updated in concert | 15:48 |
| persia | Right, so that it would be wrong for *definitions* to impose the set of branches of concern. That config belongs in the automated integrator that feeds the CI. | 15:50 |
| gtristan | perhaps allowing missing refs is not great, but I do think that specifying the active branch in the chunk morph itself would be the right place, even if ignored during a regular build | 15:51 |
| persia | The problem is that it only has meaning in a small subset of cases. | 15:51 |
| gtristan | I just think that it would be difficult to maintain a set of configs in parallel | 15:51 |
| persia | Most users (whether human or automation) need to have separate config to decide whether to care about it. | 15:51 |
| persia | And since that config is there anyway, why duplicate it? | 15:51 |
| gtristan | On the other hand most refs exist on some active branch, having the branch encoded in the chunk allows a CI to build/test/propose a new ref from the same branch | 15:53 |
| gtristan | probably a human prefers first to decide on which stable branch they build, and have the actual ref derived, well... probably | 15:54 |
| ssam2 | persia: definitions doesn't need to "impose" branches of concern. It can usefully *suggest* them | 15:54 |
| ssam2 | any sensible CI system would allow overriding them, but if the definitions suggested the branch to follow (which I think in 99% of cases would be correct) then CI users wouldn't need an enourmous separate config file just to achieve anything | 15:55 |
| persia | ssam2: My contention is with your use of the word "usefully": to me the suggestions are going to be superfluous or wrong for most users. | 15:55 |
| ssam2 | really? in 99% of cases it will be 'master' | 15:55 |
| ssam2 | most projects don't even have any other branches | 15:56 |
| ssam2 | in the context of the current definitions | 15:56 |
| persia | Those are the boring cases, and for them the suggestion has little value. | 15:56 |
| persia | It is the *rest* of the cases that are interesting. | 15:56 |
| gtristan | and I think 99% of cases will be stable-of-release-Major.Minor | 15:56 |
| gtristan | while only the real risk takers will want master ;-) | 15:56 |
| persia | Where non-master is selected, the user (whether human or not) needs to determine whether they want master, or some non-master, or which. | 15:56 |
| ssam2 | true, stable branches rather than master | 15:57 |
| persia | This decision is, to my mind, unlikely to be influenced by the content of definitions, and more likely to be influenced by that users' goals. | 15:57 |
| ssam2 | I still think that info would be useful in the definitions. People make use of the current 'unpetrify-ref' field, that's why it's still there | 15:57 |
| persia | People annotate it when they make changes. | 15:57 |
| persia | Do people consume it to make decisions? | 15:57 |
| ssam2 | i do | 15:57 |
| ssam2 | to know which branch to update from | 15:58 |
| gtristan | My thoughts on this is from the point of view of a consumer; I want to build a safe and reliable system, and I want to pull latest-stable of the packages I want to include in my system | 15:58 |
| gtristan | and I would like to automate some of that via some CI | 15:58 |
| gtristan | at the end of the day, I will enjoy the safe and reproducible builds which the SHA1s provide | 15:58 |
| * franred too thinks that unpetrify-ref is nice to have to know where to look for the sha1 | 15:58 | |
| persia | gtristan: CI is entirely orthogonal to this. | 15:58 |
| franred | s/too// | 15:58 |
| gtristan | persia, well, perhaps it is, let's rephrase that: I want to build and test latest stable upstreams with all security bugfixes and important recent crasher fixes | 15:59 |
| * persia uses tig to find sha1s: `tig --all`, '/', ${SHA1} | 15:59 | |
| gtristan | whether the testing is automated or not, is probably orthogonal | 15:59 |
| persia | gtristan: Yes, but my assertion is that *you* want to do that, and that this may not be the same as what other users want. | 16:00 |
| gtristan | but what interests me as a systems builder/maintainer, is to be able to migrate to a latest-stable automatically | 16:00 |
| persia | Many users will want to pull from their local forks of things, rather than upstream stables. | 16:00 |
| persia | Some users will want to pull from upstream master, as part of validation of the master. | 16:00 |
| gtristan | persia, I think its very far fetched to think that most users fork "most" of the packages which go into a system | 16:00 |
| persia | Some users will want to pull from pre-merge candidates to see how a code change would integrate with a system | 16:00 |
| persia | etc. | 16:00 |
| persia | gtristan: I can only speak from my experience of embedded systems. Yours may differ. | 16:01 |
| gtristan | most anyone building any embedded product may have a fork of one or two repos | 16:01 |
| gtristan | but all of them ? | 16:01 |
| gtristan | doubtful | 16:01 |
| franred | persia, imagine you need to do that for ~400 chucks... Also, I though we were pushing to make definitions more explicit | 16:01 |
| persia | Most of the ones I've encountered start with vendor forks including a selection of changes all over the place. | 16:01 |
| gtristan | my experience is that I encounter enormous stop energy when desiring to update *anything* in the platform, honestly | 16:02 |
| persia | franred: Have you ever done that for 400 chunks? Do you imagine doing that with or without the field? | 16:02 |
| persia | franred: If I needed to process that many chunks, I'd use a script, which would show branches that have SHA1 as ancestor for each of the chunks. | 16:02 |
| gtristan | that is a problem, pulling a security bugfix from a stable upstream may mean that the QA team is set back one month, and all of their testing is invalidated by one bugfix | 16:02 |
| persia | Yes. I share that experience. | 16:03 |
| franred | persia, I have to update openstack... yes, it was nice to read in definitions where the sha1 came from. So you know if it is a custom or a general branch | 16:03 |
| gtristan | that is of course, insane, but from some paranoid viewpoints, valid as well :-/ | 16:03 |
| persia | I don't think fixing that problem has anything to do with a notation field in defintions about the branch name assigned to a SHA1 at the time the last person touched it, if they remembered to update the ref. | 16:03 |
| persia | franred: How do you mean "custom" vs, "general"? | 16:04 |
| franred | persia, custom: branches which are only in gbo, general: branches which we lorried | 16:05 |
| persia | If any of the former lasted any time, it indicates a failure to engage with upstream. | 16:05 |
| persia | Anyway, I've complained about this enough for today. My complaints aren't any different than they have been since I first sent email ridiculing this field. I'll stop now. | 16:06 |
| pedroalvarez | ok, there might be different opinions from: (a) baserock users (b) baserock developers (c) people just following the project | 16:06 |
| gtristan | I think that if we are going to be a venue for hosting stable reference builds, we need to have branch tracking in mind | 16:07 |
| persia | gtristan: I agree, but I think that belongs in the configuration of the tool that submits candidate patches to definitions, rather than definitions. | 16:09 |
| gtristan | perhaps, but I wonder how it would be to work with that | 16:09 |
| gtristan | persia, what workflow do you envision, personally I see the entire definitions repository branched for a collective stable branch, and each chunk declaring which branch they track | 16:10 |
| gtristan | I think that's rather logical and easy to understand | 16:10 |
| persia | I think the definitions repository should be branched for a stable model, if one wants that. | 16:11 |
| persia | But I think that any policy for branch tracking belongs in the automation that submits candidate changes to those definitions, rarther than in the definitions. | 16:11 |
| gtristan | So baserock-1.0 is released and a baserock-1.0 branch is created, with a BASEROCK_1_0_0 release tag | 16:12 |
| persia | Because the value for stable differs from the value for non-stable in ways that mean one cannot simply branch and label definitions, but needs to re-annotate all the notes. | 16:12 |
| gtristan | how do we move to BASEROCK_1_0_1 ? | 16:12 |
| ssam2 | let's bear in mind that we've succeeded in creating the definitions format, but have failed 3 times now to create said CI tooling | 16:12 |
| persia | Since I'm opposed to even the rudimentary baserock releases done now, as I think them counterproductive, I have trouble answering that without conflating it with other issues. | 16:12 |
| * gtristan is digesting this... | 16:12 | |
| ssam2 | let's add the field to the definitions format for now, and if $amazing CI tool eventually exists and obsoletes it, we can remove it again | 16:13 |
| persia | ssam2: The field is already there. It's just a matter of not removing it. | 16:13 |
| persia | The reason I raised complaint again is that I don't want someone trying to use it for CI, as I think that is another recipe for failure. | 16:14 |
| pedroalvarez | so going back to the problem, what do we do :) | 16:19 |
| persia | Which problem? | 16:19 |
| pedroalvarez | baserock | 16:19 |
| persia | That some chunks don't have unpetrify refs? | 16:19 |
| gtristan | some people have nothing to do around here huh... | 16:20 |
| gtristan | ;-) | 16:20 |
| pedroalvarez | https://gerrit.baserock.org/#/c/1505/1/strata/gnome.morph | 16:20 |
| *** ctbruce has quit IRC | 16:20 | |
| gtristan | sigh... | 16:20 |
| gtristan | pedroalvarez, my benevolent dictator, want me to change it ? | 16:20 |
| pedroalvarez | it has been merged | 16:21 |
| persia | gtristan: Do you know what ref that was tracking? | 16:22 |
| * gtristan checks this | 16:22 | |
| * gtristan is quite sure he just did 'git describe' | 16:23 | |
| persia | git describe doesn't always generate a ref that can be resolved. | 16:24 |
| pedroalvarez | the ref used is tip of master | 16:24 |
| pedroalvarez | looks like it's git describe, yes | 16:25 |
| gtristan | verified, indeed this is just the output of git describe at the tip of gnome-keyring master, which has not branched out for 3.18 yet | 16:25 |
| pedroalvarez | to me, git describe is more useful than master there | 16:25 |
| persia | Why? | 16:26 |
| * persia is actually curious how this field is consumed | 16:26 | |
| gtristan | I may be guilty of having pushed some commits with unpetrify-ref pointing to an unresolvable git describe output | 16:26 |
| gtristan | yeah, me too | 16:26 |
| pedroalvarez | you open the definition, see ref, don't understand a thing, and then see unpetrify-ref | 16:26 |
| * tiagogomes always uses the branch where the ref came from for unpetrify-ref | 16:26 | |
| gtristan | I consume it that way also | 16:26 |
| gtristan | but I assume it has some deeper purpose :) | 16:27 |
| pedroalvarez | if "master" in unpetrify-ref, no useful information | 16:27 |
| persia | pedroalvarez: So, how is `git describe` output more useful than master? It gives no information on how to advance to the "current" state from whatever state was used then. | 16:28 |
| gtristan | pedroalvarez, if it's cruft and not read by the machine, it may be better replaced by a per-chunk comment | 16:28 |
| persia | gtristan: We had issues with comments, which is part of why there aren't many | 16:28 |
| gtristan | mhm | 16:28 |
| pedroalvarez | we had, not sure if that is still the case | 16:28 |
| tiagogomes | pedroalvarez, I woudn't say it is useless. It tells you that the commit came from the development branch instead of stable branch | 16:28 |
| tiagogomes | `git describe` seems useless to me though, as it is a middle term between the ref and a possible stable branch or tag | 16:29 |
| gtristan | tiagogomes, sometimes that is all you have, though | 16:30 |
| gtristan | tiagogomes, typically when the stable release is recent and no branch is created yet, because no API changing work needs to land in master just yet | 16:30 |
| pedroalvarez | persia: I was just saying that for my human brain, 3.18.3-5-geb16c03 has more information than "master" | 16:32 |
| persia | pedroalvarez: I agree that it contains more information. I'm just wondering how this information would be used? What decisions might get taken based on this information, etc. | 16:33 |
| tiagogomes | tbh, I don't care much about what to put there, but I'd like consistency | 16:33 |
| pedroalvarez | I don't have answers for those questions. We should probably ponder, and investigate if we need them or not | 16:33 |
| persia | pedroalvarez: I'd be very curious if you ever think of answers for them :) | 16:34 |
| gtristan | this is an odd conversation; a more productive path may be: "Do we all agree that there is no tool which actually uses unpetrify-ref and that it is as such, obsolete ?" and then "Lets define a policy for what we actually do need instead and then enforce it" | 16:34 |
| persia | I fear most folk are like tiagogomes: using this field because it is there, rather than for some purpose. | 16:35 |
| pedroalvarez | yes, but I fear that if we remove it people will miss it | 16:35 |
| persia | gtristan: We agreed to the first part of that last year: we just never managed to get an answer for the second part, and some people are attached to the text in ways that are hard to explain in terms of policy. | 16:36 |
| persia | pedroalvarez: I *know* people will miss it, as every time I've suggested removing it, people have told me we should keep it. | 16:36 |
| richard_maw | 2 | 16:37 |
| richard_maw | erm, I think it needs a better name | 16:37 |
| richard_maw | that is all | 16:37 |
| * richard_maw hides again | 16:37 | |
| gtristan | Right, for machines, a stable/feature branch can be useful to pull the latest of that branch, for humans - "at least some information that is more comprehensible than an SHA1" would be nice, and I think for the latter a comment would suffice | 16:37 |
| tiagogomes | richard_maw +1 | 16:38 |
| ssam2 | yes | 16:38 |
| tiagogomes | And a policy of what to write on it | 16:38 |
| gtristan | SHA1s are the new binary, Klingon programmers can now claim to understand SHA1 keys | 16:38 |
| * gtristan just wanted that branch so he wrote in a52bcff0844.... by hand ! | 16:39 | |
| pedroalvarez | should we discuss the policy now that we are at it? | 16:39 |
| ssam2 | I think there are two uses: readable (tag/branch) name for sha1, and suggested-branch-for-ci-to-follow | 16:39 |
| ssam2 | we don't always need both | 16:39 |
| pedroalvarez | I think we can forget about the latter | 16:39 |
| ssam2 | that's fine. we can add it if we need it | 16:40 |
| * persia concurs about ignoring the latter | 16:40 | |
| ssam2 | so unpetrify-ref becomes ref-name, basically? | 16:40 |
| * tiagogomes thinks the same | 16:40 | |
| persia | Next question: can we trivially convert from SHA to name in some programmatic way? | 16:40 |
| * gtristan also agrees that would be a good rename | 16:40 | |
| persia | So that we don't need to remember to update the field on every commit? | 16:40 |
| ssam2 | persia: no, because one sha1 can be in multiple branches | 16:41 |
| gtristan | a branch-tracking thing should be ignored at least until such time that tooling would make use of it, otherwise it's bloat and not worth discussing | 16:41 |
| ssam2 | persia: if it appears in 'master', 'v1.3.0', and 'freds-feature-branch', it's hard for software to know which is the useful one | 16:41 |
| ssam2 | where a human knows right away that v1.3.0 is the meaningful namne | 16:41 |
| ssam2 | *name | 16:41 |
| pedroalvarez | I like fred | 16:41 |
| pedroalvarez | anyway, what we should do in the case I posted before this discussion | 16:42 |
| pedroalvarez | https://gerrit.baserock.org/#/c/1505/1/strata/gnome.morph | 16:42 |
| gtristan | rrright... ssam2 so basically I think persia is talking about some meaningful migration path | 16:42 |
| pedroalvarez | a) create a branch with a meaningful name ? | 16:43 |
| pedroalvarez | b) put master in ref-name? | 16:43 |
| gtristan | ssam2, so to put it another way, if we just ran a script right now which created ref-name from the SHA1, would it be "good enough for now" and follow a better policy in the future ? | 16:43 |
| pedroalvarez | c) ... more sugestions? | 16:43 |
| ssam2 | gtristan: do we need that? the info is there in 'unpetrify-ref' | 16:43 |
| ssam2 | pedroalvarez: (a) | 16:43 |
| gtristan | ssam2, or maybe we have to play rock paper scissors, and the loser has to spend their evenings converting them one by one :D | 16:43 |
| pedroalvarez | rock! | 16:44 |
| gtristan | haha | 16:44 |
| pedroalvarez | (is part of baserock) | 16:44 |
| ssam2 | pedroalvarez: as if someone upstream force pushes master, that commit would lost | 16:44 |
| pedroalvarez | (reproducible wins) | 16:44 |
| persia | No, I think I like what ssam2 is saying: that we need to put user-mediated information in the field to capture *intent*. | 16:44 |
| persia | Just because a commit is on some given branch doesn't mean that is the branch we want to be using. | 16:44 |
| pedroalvarez | ssam2: then, we shouldn't use tags either? | 16:45 |
| gtristan | we certainly dont alway have a tag to go on | 16:45 |
| persia | And tags aren't any more fixed than branches, except by social convention | 16:45 |
| gtristan | and when we intend to use stable, that stable is often still unbranched and on master | 16:45 |
| persia | (well, and that `git commit` doesn't auto-advance the tag) | 16:45 |
| ssam2 | pedroalvarez: no, we should tag everything locally using `morph anchor` | 16:46 |
| ssam2 | if we actually care about this stuff | 16:46 |
| ssam2 | "locally" meaning "in our mirrored Git repos" | 16:46 |
| * gtristan throws a stick in the front wheel: https://gerrit.baserock.org/1510 | 16:48 | |
| gtristan | Beware, gzip lorry ahead ! | 16:49 |
| persia | Yes, or simply cloning a repo from git.baserock.org, and adding any commit to any branch could also delete a commit we are about during the automatic `git gc` that runs as part of `git commit`. | 16:49 |
| pedroalvarez | I like the morph anchor idea, but.. are we going to do that for every single change? just for releases? | 16:55 |
| pedroalvarez | I want a baserock desing summit.. In a place that nobody can scape until we have answers for everything | 16:57 |
| persia | Depends on the release model. | 16:57 |
| persia | For the every-merge-is-a-release story, it would be something the gatekeeper should do on merge. | 16:57 |
| persia | pedroalvarez: The last time we did one of those nobody worked on anything afterwards :) We could do it again, but ... | 16:58 |
| persia | I don't know if it is too late, but maybe we could have a BoF at FOSDEM? | 16:58 |
| pedroalvarez | that's true.. I guess only people that can work on things should attend | 16:59 |
| pedroalvarez | hm.. no, there are users too | 17:00 |
| ssam2 | well, and also people who actually have a use for them | 17:00 |
| ssam2 | yeah | 17:00 |
| ssam2 | I think one problem we have is we do a lot of discussion without actual use cases | 17:00 |
| persia | I think that if we meet and have agreement, that makes it easier for people to have confidence that they are doing the right thing between meetings. | 17:00 |
| persia | Whether people actually have time to do it, etc. is different. | 17:00 |
| ssam2 | and my actual use cases, I mean people who are using the tooling and definitions to do things with purposes that are not "improve Baserock" | 17:00 |
| ssam2 | *by | 17:00 |
| persia | But by writing down the decisions and putting them on the wiki, there's a better chance that we end up building what we decided to build. | 17:01 |
| persia | ssam2: Absolutely. Non-developer users are key to successful creation of software. | 17:02 |
| *** ssam2 has quit IRC | 17:05 | |
| *** ssam2 has joined #baserock | 17:05 | |
| *** ChanServ sets mode: +v ssam2 | 17:05 | |
| *** franred has quit IRC | 17:09 | |
| * pedroalvarez sends: https://gerrit.baserock.org/#/c/1511/ | 17:17 | |
| pedroalvarez | (trying to get the gzip importer working on g.b.o) | 17:17 |
| gtristan | ah, I missed that setup.py file | 17:22 |
| pedroalvarez | and its friend: https://gerrit.baserock.org/#/c/1512/ | 17:26 |
| gtristan | yay | 17:30 |
| *** jonathanmaw has quit IRC | 17:59 | |
| *** jonathanmaw has joined #baserock | 17:59 | |
| *** bashrc_ has quit IRC | 18:06 | |
| *** edcragg has quit IRC | 18:20 | |
| *** locallycompact has quit IRC | 18:20 | |
| *** gtristan has quit IRC | 18:22 | |
| *** Lachlan1975 has quit IRC | 18:23 | |
| *** ssam2 has quit IRC | 18:44 | |
| *** gary_perkins has quit IRC | 18:57 | |
| *** rdale has quit IRC | 18:58 | |
| *** SotK has quit IRC | 22:16 | |
| *** SotK has joined #baserock | 22:17 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!