Re: [board-discuss] [VOTE] Approve the attic proposal
Hi Paolo, Paolo Vecchi wrote: > Abstaining from voting on it as while the text could be a starting point it > seems to make it clear that whatever goes in the "attic" will never come out > of it as explained very well by Andreas Mantke: > > https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00373.html > I've just answered Andreas, and I believe he's not describing a real-world problem, for actual developers of the kind of code hosted at TDF. Andreas has used github before, with forked repos from TDF's main ones, and gihub issues for bug tracking. It really does not seem to be a barrier. > Before anything is put in the "attic" we should make an analysis of what we > are hosting, open repositories for 12 months (if they have been frozen) and > promote them to see if anyone starts contributing and then, after the 12 > months period has expired, evaluate if the repositories should be archived > for good. > We should look at each request to atticize on its own merits. The vote on the process has just passed (it's the ESC's and the board's job to propose projects). An aside: let's please continue the discussion with a separate subject if there's a need; but ideally as a new thread. the vote here has concluded. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [VOTE] Approve the attic proposal
Abstaining from voting on it as while the text could be a starting point it seems to make it clear that whatever goes in the "attic" will never come out of it as explained very well by Andreas Mantke: https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00373.html While the text has been written to take out of the way LOOL there have been no follow ups to requests to evaluate what else we are hosting which should or should not be put in the "attic". Before anything is put in the "attic" we should make an analysis of what we are hosting, open repositories for 12 months (if they have been frozen) and promote them to see if anyone starts contributing and then, after the 12 months period has expired, evaluate if the repositories should be archived for good. Ciao Paolo On 24/03/2022 00:20, Thorsten Behrens 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
Re: [board-discuss] [VOTE] Approve the attic proposal
Hi Thorsten, all, Am 24.03.22 um 22:59 schrieb Thorsten Behrens: Hi Andreas, all, Andreas Mantke wrote: Am 24.03.22 um 00:20 schrieb Thorsten Behrens: • 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”; I'm curious why there is not only push function is disabled but also pull function. Does this mean that there is no 'git clone' available too? That seems to be a misunderstanding. A "pull request" in git(hub) lingo means asking an upstream git project to merge a change. A readonly clone is going to be available for atticized projects. I summarize: for a attic project no git push and pull request are available, only git clone and git pull. Thus it is not possible to make a contribution or a potential contribution for such a project within TDF resources. The attic proposal expects for the de-attic process (extraction): • 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; • 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; Because it is not possible to make a pull request or to work on a branch of the attic project on TDF resources, the work on that project has to be done somewhere else. The developers which work on that project need to organize their work inside that new environment. They will already organize their workflow and communication channels. And thus the question pops up, why they should invest their (volunteer) work time to ask for moving the project onto TDF resources, change their workflow etc. and transfer everything onto TDF resources and under the hat and control of TDF. Thus if TDF moves a project to the attic a steel door is locked behind it with a lot of locks. It will be unlikely that such a project will get back to live inside the TDF environment. Regards, Andreas -- ## Free Software Advocate ## Plone add-on developer ## My blog: http://www.amantke.de/blog -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] Approve the attic proposal
Hi Andreas, all, Andreas Mantke wrote: > Am 24.03.22 um 00:20 schrieb Thorsten Behrens: > > • 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”; > > I'm curious why there is not only push function is disabled but also > pull function. Does this mean that there is no 'git clone' available too? > That seems to be a misunderstanding. A "pull request" in git(hub) lingo means asking an upstream git project to merge a change. A readonly clone is going to be available for atticized projects. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [VOTE] Approve the attic proposal
Hi, Thorsten Behrens wrote on 24/03/2022 00:20: calling for an email VOTE on the below final version of the Attic Proposal. The vote runs for 72 hours, starting now. Thanks to all involved in the discussion .. and +1 from me, Cor -- Cor Nouws, member Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28 A038 E49D 7365 B134 80A6 mobile : +31 (0)6 25 20 7001 skype : cornouws blog: cor4office-nl.blogspot.com jabber : cor4off...@jabber.org -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] Approve the attic proposal
Hi Andreas, Andreas Mantke píše v Čt 24. 03. 2022 v 21:24 +0100: > > • 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”; > > I'm curious why there is not only push function is disabled but also > pull function. Does this mean that there is no 'git clone' available > too? It is "pull request" as a term known originally from GitHub, not "pull", so "git clone" is supposed to be available; it would make no sense without that of course. GH explains "pull request" as: "Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch." All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] Approve the attic proposal
Jan Holesovsky píše v Čt 24. 03. 2022 v 20:07 +0100: > > calling for an email VOTE on the below final version of the Attic > > Proposal. The vote runs for 72 hours, starting now. > > Thank you for this effort, +1 from me. Oops, meant to +1 from this email address :-) [Sorry about that, I've mis-configured after a reinstall...] All the best, Kendy -- Jan Holešovský, Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] Approve the attic proposal
Hi all, Am 24.03.22 um 00:20 schrieb Thorsten Behrens: (...) • 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”; I'm curious why there is not only push function is disabled but also pull function. Does this mean that there is no 'git clone' available too? Regards, Andreas -- ## Free Software Advocate ## Plone add-on developer ## My blog: http://www.amantke.de/blog -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] Approve the attic proposal
Hi Thorsten & Emiliano, all, Thorsten Behrens píše v Čt 24. 03. 2022 v 00:20 +0100: > calling for an email VOTE on the below final version of the Attic > Proposal. The vote runs for 72 hours, starting now. Thank you for this effort, +1 from me. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] Approve the attic proposal
On Thu, 2022-03-24 at 00:20 +0100, Thorsten Behrens 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. +1 in favor. -- Caolán McNamara, Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] Approve the attic proposal
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
[board-discuss] [VOTE] Approve the attic proposal
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
