Date: prev next · Thread: first prev next last
2022 Archives by date, by thread · List index

Hi Thorsten, Emiliano, all,

thanks for the reminder Thorsten, as the discussion goes on in different areas of using this status of attic, my feedback is more on the procedural aspect of it.

It says, Quote:
" ...
## Atticization process
That proposal will have to be
voted on successfully by both the ESC and the Board of Directors.
## De-atticization procedure
If the vote turns out affirmative, the implementation part will be
handed over to Infra team, which can, based on common sense:
" End of Quote

Both sentences imply that the ESC have in praxis a blocking veto, independent of the decision by a board, for both procedures.
First of all let me ask, if this was intended and is a correct understanding or if I understood it wrong?

So, in case I understood it right, then
- in reflecting our Statutes and RoP and its construction of the foundation, that the "last" ruling body is the board in an appropriate case of conflict and if needed in supervision of the meritocratic organisation* - 
I would propose to add for a better understanding:

"The last and ruling decision for the Atticization or De-atticization of a project in TDF is certainly by the board. If it is in contradiction to a preliminary vote of the ESC, it should be at least heard by the board for its arguments and it should be reflected from the board with an answer why the decision of the board is not following the ESC vote. "

Or something like this. I am not sure if it is good to vote on it without clarification of this item in any case. What do you think?


* beside some very seldom things where the MC or at last the membership comes into the game, but here we are upon normal activities inside the foundation

Am 08.01.2022 um 17:50 schrieb Thorsten Behrens:
Dear board, dear TDF members, all,

this proposal has sparked interesting discussions, that we should
continue. For the proposal at hand though, we've not received much if
any actionable feedback.

So I'd like to call for a vote soon, unless there's concrete input for
edits. Let's give this two more days.

All the best, Thorsten

I wrote:
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:

## 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

## 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

• 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

• 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].



Lothar K. Becker, 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:

phone: +49 7202 9499 001 (c/o .riess applications gmbh)
-- To unsubscribe e-mail to: Problems? Posting guidelines + more: List archive: Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.