From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 597CA3858C83 for ; Wed, 2 Nov 2022 14:49:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 597CA3858C83 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667400582; 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=6udxT39FOg16QicEShb2slwYEzoozWFI9EQVMwNLKso=; b=OJ4UtsASIT7nJrYVaKUKcoIqE9VuC91RlRu23xzRG7QU0pbc0rRPEiKCrQBkadJvD2GG6v b8tJl5gMKQ5bFqNqs9MRRPbZgwM5HzISQlBU2fxvXOMx3iAUKmwp1Pn4MHhRGg1NH80AMT w/lqLF5rdKaqFUL28N+0YNC350rtrGY= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-250-xr_ETw8lOEas8O8P3x7Aeg-1; Wed, 02 Nov 2022 10:49:38 -0400 X-MC-Unique: xr_ETw8lOEas8O8P3x7Aeg-1 Received: by mail-qk1-f198.google.com with SMTP id bp10-20020a05620a458a00b006fa29f253dcso8447332qkb.11 for ; Wed, 02 Nov 2022 07:49:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:references:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6udxT39FOg16QicEShb2slwYEzoozWFI9EQVMwNLKso=; b=TrRz9vpgMMhzdWQ2V79jIcfHy0Sv6TpoTgipnNcnSGDIpIakBO1kTQfn/2VOmmoo0S juVM/zz7LJKf0XWpURR0a57Fo0MyloLnqXrrGSdcKIotwG7AUFiLpv+C2i/DDB5SBOj9 LQb9q9yIu1sHlhRLQjpIegwp50duOFqfaWEbyMVTG0PW/Fu9lcPDmTB6CXpDlS8dx4kW 7pVg8RhU9A+LiYItf51LtNswKQzce/rcKpzDAu+96UFqEZLuegV/WcIvkrHcTNm66W3L C2WVxE908pBiHSiG9SSONJSebKaHIKa1rClHK6292tKRQxU56MPusS7C9bQFcpMLkygh 0MwA== X-Gm-Message-State: ACrzQf1cJWFB+/5u5lk9vs2+DNW0/9rf/gs80KfeGg2Jool/peXUZKYc Za6pS0C7kLiLEWlILm1aykaO6BYo8xY0/1S5gbPtP2svD0P2oQB67BMdy/t9SuXckzdA65NWXW8 uyHUANyZ+0gpaT8l5Lg== X-Received: by 2002:a05:622a:1014:b0:39c:c5ef:c768 with SMTP id d20-20020a05622a101400b0039cc5efc768mr19426266qte.525.1667400577946; Wed, 02 Nov 2022 07:49:37 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4bnKyaQ5g5nIvpvij8Kc17LnXk5r9aID1+XwiNrxzKR9iiGgckRanXXNM0bGsLAaGmL+BAQw== X-Received: by 2002:a05:622a:1014:b0:39c:c5ef:c768 with SMTP id d20-20020a05622a101400b0039cc5efc768mr19426257qte.525.1667400577713; Wed, 02 Nov 2022 07:49:37 -0700 (PDT) Received: from [192.168.1.18] (adsl-164-85.freeuk.com. [80.168.164.85]) by smtp.gmail.com with ESMTPSA id r17-20020a05620a03d100b006eee3a09ff3sm8441336qkm.69.2022.11.02.07.49.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Nov 2022 07:49:36 -0700 (PDT) Message-ID: <87fb1712-d568-46fc-aa47-733ff6931171@redhat.com> Date: Wed, 2 Nov 2022 14:49:35 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 To: joel@rtems.org, Mike Frysinger , Joel Brobecker , Nick Clifton via Binutils References: <71067e2b-f43b-2be8-ea4a-88ead1dd6e56@redhat.com> <4ca81bcb-c569-7d9d-a243-fea12bfead52@redhat.com> From: Nick Clifton Subject: Re: A GNU Binutils wiki In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham 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 Joel, > 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. > 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). > This ignores that Wikis get vandalized and have spam account attempts > which doesn't seem to happen with source code in git (or cvs). Ideally the fact that only people in the EditorGroup can make changes to the wiki should help to reduce/eliminate this problem. > What's the process for ensuring any links in the wiki don't break? There isn't one. (I would assume that broken links would be reported and fixed, but there is no formal scheme for verifying that any links continue to work). > What review processes are going to be used for content? Similar to the current process for patch review would be my assumption. People with EditorGroup access can make changes directly. Others would submit changes for review and eventual application. > What's the driving content need for a wiki? Apparently wikis have been successful for other projects, eg glibc, and I am trying, in a small way, to bring the GNU Binutils up to date. It was pointed out for example that we do not have a Code of Conduct or a Mission Statement. Now some people might feel that these things are not really necessary, but would it hurt to have them ? And if we do have them, where would a naive, unexperinced-with-the-binutils person look for them ? > Sorry to be negative. I like the "control" in source code control > and a wiki is lacking there. That's fine. It is good to have an opinion and I am glad that you are willing to express it. My counter would be - what can we do instead ? I know that most of the information intended for the wiki can be found by digging through the sources, but that will not work for people who are not already deeply familiar with the binutils. So I wanted to create a place where people with at least some experience with other part(s) of the GNU toolchain would expect to be able to find information on the binutils. Plus I wanted to provide a location for binutils users and contributor to be able to provide their own content. Descriptions of the problems that they encountered whilst porting the binutils; advice for users of small devices that need custom linker scripts in order to work properly and so on. Plus a location with responses to frequently asked questions(tm) which we can use when answering those I-have-found-a-name-mangling-bug and why-doesn't-the-assembler-auto-correct-my-bugs type questions on the mailing list. Cheers Nick