Dear community, I've rolled all suggestions into this (near?) final version. I believe we're ready to vote on this now.
Changes to v2.0: * added a half-sentence to clarify that the developers of the forked attic repo would need to want it back as active at TDF * rolled Caolan's small/medium/large project idea into both atticisation and de-atticisation text Cheers, Thorsten -%<------------------------------------------------------------------ ## 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 “deatticization” requirements and how to get support on the code inside the repository needs to be present in the README of every repository. The text of these disclaimer and the deatticization 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-backend [1]. The proposal has already been evaluated by the Infra team and the overhead for maintaining such a solution will be “negligible”. ## Considerations about the approval procedure for atticization/deatticization As per the Statutes of the Foundation, the Board of Directors (BoD) should be the ultimate decision-making body of the Foundation; thus it has technically the last word on the approval or the refusal of an atticization/deatticization proposal. If we analyse the matter at hand, we recognize there is another codified body inside TDF that is directly composed by the technical part of the community and, as such, should have more insights and knowledge on the parts of the project that are proposed to be atticized/deatticized; that body is the Engineering Steering Committee (ESC). As such, a common and shared understanding of the political and technical impacts of the atticization/deatticization proposal has to be reached by the two bodies all together, and this understanding should be condensed in a unique, unambiguous preference towards approval or disapproval. The leanest approval process would then be that the ESC expresses its preference and the BoD agrees with the ESC. The proposal is then officially accepted or refused by the BoD, according to the preference expressed. If this doesn't happen, a shared discussion in a public meeting with the components of both bodies is highly recommended; the goal of such consultations would be to understand and underline weaknesses and threats of the proposal, and eventually to get to a unique preference. Whatever the means of the consultations are and if there is no clear preference as outcome, but the BoD is called anyways to decide, it has to provide an official written report on the merits of the decisions, the decisions taken, and a mitigation plan for the hard blockers identified during the discussion. ## 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, as per the procedure hinted in the previous section. For an eventual de-atticization procedure, the ESC will mark the project under atticization as either small, medium, or large in terms of code size and complexity. After the approval of the atticization proposal, 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 the 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 deatticized 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; • A sufficient number of developers [2] 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 deatticization proposal has to be supported by those active developers, and by at least one member of The Document Foundation; • At the discretion of the ESC or the BoD, if parties involved in the development of the project are commercial entities and as a prerequisite of approving/refusing the proposal: * A formal agreement must be published outlining the scope, benefits and responsibilities of both the parties and TDF. * This agreement should state any significant impacts on TDF, its development community, and users both negative and positive. ## Deatticization procedure The deatticization has to be requested from either the ESC or the Board of Directors; the ESC will provide a technical clearance for the deatticization, 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. A well-written proposal for the deatticization can help the ESC and the BoD to quickly identify requirements, changes needed and thus speed up the approval; some samples might be provided to haste the process. Once clearance has been granted, both ESC and BoD will vote on the deatticization of the specific repo, as illustrated by the above section (cft. "Approval procedure for atticization/deatticization"). 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 deatticization 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]. --- [1] (https://git-scm.com/docs/git-http-backend) [2] 1 for small, 3 for medium, and 6 developers for a large project -%<------------------------------------------------------------------
signature.asc
Description: PGP signature
