From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id C072C3858D3C for ; Sun, 27 Nov 2022 23:44:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C072C3858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x0e.wildebeest.org [172.31.17.144]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 4CA94300B351; Mon, 28 Nov 2022 00:44:29 +0100 (CET) Received: by reform (Postfix, from userid 1000) id 0DEE62E80573; Mon, 28 Nov 2022 00:44:29 +0100 (CET) Date: Mon, 28 Nov 2022 00:44:28 +0100 From: Mark Wielaard To: Nick Clifton Cc: joel@rtems.org, Mike Frysinger , Joel Brobecker , Nick Clifton via Binutils Subject: Re: A GNU Binutils wiki Message-ID: References: <71067e2b-f43b-2be8-ea4a-88ead1dd6e56@redhat.com> <4ca81bcb-c569-7d9d-a243-fea12bfead52@redhat.com> <87fb1712-d568-46fc-aa47-733ff6931171@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87fb1712-d568-46fc-aa47-733ff6931171@redhat.com> X-Spam-Status: No, score=-3032.7 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, On Wed, Nov 02, 2022 at 02:49:35PM +0000, Nick Clifton via Binutils wrote: > > Not to be negative but what type of content is going to go in the Wiki? > > Well I am hoping that there will be two types of content: > > 1. Things that will encourage people to contribute to the binutils. > 2. Information that will help binutils users solve their problems > (without having to post questions to the mailing list). > > > Over at RTEMS, I've become quite disillusioned with Wikis for most > > content. Not being integrated with the source processes, version > > control, and releases, it can become out of sync and out of date. > > To be fair I am expecting that much of the content will not be that > sensitive. Things like the descriptions of what the tools do, how to > contribute changes, where to ask for help, the history of the project > and so on. These are all fairly static. I think the wiki is nice for these kind of more "social" things than direct code things. I added a little on the buildbot CI and try builders: https://sourceware.org/binutils/wiki/Buildbot > > It's usually much easier to keep documents in any markup system > > up to date than a wiki. > > Would you feel happier if the text for the wiki was kept in the sources > and then uploaded to the site on a semi-regular basis ? (eg when releases > are made, or once a month, or some other schedule). However the documentation is maintained it will always be a bit of a struggle to keep it up to date. The advantage of the wiki is that it is updated immediately and that non-developers can update it. But for documentation that is actually about the code it makes sense that only actual developers can commit it. Now that we have the buildbot and do a build for every commit of code we can do the same for the documentation. How are the current code snapshots created? How is the documentation uploaded at release time? We can automate both and publish them on a special buildbot worker under something like snapshots.sourceware.org/bintuils to keep them current and so everybody can immediately see how the documentation looks. Cheers, Mark