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=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14650 invoked from network); 9 Sep 2020 14:55:13 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 9 Sep 2020 14:55:13 -0000 Received: (qmail 26782 invoked by uid 89); 9 Sep 2020 14:55:38 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 26775 invoked from network); 9 Sep 2020 14:55:37 -0000 From: "Laurent Bercot" To: "supervision@list.skarnet.org" Subject: Re: s6-man-pages update Date: Wed, 09 Sep 2020 14:55:10 +0000 Message-Id: In-Reply-To: <87r1rbavqo.fsf@ada> References: <87r1rbavqo.fsf@ada> Reply-To: "Laurent Bercot" User-Agent: eM_Client/8.0.3385.0 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrudehhedgjeejucetufdoteggodftvfcurfhrohhfihhlvgemucfpfgfogfftkfevteeunffgpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhhrfgggtgfgsehtqhertddtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdhsuhhpvghrvhhishhiohhnsehskhgrrhhnvghtrdhorhhgqeenucggtffrrghtthgvrhhnpedtfeekueetieektefhveeuveevtdekgeefhfeutedvieeiheduueeiudehvdetveenucffohhmrghinhepshhkrghrnhgvthdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht >Fair enough. :-) My thought is, to help distros with packaging, i can add= tags to the s6-man-pages repo to match the corresponding s6 version on whic= h they were based. So at the completion of this current process, i could ad= d a 2.9.2.0 tag (assuming that the current docs on skarnet.org are from the = 2.9.2.0 release). Does that sound reasonable? The docs on the website are updated at least at every release, but also a bit more often: when I have fixes for the documentation, I add them to the git repo and also to the website. So the website always has the most up-to-date documentation (barring functionality that has not been released yet). For instance, the current git head, as well as the website docs, include the fixes to the typos you reported, whereas the v2.9.2.0 git tag does not include them. So I don't know what policy would be best. It would probably be easier for you to mimic the tags; I can commit to notifying you on git changes impacting documentation, so you can have a "current" branch mimicking the state-of-the-art. But it's really up to you, and all in all I think tags are a good idea. :) -- Laurent