Re: On raw strings in commit field

2021-12-31 Thread Mark H Weaver
Hi Liliana, Liliana Marie Prikler writes: > Am Freitag, dem 31.12.2021 um 18:36 -0500 schrieb Mark H Weaver: >> Hi Liliana, >> >> Liliana Marie Prikler writes: >> > In my personal opinion, the version+raw commit style can be >> > discredited using Cantor's diagonal argument. >> >> You've ment

Re: On raw strings in commit field

2021-12-31 Thread Mark H Weaver
Hi Liliana, Liliana Marie Prikler writes: > Am Mittwoch, dem 29.12.2021 um 20:13 -0500 schrieb Mark H Weaver: [...] >> The simple fact is that the way Ricardo wrote the 'guile-aiscm' package >> is the right way to ensure that it can be reliably reproduced in the >> future. > And here I disagree.

Re: On raw strings in commit field

2021-12-31 Thread Liliana Marie Prikler
Am Freitag, dem 31.12.2021 um 18:36 -0500 schrieb Mark H Weaver: > Hi Liliana, > > Liliana Marie Prikler writes: > > In my personal opinion, the version+raw commit style can be > > discredited using Cantor's diagonal argument. > > You've mentioned Cantor's diagonalization argument at least twice

Re: On raw strings in commit field

2021-12-31 Thread Liliana Marie Prikler
Am Freitag, dem 31.12.2021 um 18:56 -0500 schrieb Mark H Weaver: > Hi Liliana, > > Liliana Marie Prikler writes: > > > Git commit hashes do not just depend on the content.  They also > > depend on how much effort you put into solving a proof of work > > challenge that won't ever earn you crypto

Re: On raw strings in commit field

2021-12-31 Thread Mark H Weaver
Hi Liliana, Liliana Marie Prikler writes: > Git commit hashes do not just depend on the content. They also depend > on how much effort you put into solving a proof of work challenge that > won't ever earn you crypto coins [1]. My knowledge of git is admittedly not that strong, but my understan

Re: On raw strings in commit field

2021-12-31 Thread Mark H Weaver
Hi Liliana, Liliana Marie Prikler writes: > In my personal opinion, the version+raw commit style can be discredited > using Cantor's diagonal argument. You've mentioned Cantor's diagonalization argument at least twice in this thread so far, but although I'm familiar with that kind of argument fo

Re: On raw strings in commit field

2021-12-31 Thread Liliana Marie Prikler
Hi, Am Freitag, dem 31.12.2021 um 18:21 +0100 schrieb zimoun: > Redundancy adds one kind of robustness: resilience.  [...]  However > this assumes all the redundant nodes of the web of nets will be still > up, at least enough to have this…  robustness.  Me too, I hope Guix > will be popular and al

Re: On raw strings in commit field

2021-12-31 Thread Vagrant Cascadian
On 2021-12-28, Liliana Marie Prikler wrote: > Consider a package being added or updated in Guix. At the time of > commit, we have the tag v1.2.3 pointing towards commit deadbeef. We > therefore create a guix package with version "1.2.3" pointing to said > commit (either directly or indirectly).

Re: On raw strings in commit field

2021-12-31 Thread zimoun
Hi, On Fri, 31 Dec 2021 at 16:19, Liliana Marie Prikler wrote: > You're also missing the part in which it currently relies on a single > server to do all this, but there are plans to move it out to multiple > ones, i.e. adding fallbacks/redundancy to your fallback mechanism, > which for the rec

Re: On raw strings in commit field

2021-12-31 Thread Liliana Marie Prikler
Hi, Am Freitag, dem 31.12.2021 um 14:15 +0100 schrieb zimoun: > [...] > Version is also Guix specific.  Sometimes, we patch; for security > reasons, for fixing a bug, for quickly backporting something, for > removing non-free bits, for unbundling stuff, for making work with > the rest of Guix pack

Re: On raw strings in commit field

2021-12-31 Thread Liliana Marie Prikler
Am Freitag, dem 31.12.2021 um 13:31 +0100 schrieb Ricardo Wurmus: > > Liliana Marie Prikler writes: > > > Particularly here, you're used to raw commit hashes, so you no > > longer feel the need to add a comment explaining that it > > corresponds to a given tag, which others (such as myself, your

Re: On raw strings in commit field

2021-12-31 Thread zimoun
Hi all, On Fri, 31 Dec 2021 at 10:31, Ricardo Wurmus wrote: > I have no strong feelings for or against any of the proposed options. I > think that using raw commits might not be great for our tooling because > we’re not reusing an existing version string and would need to remember > to update t

Re: On raw strings in commit field

2021-12-31 Thread Ricardo Wurmus
Liliana Marie Prikler writes: > Particularly here, you're used to raw commit hashes, so you no longer > feel the need to add a comment explaining that it corresponds to a > given tag, which others (such as myself, your past self and possibly > your future self) would need at least until they th

Re: Updating old blog posts?

2021-12-31 Thread Liliana Marie Prikler
Am Donnerstag, dem 30.12.2021 um 16:01 -0500 schrieb Leo Famulari: > I updated a section of the cookbook so that it was still useful after > some changes in Guix: > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c7d74a9bccfc1b1274fc8754a6e78bb6887c7fea > > There was also a blog post made

Re: On raw strings in commit field

2021-12-31 Thread Liliana Marie Prikler
Hi Ricardo, Am Freitag, dem 31.12.2021 um 10:31 +0100 schrieb Ricardo Wurmus: > In the past I’ve also added a comment above the raw commit, stating > that it corresponds to the given version. > > I have no strong feelings for or against any of the proposed > options.  I think that using raw commi

Re: On raw strings in commit field

2021-12-31 Thread Liliana Marie Prikler
Hi, Am Freitag, dem 31.12.2021 um 08:57 +0100 schrieb Taylan Kammer: > On 31.12.2021 04:15, Liliana Marie Prikler wrote: > >   [...] Obviously, > > when travelling back in time, we want Guix' "1.2.3" to be whatever > > it was by that point, but on th

Re: On raw strings in commit field

2021-12-31 Thread Ricardo Wurmus
Liliana Marie Prikler writes: >> And for completeness, let quote Ludo again from the same thread. :-) >> >>     No, I think we should consider always referring to commits >>     instead of tags.  It’s annoying from a readability viewpoint, >>     but it would ensure reproducibility