Announcement: Porting the Docs to Sphinx - 9. November 2022
Hello. Based on the very positive feedback I was given at the Cauldron Sphinx Documentation BoF, I'm planning migrating the documentation on 9th November. There are still some minor comments from Sandra when it comes to the PDF output, but we can address that once the conversion is done. The reason I'm sending the email now is that I was waiting for latest Sphinx release (5.3.0) that simplifies reference format for options and results in much simpler Option summary section ([1]) The current GCC master (using Sphinx 5.3.0) converted docs can be seen here: https://splichal.eu/scripts/sphinx/ If you see any issues with the converted documentation, or have a feedback about it, please reply to this email. Cheers, Martin [1] https://github.com/sphinx-doc/sphinx/pull/10840 [1] https://splichal.eu/scripts/sphinx/gcc/_build/html/gcc-command-options/option-summary.html
[EXTERNAL] Payment Advice Note from Monday, October 17, 2022
Dear gcc, Please see attached paid invoice. Thank you for your business! InnovativePay Due date:18/10/2022 10:11 PM For: gcc@gcc.gnu.org gcc.gnu.org
Re: Announcement: Porting the Docs to Sphinx - 9. November 2022
Hi Martin, Thank you very much for porting the documentation to Sphinx, it is very convenient to use, especially the menu on the left and the search bar. However, I also regularly browse and search the documentation through info, especially when I want to use regexps to search or need to include a special character (eg.,+,-,_,(; this can happen when I search for '(define' ) for example) in the search string. Does the port to Sphinx means the end of texinfo? Or, will both be available as it is the case now with the official texinfo and your unofficial splichal.eu pages. Paul On Mon, Oct 17, 2022 at 03:28:34PM +0200, Martin Liška wrote: > Hello. > > Based on the very positive feedback I was given at the Cauldron Sphinx > Documentation BoF, > I'm planning migrating the documentation on 9th November. There are still > some minor comments > from Sandra when it comes to the PDF output, but we can address that once the > conversion is done. > > The reason I'm sending the email now is that I was waiting for latest Sphinx > release (5.3.0) that > simplifies reference format for options and results in much simpler Option > summary section ([1]) > > The current GCC master (using Sphinx 5.3.0) converted docs can be seen here: > https://splichal.eu/scripts/sphinx/ > > If you see any issues with the converted documentation, or have a feedback > about it, > please reply to this email. > > Cheers, > Martin > > [1] https://github.com/sphinx-doc/sphinx/pull/10840 > [1] > https://splichal.eu/scripts/sphinx/gcc/_build/html/gcc-command-options/option-summary.html > > > >
Re: Toolchain Infrastructure project statement of support
Hi Carlos, On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote: > The GNU Toolchain project leadership [...] I must say I don't understand why you are communicating in this way. Sending out "proclamations" about having support from "leadership", "committees" and "key stakeholders". Some of these key people seem to not even agree with it or know what it is really about and they cannot or don't want to answer questions about the details. In the last year we did some really nice work for the sourceware infrastructure. We setup the shared buildbot, got various companies and organisations to provide compute resources, workers for various architectures. We now have CI, Try and Full builders for various projects and doing 10.000+ builds a month. With a bunsen analysis database with all those test-results. Did a resource analysis and wrote up this public roadmap to make the email/git based workflow that sourceware projects rely on more fun, secure and productive by automating contribution tracking and testing. We now also have the sourcehut mirror and the public-inbox instance to make the email workflow nicer and support things like patch attestation. We are working on better integration between patchwork and buildbot for pre- commit checking. And we got the Software Freedom Conservancy to accept sourceware as a member project to act as a fiscal sponsor. They are now helping us with the future roadmap, setting up a organization, budgeting, etc. And the FSF also is supportive of this. All this was done in public, we even setup some public video chats about how we wanted to do this in the future. And you were explicitly invited to participate because we wanted to make sure it fit with any other plans people might be having. At the Cauldron, when we wanted to discuss with the community how to use and set project policies around the sourceware infrastructure services, one of the "leaders" ran around the room shouting down and pushing people who wanted to discuss this. Telling people they didn't got to decide what we would talk about. And finally yelling at me that I lost all trust of the "gnu toolchain leadership". All just for wanting to have a public discussion on some cool stuff we did and were planning to do together. That isn't "leadership". That is just intimidation and bullying. It made me really sad. And now you again seem to not want to discuss any details on how to work together. After Cauldron I thought we agreed we would discuss goals on overseers and create sourceware infrastructure bugs. So we could see what the community priorities were, write an updated sourceware roadmap, setup a budget, etc. I was really happy to see the discussions about setting up a video chat system for projects, the FSF tech-team offering to setup mirrors, backups and help coordinate secure release uploads. And I had hoped to see some discussion on how the LF and potential sponsors could help, working together with the sourceware community and the SFC. We really would love for gdb, glibc, binutils and gcc to keep being part of sourceware. Cheers, Mark
Re: Toolchain Infrastructure project statement of support
On 2022-10-17 11:10, Mark Wielaard via Overseers wrote: In the last year we did some really nice work for the sourceware infrastructure. We setup the shared buildbot, got various companies and I feel like you're taking this personally as an overseer; the proposal to transition to LF IT is not a value judgment on your work. It is a proposal to scale far beyond what our current resources can afford. I personally am grateful for all that work and have participated in some of it too but I don't think that it's a scalable approach for gcc or to a lesser extent, glibc. organisations to provide compute resources, workers for various architectures. We now have CI, Try and Full builders for various projects and doing 10.000+ builds a month. With a bunsen analysis database with all those test-results. Did a resource analysis and wrote up this public roadmap to make the email/git based workflow that sourceware projects rely on more fun, secure and productive by automating contribution tracking and testing. We now also have the sourcehut mirror and the public-inbox instance to make the email workflow nicer and support things like patch attestation. We are working on better integration between patchwork and buildbot for pre- commit checking. And we got the Software Freedom Conservancy to accept sourceware as a member project to act as a fiscal sponsor. They are now Fiscal sponsor for the *sourceware overseers*. There's no way for SFC to be a fiscal sponsor for sourceware, which is infrastructure owned by Red Hat. helping us with the future roadmap, setting up a organization, budgeting, etc. And the FSF also is supportive of this. The FSF has little stake in sourceware beyond the GNU toolchain, so FSF being supportive of sourceware overseers seeking funding has about the same relevance as the FSF being supportive of my decision to move to a different country. They do have a significant stake in infrastructure for the GNU toolchain project and they've been part of discussions since the idea for GTI germinated. And now you again seem to not want to discuss any details on how to work together. After Cauldron I thought we agreed we would discuss goals on overseers and create sourceware infrastructure bugs. So we could see what the community priorities were, write an updated sourceware roadmap, setup a budget, etc. On multiple occasions I've been told on this list that sourceware administration being transitioned to LF IT is out of question, so I don't see the point of having these discussions. I don't see a retention plan that's viable for the next 5, 10 or 20 years. I personally do not think the current sourceware infrastructure, even with the roadmap it promises is a viable alternative to what LF IT can provide. There is a significant resource gap (e.g. service isolation to different machines and/or containers, full time administrators with global presence for FTS support, established security and administration practices, traffic acceleration, to name a few) that we seem to disagree about. There seems to be little to discuss from the GNU toolchain perspective IMO; the overseers think that the LF IT proposal and the additional funding and infrastructure it brings in are not necessary and we think it is. I was really happy to see the discussions about setting up a video chat system for projects, the FSF tech-team offering to setup mirrors, backups and help coordinate secure release uploads. And I had hoped to see some discussion on how the LF and potential sponsors could help, working together with the sourceware community and the SFC. We really would love for gdb, glibc, binutils and gcc to keep being part of sourceware. IMO the best way to make this happen is for us to transition sourceware administration to LF IT. However since all projects hosted on sourceware don't seem to agree on this and the overseers also do not desire to give up control over the infrastructure, I don't see another way out of this. Of course, like I said to Chris, it's likely going to be a while before we fully transition away from sourceware (it'll likely happen one service at a time, or something like that, we need to figure that out at some point) and we'll need continued help from the overseers to help manage the infrastructure in the near future. Sid
Re: Announcement: Porting the Docs to Sphinx - 9. November 2022
On 10/17/22 07:28, Martin Liška wrote: Hello. Based on the very positive feedback I was given at the Cauldron Sphinx Documentation BoF, I'm planning migrating the documentation on 9th November. There are still some minor comments from Sandra when it comes to the PDF output, but we can address that once the conversion is done. My main complaint about the PDF is that the blue color used for link text is so light it interferes with readability. Few people are going to print the document on paper any more, but I did try printing a sample page on a grayscale printer and the blue link text came out so faint that it was barely visible at all. An E-ink reader device would probably have similar problems. I'm generally not a fan of the other colors being used for formatting, either. To me it seems like they all interfere with readability, plus in code samples it seems like random things get highlighted in random colors, instead of focusing on the thing the example is trying to demonstrate. I've been preferring to use the PDF form of the GNU manuals because it is easier to search the whole document that way. The search feature in the new web version doesn't quite cut it it gives you a list of web pages and then you have to do a second browser search within each page to find the reference. So I hope we can continue to support the PDF as a canonical format and better tune it for easy readability, instead of assuming that most people will only care about the online web version. -Sandra
