Dear Thorsten, Emiliano, board, dear TDF members, all,
first of all, I'd like to state for those that are not into the current status quo that this proposal will mainly affect the "Online" project at TDF's infra. I have to say, as a contributor of LibreOffice Online and a member of TDF, this proposal makes me completely unhappy, although it was clear since day 1 of Collabora forking Online that some decision had to be taken on our end. I have already said this many times but I want to repeat it: it has to be clear (and hopefully stated by legal contracts) to the companies working in the LibreOffice ecosystem that they cannot wake up one day and bring their development outside the LibreOffice project. They cannot stay with one foot inside the ecosystem, contributing to it, and with the other one bringing their development effort outside. This is something the next board should focus on. Getting to this specific situation, Jan 'Kendy' Holešovský, in the last Q+A session for the next BoD, stated that “it was really hard for us [Collabora] to get contributors and volunteers under the TDF umbrella… and we tried hard […] now that we’re on GitHub we get several commits from random people just because it’s on GitHub” [1]. Kendy didn’t bring any data supporting this thesis but – for the sake of the argument – assume he’s true. Shouldn’t this have been a concern for the whole foundation, and not only for Collabora? It’s the foundation scope to bring new developers in. If GitHub can magically attract developers, also TDF, from my point of view, should move there. There are indeed a few concerns I have to bring: have you ever wondered why the Nextcloud Server project on GitHub has 1.6k open issues? Why do they need so many tags, bots, and PEOPLE, employees that spend their time closing useless issues that are used as support requests? What I’m trying to say is that a wider audience also comes with considerable disadvantages. In his speech, Kendy also mentions that “we [Collabora] love LibreOffice”. I am sure that what he says is true, which is precisely why he (with the whole Collabora team) could help us understand why they renamed lool (LibreOffice Online) to cool (Collabora Online) also in the source code [2], removed the “This file is part of the LibreOffice project.” statementfrom the headers of the source [3] and changed the variable names [4]. In conclusion, I would like to emphasise the fact that I’m completely unhappy with the “attic” proposal as a solution for the Online situation and hope we can all work together to allow TDF to still consider Online a part of the LibreOffice suite. All the best, Marco [1] 1:40:00 and on, https://www.youtube.com/watch?v=YL1NnGvbZT8 [2] https://github.com/CollaboraOnline/online/commit/f07ff8c7e0754babe9819163fb0edeacac326caf https://github.com/CollaboraOnline/online/commit/ec8f28d75c62f2ea1e0bc147ac80b68a52336932 [3] https://github.com/CollaboraOnline/online/commit/0002fdfd6c21655bcba3fb69b291af4d3801ad79 [4] https://github.com/CollaboraOnline/online/commit/34b8ff08f6c417acbf62c256f0b9371d725c4e54 Il 17/12/21 12:16, Thorsten Behrens ha scritto: > Dear board, dear TDF members, all, > > as mentioned a few times during board calls, Emiliano and me have been > drafting a proposal what to do with no-longer-active projects at TDF. > > Here's the draft we're both happy with: > > -%<------------------------------------------------------------------ > > ## Introduction > > It can happen, with a huge project like LibreOffice, that parts > of the project worked on by the community will become obsolete or > superseded by other projects. The following proposal will cope > with the need to let the code (and/or other form of text related > to the code) to be publicly available, while setting the correct > expectations around its availability, suitability for a > production environment, quality and security. > > ## What is the “attic”? > > The “attic” is a special area of TDF infrastructure where part of > the code/documentation/translations can be parked, that is not > anymore actively developed. This will help setting the correct > expectations on its status of development, while not losing its > fundamental trait of being open source (so its code must be > publicly available). > > In the present proposal, the “attic” would be a single host > inside TDF infrastructure, available in HTTP/HTTPS protocols, > responding to a URI similar to: > https://attic.documentfoundation.org > > ## Specificity of the “attic” > > This “attic” space will have, at minimum, the following characteristics: > > • It is supported by git – the well known CVS developed by Linus > Torvalds initally and used to share the sources of the Linux > kernel. Being supported by git will ease the forking of the code > contained there; > > • Any repositories inside it will be made “read only”, so no “push” or > “pull request” mechanisms will be available: this allows changes to > the code to be shared as it was the last time it was “atticisized”; > > • Anonymous access to the repositories has to be made the default > access method: we want the code present in the “attic” to be always > available to everyone; > > • It should have a recognizable URL – or internet address, less > technically: this allows for the code present to be clearly > separated by other actively developed code; > > • A specific text explaining the nature of the code, its > “de-atticization” requirements and how to get support on the code > inside the repository to be present in the README of every > repository. The text of these disclaimer, the de-atticization > requirements will be discussed further on in the proposal. Regarding > contacts to get support, the idea is to provide quick and ready > information on who/where to ask for anything related to the code in > the repository. > > The proposed implementation of this space is by using > git-http-backend1. The proposal has already been evaluated by the > Infra team and the overhead for maintaining such a solution will be > “negligible”. > > ## Atticization process > > The Engineering Steering Committee (ESC) of TDF, the Board of > Directors (BoD) or one or more of its Directors can propose the > “atticization” of a part of the project. That proposal will have to be > voted on successfully by both the ESC and the Board of Directors. > > The specific code proposed (mostly, entire git-based repositories) > will be then effectively atticized by the Infra team. Other than > moving the repository to the attic, these other changes will be > needed: > > • Deactivation of specific -dev or -users mailing list; > > • No new binary releases will be provided (older releases will persist > in download archive); > > • Changing eventual specific category on BugZilla to “Atticized repo – > please do not use” (ed.: needs to be checked by Infra/QA/Ilmari); > > • Possibly disable Ask/Discourse pertaining categories (ed.: needs to > be checked by Infra/Sophie). > > ## De-atticization > > A part of the project that is actually present inside the “attic” can > be moved back into active development, whenever sufficient interest > around the code emerges. > > ## De-atticization requirements > > A repository can be de-atticized when it reaches the following requirements: > > • A publicly available repository has to be present, collecting new > modifications to the initial project. This repository needs to be > based on the initial atticized repository; > > • The modified code has to be open source/free software under an > OSI-approved license; > > • At least three different developers have committed changes to the > forked repository, ideally not all of them affiliated to the same > entity; > > • Every developer should have pushed 5-10 non-trivial commits over the > span of at least three months; > > • The de-atticization proposal has to be supported by at least one > member of The Document Foundation. > > ## De-atticization procedure > > The de-atticization has to be requested from either the ESC or the > Board of Directors; the ESC will provide a technical clearance for the > de-atticization, as well as any needed corrections to the project to > comply to specific development customs of TDF community and to adhere > to the conventions practiced at TDF. > > Once clearance has been granted, both ESC and BoD will vote on the > de-atticization of the specific repo. > > If the vote turns out affirmative, the implementation part will be > handed over to Infra team, which can, based on common sense: > > • Import the forked public repository; > > • Or move the repository from attic to gerrit altogether and apply the > needed corrections. > > If needed, new mailing list, BugZilla and Ask/Discourse categories > will be instantiated. > > ## Proposed text for the nature of the code > > The following text is proposed to be included in the README of any > atticized repository: > > --- > > This repository contains FLOSS code that is not maintained and/or > actively developed. The code provided here is *NOT READY FOR > PRODUCTION*, as it lacks updated security auditing (and probably > contains insecure code) and Quality Assurance. Releases are *NOT* > anymore provided for this code. > > --- > > ## Proposed text for the un-atticization requirements > > The following text is proposed to be included in the README of any > atticized repository: > > --- > > This repository might be moved to active development under TDF’s > supervision through a specific procedure. > > Please check that your modifications match the following requirements > (which needs to be all fulfilled): > * modified code is present in a publicly available git repository > * modified code is release with a free/open source license > * at least 3 developers, ideally not from the same entity, modified the code > * modifications efforts to the code are qualified as 5-10 non-trivial commits > for each developer over a period of 3 months > * modified code is actively advocated by at least a member of TDF > > If the requirements are fulfilled and you can guarantee to continue to > develop on the modified code, please get in touch with TDF ESC and > Board of Directors. > > Full procedure available at [Insert URL to a wiki page with the > procedure here]. > > --- > > -%<------------------------------------------------------------------ > > Cheers, > > -- Thorsten
