From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no
	version=3.4.4
Received: (qmail 12726 invoked from network); 14 Jun 2022 19:40:14 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 14 Jun 2022 19:40:14 -0000
Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Tue Jun 14 15:38:35 -0400 2022
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org;
	s=20200506; t=1655235511;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=ewUk+u/a1AXG1igcHl88CRRwkmm2zFY+EHSk2Aj0YZE=;
	b=rnmlju8CPvpFvCinS/JHwqpATyyDhZypKdjZWEsLtw5st0GCZEKP1BZFeyTkc+AftNGPIc
	nRC0EfHA0OTxXqjS2S607qUapKY1/A16AEbzCozPGR+DzTfLWjO98aLHg8PoHqMhU1WN9Y
	8iOsc6gMbbFv3Ix4/rTi/dw84E5V3R0=
Received: from [192.168.168.200] (161-97-228-135.lpcnextlight.net [161.97.228.135])
	by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id d15b6f0d (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO)
	for <9front@9front.org>;
	Tue, 14 Jun 2022 14:38:31 -0500 (CDT)
Message-ID: <99f34c74-1578-c00a-8237-66b00fb2a1f5@posixcafe.org>
Date: Tue, 14 Jun 2022 13:37:44 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Content-Language: en-US
To: 9front@9front.org
References: <546AB7A189C97E6865B97D7342EB6B66@eigenstate.org>
 <d7c7389b-5e94-68d3-183e-ac368ea29544@posixcafe.org>
 <b5156cb7bf5d0d73@orthanc.ca>
From: Jacob Moody <moody@mail.posixcafe.org>
In-Reply-To: <b5156cb7bf5d0d73@orthanc.ca>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: XMPP over ORM high-performance base base-oriented layer 
Subject: Re: [9front] [PATCH] embed git head hash as /dev/head
Reply-To: 9front@9front.org
Precedence: bulk

On 6/14/22 11:32, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
>> Wasn't aware we shipped with other version control software :P.
> 
> It was hg until just a few months ago.  Don't assume it will be git
> this time next year.

Yeah fair point.

> 
> Also, I am not a fan of /dev/head. I'd prefer to see this as an attribute
> of /dev/config, perhaps added to the start of its output:
> 
>   term% cat /dev/config
>   # kernel version xyzzy
>   #
>   # pc64 - amd64 pc terminal with local disk
>   [...]
>   term%
> 
> 'xyzzy' can be whatever version string is appropriate.
> 
> To be clear, I'm talking about having the /dev/config driver synthesize
> those first two lines whenever someone does a read on the file.
> 

If we did want to add it, I think this would be the way to go.
A lot less intrusive if it does/doesn't exist.

But to take a step back, I haven't seen anyone _love_
this idea. My original intent with this was to provide
the revision in the kernel to assist in debugging.
But I am not entirely convinced this would be useful.
We already have KERNDATE, and it's quite easy to just
say 'update your kernel if you haven't in a while'.
If it becomes suspect in a debugging session.

Since the general update flow to me seems to be:
: sysupdate
: @{ cd /sys/src/ && mk install }

What might be more useful is keeping track of where we
updated from. To have a list of commits as suspect for
if a bug appears after updating. You have this to some extent
already, if you update and things break today, you have a dump
from yesterday with your previous commit hash in /dist/plan9front.
That works fine, but does assume daily dumps. To avoid that assumption
you could have something like /dist/plan9front/revisions or /sys/log/revisions,
append only files that just log the jumps between versions done by sysupdate.
But I dont love this either.

Thanks,
moody