I vote +1. I wrote: > Dear directors, > > calling for an email VOTE on the below final version of the Attic > Proposal. The vote runs for 72 hours, starting now. > > Changes since v2.1: > * corrected mistakes found during Monday board call > * light touch-ups for English > * aligned the readme text suggestions with the changes in the prose > above > > Best, Thorsten > > -%<------------------------------------------------------------------ > > ## Introduction > > It can happen, within 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 deal > with the need to let the code (and/or other forms of text related > to the code) 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's infrastructure where part of > the code/documentation/translations, which is not being actively > developed, can be stored. This will help to set the correct > expectations on its development status, 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's infrastructure, available via HTTP/HTTPS protocols, > responding to a URI similar to: > https://attic.documentfoundation.org > > ## Specificity of the “attic” > > This “attic” space will have, at a minimum, the following characteristics: > > • It is supported by Git – the well known VCS developed initially by > Linus Torvalds and used to share the sources of the Linux > kernel. Being supported by Git will ease 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 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 for the code > inside the repository needs to be present in the README of every > repository. The text of these disclaimers 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 infrastructure 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 that 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 into a > unique, unambiguous preference towards approval or disapproval. > > The leanest approval process would then be: 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 > members 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 for an outcome, but the BoD is called to decide anyway, 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 described in the previous section. > > For an eventual deatticization 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 infrastructure team. > > Other than moving the repository to the "attic", these other > changes will be needed: > > • Deactivation of specific -dev or -users mailing lists; > • 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” (needs to be checked by TDF's team); > • Possibly disable relevant Ask/Discourse categories (needs to > be checked by TDF's team). > > ## Deatticization > > 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. > > ## Deatticization 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. "Considerations about the approval procedure for > atticization/deatticization"). > > If the vote turns out affirmative, the implementation part will be > handed over to the infrastructure team, which can, based on common sense: > > • Import the forked public repository; > > • Or move the repository from the attic to Gerrit altogether, and apply the > needed corrections. > > If needed, a new mailing list, along with 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* > provided for this code any more. > > --- > > ## 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 > (all of which need to be fulfilled): > * modified code is present in a publicly available Git repository > * modified code is released with a free/open source license > * at least {1|3|6} 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 three months > * modified code is actively advocated by its developers and at least a > member of TDF > > If the requirements are fulfilled and you can guarantee to continue to > develop the modified code, please get in touch with TDF's ESC and > Board of Directors. > > The full procedure is 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
