Re: [board-discuss] Draft text: an "attic" proposal - version 2.0
Hi Kendy, On 15/03/2022 10:45, Jan Holesovsky wrote: You really don't have to assure me. I started programming 35 years ago, I was there in the 80's and 90's, so I can compare with the present. If you were a professional developer 35 years ago? Then you have to tell me how you can look so young as I thought you were in your early 40. Maybe a small number of passionate and capable developers will be able to fix the CVEs and bring LOOL to a state where it could work well with the features left since the fork for those that don't need new fancy features. The most important "new fancy features" are in the area of making the editing more fluent, optimized & pleasant, do you really think there are people who don't need them? That is always nice but maybe other features are less important to many. The point is that we don't know until we open the repository and let people know that is available with all the relevant warnings. It is git, anybody can clone it & work on it if they want. If there were passionate and capable developers interested in this, they'd be bombarding the development mailing list with their patches the last >12 months; passionate and capable developers always find their way to get their code integrated one way or the other. But I'm not aware of any such patches. As people have been told that the project has been forked and LOOL has been frozen I guess that no one bothered sending patches to LOOL. Maybe if we announce that we will re open the repository, with the due warnings, we will see if some people are actually interested in contributing or not. All the best, Kendy Ciao Paolo -- Paolo Vecchi - 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 OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Draft text: an "attic" proposal - version 2.0
Hi, Thorsten Behrens wrote on 14/03/2022 21:20: Caolán McNamara wrote: I tend to agree. I don't think making it trivial to deattic something by applying a set of superficial commits to a very large code base which don't achieve meaningful change while f.e. unaddressed security issues mount up, creating a sort of zombie would be a good idea. Indeed, the proposal had a large project (like core or online) in mind. wrt the proposals exact number of devs and commits, I could imagine that on getting atticed a project is categorized into small, medium, large with 1, 3, 6 devs required to de-attic if there is genuine concern about the proposed bar being too high vs a new from scratch project. I like this idea. It nicely addresses the problem. Ah you already made an nice proposal on this matter, Caolán. Sorry I missed that early in the evening :) 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] Draft text: an "attic" proposal - version 2.0
Hi *, Caolán McNamara wrote: > I tend to agree. I don't think making it trivial to deattic something > by applying a set of superficial commits to a very large code base > which don't achieve meaningful change while f.e. unaddressed security > issues mount up, creating a sort of zombie would be a good idea. > Indeed, the proposal had a large project (like core or online) in mind. > wrt the proposals exact number of devs and commits, I could imagine > that on getting atticed a project is categorized into small, medium, > large with 1, 3, 6 devs required to de-attic if there is genuine > concern about the proposed bar being too high vs a new from scratch > project. > I like this idea. It nicely addresses the problem. The other option, at this stage (we're discussing a substantially unmodified proposal here since almost three months!), would be to first ratify the atticisation part of the text. Those bits have not received tangible input in a while, and we could finally get the online repo out of its undefined state. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Draft text: an "attic" proposal - version 2.0
Hi Jan, On 14/03/2022 19:43, Jan Holesovsky wrote: Hi Paolo, Paolo Vecchi píše v Po 14. 03. 2022 v 17:07 +0100: I have to agree with you that the process seems to be too cumbersome and it would very likely lead to the end of the project, so may as well delete it, or to forks that will never come back. Interestingly when I've read the de-atticization part of the attic proposal, I had the feeling it goes well with your proposal that when a commercial entity wants to contribute a project, they have to go through extra scrutiny? What has changed, please? Nothing has changed at all. As already explained also to Allotropia in regards to their WASM project I asked if they could officially present their project to TDF in a page or 2 where they also state what part of the project hosted at TDF will be made available for free to the community in full respect of our statutes and mission to lead by example and show that commercial contributors are very welcome, we don't want to complicate things but the relationship should be clear from the beginning to protect each others interests. That's the same thing that should have happened with LOOL to clarify what type of relationship was there between TDF and the commercial contributor but the commercial contributor decided to clarify it in its own way. As plenty of time has passed by since LOOL has been forked I would even propose to just re-open the repository and let the community decide if they are actually interested in contributing to it. With my developer hat on (ie. not Board, not Collabora), I'd like to point out that you should consider the implications of potential or real security issues. How do you want to force the community to fix those? [I mean, who will be the actual people actually fixing those?] What if the re-opened repo gets a CVE? A bit of a shame that LOOL's repository was blocked when we had a bug bounty going on as maybe it would have discovered other security issues but yes we are all aware that there are CVE present in there and it would be up to those that start working on it to look at them and fix them. We may discover that the community is actually interested in contributing to a LOOL which is unlikely to reach features parity with other similar products but that is good enough for some use cases where basic features and a lightweight component is needed. Still with my developer hat on, I think you underestimate the complexity of the Online editing problem; the programming was just completely different 25 years ago (I think you said you used to be a developer then?). I used to be a developer and stopped about 25 years ago as I fancied taking on new challenges. It's true that through the 80s and 90s software development was different but I can assure you that there were levels of complexity that aren't that different from today's systems and the tolerance for errors were probably a lot narrower. The problems that the Online has to sort out are complex; like extremely complex; like nobody-25-years-ago-could-imagine-how-much complex: Lots of asynchronous communication, performance implications (on many levels - in C++, in C++/JS combination, in JS, on the network), limitations of JavaScript, limitations of various browsers, and more. And solving these problems is painful, there are no good tools to debug the C++ / JavaScript combination, developers who love C++ hate JS & the other way around, etc. I bet there are quite a few older developers that would tell you that 25/30 years ago we could imagine those level of complexities as in substance nothing much has changed. I would go as far as saying that you have a lot more tools and information that we had back then and that it was probably much more difficult to handle communication and code optimisation, when we had to deal with X.25 networks, modems and a few MB of RAM, than it is now. So, yes, I do fully understand what you are talking about. In other words, from the development point of view, there is no "basic features and a lightweight component" possible for the approach that COOL / LOOL is using. Maybe a small number of passionate and capable developers will be able to fix the CVEs and bring LOOL to a state where it could work well with the features left since the fork for those that don't need new fancy features. The point is that we don't know until we open the repository and let people know that is available with all the relevant warnings. If no one will take on the challenge within 12 months then we will know that there is no even point to put it in an "attic". All the best, Kendy Ciao Paolo -- Paolo Vecchi - 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 OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Draft text: an "attic" proposal - version 2.0
hi Andreas, On 14.03.22 18:36, Andreas Mantke wrote: and with the proposal the Android Viewer had to be put the attic and wouldn't currently get the chance to get out of this state (because only one developer looking for it). that's a bad example: the Android Viewer is in the core.git repository. there is no practical way to "move it to the attic" - in the hypothetical case, i'm pretty sure it would be considered too much effort to disentangle a dead project from core.git and there would just be a commit that deletes the code, as has happened for multiple large pieces of obsolete code in the past (just this year i happily deleted 2 WebDAV UCPs). -- 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] Draft text: an "attic" proposal - version 2.0
Hi Paolo, Paolo Vecchi píše v Po 14. 03. 2022 v 17:07 +0100: > I have to agree with you that the process seems to be too cumbersome > and > it would very likely lead to the end of the project, so may as well > delete it, or to forks that will never come back. Interestingly when I've read the de-atticization part of the attic proposal, I had the feeling it goes well with your proposal that when a commercial entity wants to contribute a project, they have to go through extra scrutiny? What has changed, please? > > As plenty of time has passed by since LOOL has been forked I would > even > propose to just re-open the repository and let the community decide > if > they are actually interested in contributing to it. With my developer hat on (ie. not Board, not Collabora), I'd like to point out that you should consider the implications of potential or real security issues. How do you want to force the community to fix those? [I mean, who will be the actual people actually fixing those?] What if the re-opened repo gets a CVE? > We may discover that the community is actually interested in > contributing to a LOOL which is unlikely to reach features parity > with > other similar products but that is good enough for some use cases > where > basic features and a lightweight component is needed. Still with my developer hat on, I think you underestimate the complexity of the Online editing problem; the programming was just completely different 25 years ago (I think you said you used to be a developer then?). The problems that the Online has to sort out are complex; like extremely complex; like nobody-25-years-ago-could-imagine-how-much complex: Lots of asynchronous communication, performance implications (on many levels - in C++, in C++/JS combination, in JS, on the network), limitations of JavaScript, limitations of various browsers, and more. And solving these problems is painful, there are no good tools to debug the C++ / JavaScript combination, developers who love C++ hate JS & the other way around, etc. In other words, from the development point of view, there is no "basic features and a lightweight component" possible for the approach that COOL / LOOL is using. 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] Draft text: an "attic" proposal - version 2.0
Hi, Andreas Mantke wrote on 14/03/2022 18:36: and with the proposal the Android Viewer had to be put the attic and wouldn't currently get the chance to get out of this state (because only one developer looking for it). Fair point. One could think of a way that the activity/nr of devs asked, has a relation with the initial project/project from the past. Emiliano, Thorsten, what do you think? I created two projects for TDF infra in 2011 (and two further in 2012 and 2013). If you'd ask for the same commitment to start / run this so that's not the aim, as I explained. projects as for de-attic a project, this projects wouldn't have been supported / used by TDF. Cheers, 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] Draft text: an "attic" proposal - version 2.0
Hi Cor, all, Am 14.03.22 um 17:34 schrieb Cor Nouws: Hi Andras, Andreas Mantke wrote on 13/03/2022 16:12: the quintessence of he proposal would be that a project will at 99,9% or more wouldn't get out of the attic state inside the TDF resources. The barriers to de-attic a project and make it an active project inside TDF are much higher than setting up / starting a new project. That is true. On the other hand: is it reasonable to compare a new project with one that is in attic state? For a new project - and I think TDF will adopt projects all too swift - you create a stage so that there is a place to grow, prove oneself. When a project has been paused at some moment, that will not have been done without thinking, consideration, extra efforts to avoid etc. as well. So based on this, one not make conclusions on the current proposal by 'comparing' the cases. For me the clear demands in the proposal are to prevent a situation where projects restart without a good change on success, which is IMO quite relevant for TDF's good name. and with the proposal the Android Viewer had to be put the attic and wouldn't currently get the chance to get out of this state (because only one developer looking for it). I created two projects for TDF infra in 2011 (and two further in 2012 and 2013). If you'd ask for the same commitment to start / run this projects as for de-attic a project, this projects wouldn't have been supported / used by TDF. Thus I'm happy that never used TDF resources for the source code of my projects and could fork and further develop this projects without explicit permission of TDF. I don't think the attic proposal will help TDF to save it's reputation. It's a clear statement of setting further barriers to volunteer work. 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] Draft text: an "attic" proposal - version 2.0
On Mon, 2022-03-14 at 17:34 +0100, Cor Nouws wrote: > For me the clear demands in the proposal are to prevent a situation > where projects restart without a good change on success, which is IMO > quite relevant for TDF's good name. I tend to agree. I don't think making it trivial to deattic something by applying a set of superficial commits to a very large code base which don't achieve meaningful change while f.e. unaddressed security issues mount up, creating a sort of zombie would be a good idea. wrt the proposals exact number of devs and commits, I could imagine that on getting atticed a project is categorized into small, medium, large with 1, 3, 6 devs required to de-attic if there is genuine concern about the proposed bar being too high vs a new from scratch project. -- 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] Draft text: an "attic" proposal - version 2.0
Cor Nouws wrote on 14/03/2022 17:34: Hi Andras, Andreas Mantke wrote on 13/03/2022 16:12: the quintessence of he proposal would be that a project will at 99,9% or more wouldn't get out of the attic state inside the TDF resources. The barriers to de-attic a project and make it an active project inside TDF are much higher than setting up / starting a new project. That is true. On the other hand: is it reasonable to compare a new project with one that is in attic state? For a new project - and I think TDF will adopt projects all too swift - will _not_ - that should read of course. you create a stage so that there is a place to grow, prove oneself. When a project has been paused at some moment, that will not have been done without thinking, consideration, extra efforts to avoid etc. as well. So based on this, one not make conclusions on the current proposal by 'comparing' the cases. For me the clear demands in the proposal are to prevent a situation where projects restart without a good change on success, which is IMO quite relevant for TDF's good name. Cheers, 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] Draft text: an "attic" proposal - version 2.0
Hi Andras, Andreas Mantke wrote on 13/03/2022 16:12: the quintessence of he proposal would be that a project will at 99,9% or more wouldn't get out of the attic state inside the TDF resources. The barriers to de-attic a project and make it an active project inside TDF are much higher than setting up / starting a new project. That is true. On the other hand: is it reasonable to compare a new project with one that is in attic state? For a new project - and I think TDF will adopt projects all too swift - you create a stage so that there is a place to grow, prove oneself. When a project has been paused at some moment, that will not have been done without thinking, consideration, extra efforts to avoid etc. as well. So based on this, one not make conclusions on the current proposal by 'comparing' the cases. For me the clear demands in the proposal are to prevent a situation where projects restart without a good change on success, which is IMO quite relevant for TDF's good name. Cheers, 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] Draft text: an "attic" proposal - version 2.0
Hi Andreas, thanks for your feedback. I have to agree with you that the process seems to be too cumbersome and it would very likely lead to the end of the project, so may as well delete it, or to forks that will never come back. The point here is also to try to understand what the scope of the "attic" would be, apart from locking out LOOL as we haven't got a list of other projects that we could/should archive. During the first discussion the Android Viewer has been proposed for archival to then discover that mostly one developer (Michael Weghorn) is actually looking after it so we have a good example that some may take interest on a project if it's open for contributions. Probably before we decide to put a project in the "attic" it would be a great idea to understand which projects we are hosting and then decide what to do as the rules should be the same for all and we should avoid another LOOL situation without clear rules in place. As plenty of time has passed by since LOOL has been forked I would even propose to just re-open the repository and let the community decide if they are actually interested in contributing to it. We may discover that the community is actually interested in contributing to a LOOL which is unlikely to reach features parity with other similar products but that is good enough for some use cases where basic features and a lightweight component is needed. If a community starts forming around it then we could compile it and make it available with the relevant warning of not being commercially supported as it planned before it was forked. If within 12 months we see that there is no interest at all then we may as well tarball LOOL and make it available for download for historical reference. Ciao Paolo On 13/03/2022 16:12, Andreas Mantke wrote: Am 08.03.22 um 22:54 schrieb Emiliano Vavassori: Dear community members, Following the discussion on the first revision of the "Attic" proposal, posted here by Thorsten Behrens on December 17th, 2021, gathering the input we received from the community (thanks for the invaluable help provided by everyone who participated!) and as anticipated in the last Board meeting (yesterday, March 7th), Thorsten and I tried to condense the discussion in a new 2.0 version, which I post below for further discussion. Of course, we are available to further clarify the proposal, if needed, and we eagerly await for your input on this following version. the quintessence of he proposal would be that a project will at 99,9% or more wouldn't get out of the attic state inside the TDF resources. The barriers to de-attic a project and make it an active project inside TDF are much higher than setting up / starting a new project. You ask for at least 3 devs with a lot of very valuable commits to start the process. But in comparison with the hurdles to run a new project / idea inside TDF resources there is no balance. A lot of (software) projects starts and run with only one (or maybe two) developers. If you put the same burden on them they would never get a go from TDF. I think a lot of volunteer work for and around LibreOffice would have been running on TDF resources if you took this criteria as a basis. The proposal is the start to stop any (volunteer) initiative to revive of - temporarily - not actively developed / worked on projects. Everyone who wants to work on such a project from the attic needs to use resources outside of TDF and I expect the development will stay there (and will not moved to TDF resources later). Thus in my opinion it is contrary to TDF's mission. Regards, Andreas -- ## Free Software Advocate ## Plone add-on developer ## My blog: http://www.amantke.de/blog -- Paolo Vecchi - 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 OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Draft text: an "attic" proposal - version 2.0
Am 08.03.22 um 22:54 schrieb Emiliano Vavassori: Dear community members, Following the discussion on the first revision of the "Attic" proposal, posted here by Thorsten Behrens on December 17th, 2021, gathering the input we received from the community (thanks for the invaluable help provided by everyone who participated!) and as anticipated in the last Board meeting (yesterday, March 7th), Thorsten and I tried to condense the discussion in a new 2.0 version, which I post below for further discussion. Of course, we are available to further clarify the proposal, if needed, and we eagerly await for your input on this following version. the quintessence of he proposal would be that a project will at 99,9% or more wouldn't get out of the attic state inside the TDF resources. The barriers to de-attic a project and make it an active project inside TDF are much higher than setting up / starting a new project. You ask for at least 3 devs with a lot of very valuable commits to start the process. But in comparison with the hurdles to run a new project / idea inside TDF resources there is no balance. A lot of (software) projects starts and run with only one (or maybe two) developers. If you put the same burden on them they would never get a go from TDF. I think a lot of volunteer work for and around LibreOffice would have been running on TDF resources if you took this criteria as a basis. The proposal is the start to stop any (volunteer) initiative to revive of - temporarily - not actively developed / worked on projects. Everyone who wants to work on such a project from the attic needs to use resources outside of TDF and I expect the development will stay there (and will not moved to TDF resources later). Thus in my opinion it is contrary to TDF's mission. 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] Draft text: an "attic" proposal - version 2.0
Hi Emiliano, On 08/03/2022 22:54, Emiliano Vavassori wrote: Of course, we are available to further clarify the proposal, if needed, and we eagerly await for your input on this following version. Proposal seems reasonable. This “attic” space will have, at minimum, the following characteristics: All sounds fine. ## 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; • 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; It would help to have another bullet here: * These active developers should all support its de-atticization. I think this was implicit, but lets make it explicit =) The following text is proposed to be included in the README of any atticized repository: Should be included in the README too I think. Otherwise, seems reasonable. ATB, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
[board-discuss] Draft text: an "attic" proposal - version 2.0
Dear community members, Following the discussion on the first revision of the "Attic" proposal, posted here by Thorsten Behrens on December 17th, 2021, gathering the input we received from the community (thanks for the invaluable help provided by everyone who participated!) and as anticipated in the last Board meeting (yesterday, March 7th), Thorsten and I tried to condense the discussion in a new 2.0 version, which I post below for further discussion. Of course, we are available to further clarify the proposal, if needed, and we eagerly await for your input on this following version. -%<-- ## 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
