NGI Assure call deadline 01/08/2022

Subject: Acknowledgement of your proposal Friendly Forge Format (F3): an Open Standard for secure communication between software forges

Dear Loïc,

this mail serves to acknowledge receipt of your grant application “Friendly Forge Format (F3): an Open Standard for secure communication between software forges” (2022-08-025). The project will be carefully reviewed for eligibility in two rounds following the criteria set out here:

https://nlnet.nl/assure/eligibility/

We expect the first round to take about five weeks, but given natural variation in the amount of projects and their complexity it may take longer or shorter. When the first round of review is done, we will inform you whether or not your project will be selected to enter the second round of the August 2022 call. Meanwhile, keep up the good work - and why not check out some of the wonderful projects already funded by NLnet Foundation:

https://nlnet.nl/project/current.html

Or have a look at how you can help out with reducing the impact of software patents on the FOSS ecosystem:

https://nlnet.nl/help

Kind regards,
on behalf of NLnet foundation,

[redacted]
Strategy Director
[redacted]


Support NLnet, the open internet and open source with just 5 minutes
of your time. Make a difference today.

Received today.


Subject: Your project Friendly Forge Format (F3): an Open Standard for secure communication between software forges has been selected for the second round

Dear Loïc,

it is my pleasure to inform you that your project “Friendly Forge Format (F3): an Open Standard for secure communication between software forges” (2022-08-025) has been selected to enter the second round of the August 2022 call. While the first round is solely based on your proposal, this strict selection round is potentially interactive. As your project is looked into in more depth, the reviewers may need some additional information to properly assess your application, in which case they will contact you.

Note that proposals are reviewed with regards to urgency, relevance and value for money. Unfortunately we will not be able to fund all projects proposed, as much as we would like that. For the next three weeks we will be therefore be thoroughly evaluating the remaining proposals for the second round, during which we may ask you to supply additional details. After that we will inform you on the outcome of this second (and final) selection round.

If you meanwhile have any questions, please let us know.


To which I replied:

Hi [redacted],

Thanks for the good news! I stand ready to answer any questions.

Cheers

Received today:


Dear Loïc,

you applied to the 2022-08 open call from NLnet. We have some questions
regarding your project proposal Friendly Forge Format (F3): an Open
Standard for secure communication between software forges.

Could you provide a breakdown of the main tasks, and the associated
effort?
The role and associated feature set of forges are continuously evolving.
Vendors continue to increase their features, for instance integration of
donation buttons, license compliance support, CMS and wiki functionality
etc. Where do you draw the line (and by what criteria), and stop
implementing additional features? How do you see the life cycle/future
maintenance of the specification? Have you considered engaging with a
standards body, e.g. OASIS?
Projects that are currently autonomous could be hesitant to switch away
from their existing internal abstractions, serialisations and on disk
file formats - unless their developers have 100R0confidence that
services are not disrupted by migration and users are guaranteed to not
lose information. How realistic do you consider it that others can
natively adopt an externally defined file format as-is in their
applications, or even spend time looking into such a possibility -
unless they are involved early in the definition of the format?
To what extend can F3 be an archiving format? How good is the expected
feature coverage of the spec when looking at the whole spectrum of
version control systems (e.g. Fossil, Sourcehut, Gitolite, Pagure,
Pijul, etc) and proprietary services like Github? Is the idea for the
spec to be a superset of all (theoretically) possible features of all
solutions available in todays solutions, or an opinionated subset of
that?
Today’s forges also still lack quite some features. Will you for
instance also integrate software translations, which are now often
outsourced to external translation tools like Weblate? Will you handle
groups, access control/rights, key management/signing etc? Is the spec
extensible to cover whatever a project needs?

Thank you very much for your timely reply.

A followup question on my part:


From: loic@dachary.org

Hi [redacted],

I’m in the process of answering the questions and I’m not sure I understand the following sentence:

Projects that are currently autonomous could be hesitant to switch away from their existing internal abstractions, serialisations and on disk file formats

What do you mean exactly by “projects that are currently autonomous”? An example would be enough to clarify.

Thanks!


Got a reply within the hour.


Hi Loïc,

Projects that are currently autonomous could be hesitant to switch away from their existing internal abstractions, serialisations and on disk file formats

What do you mean exactly by “projects that are currently autonomous”? An example would be enough to clarify.

an external spec gives guidance, but it also is a corset that enforces certain aspects.

If the developers of some forge software want to change how it works (because they for instance are doing refactoring, and are running into performance issues with something that is part of the spec but which they don’t particularly care about for their use cases), they can do so without having to ask anyone for permission - and without external effects. They only have to deal with their own legacy migration, which is often quite simple if there is versioning of the data.

Once you start using some external specification, and external parties using other applications start interfacing with you - you more or less are forced to maintain compliance with that specification from now on. One lock oneself to the fate of the spec, and has to ‘obey’ whatever happens. This means you are no longer autonomous in that sense.

Does that clarify?

Best,


To which I replied:


It does, perfectly. Thanks!

Discussion with Nathanael regarding the questions (in French) and how to answer them.

Reply sent September 21st, 2022.


Hi [redacted],

Establishing an Open Standard that can be trusted by software forge implementors and users is a formidable undertaking that will require years of work. The goal in the context of this funding is to create a sound ground to bootstrap this effort, which includes:

  • a lifecycle relying on both paid work and crowdsourcing
  • a scope defined and implemented by all stakeholders
  • an adoption based on incremental inclusion in software forges

In practice, the following lines of work are required to achieve this first iteration:

  • Publish and improve the F3 specifications
  • Conduct User Research to identify the needs of forge users, forge implementors and forge maintainers and focus on what matters most to them
  • Publish and develop a reference implementation of the F3 specifications
  • Create a roadmap and a lifecycle for the next iteration of the F3 specifications and reference implementation
  • Establish a dialog with all stake holders to create a consensus on F3
  • Setup an environment favorable to crowdsourcing the specifications and the reference implementation

The detailed answers to your questions can be found below, as well as a high level workplan. Please let me know if something is unclear or raises a concern.

Cheers

Scope

The role and associated feature set of forges are continuously evolving. Vendors continue to increase their features, for instance integration of donation buttons, license compliance support, CMS and wiki functionality etc. Where do you draw the line (and by what criteria), and stop implementing additional features?

In this first iteration of F3, the line is drawn by the limited resources available.

User research conducted in 2021 identified that “issues” are the most pressing need, therefore it is included. The following are also included because they are essential to Gitea, which is the primary community targeted by F3, and adoption would be unlikely if they were not: user, project, label, milestone, topic, release, asset, pull_request, repository, comment, reaction, review.

This feature set will have to expand during the next iterations of F3 to include more features. It will happen, as a result of a dialog between the implementors of the specification and the stakeholders. There will always be a tension between desirable features and the effort required to implement and maintain them. But F3 must always be a living specification.

To what extend can F3 be an archiving format? How good is the expected feature coverage of the spec when looking at the whole spectrum of version control systems (e.g. Fossil, Sourcehut, Gitolite, Pagure, Pijul, etc) and proprietary services like Github? Is the idea for the spec to be a superset of all (theoretically) possible features of all solutions available in todays solutions, or an opinionated subset of that?

Although it may be ambitious to claim that F3 is suitable for archiving a software project at this point in time, the reality is that there is no other format that even tries to do the same. GitLab import/export format is undocumented and unsuitable for archival, the same is true of GitHub etc. However imperfect F3 may be for archival it is the best there is. Since the work on F3 is based on a bottom up approach, it is effectively an opinionated subset of the existing features. Which will expand over time when the feature set expands.

At some point, when F3 becomes mature enough, forge implementors will have a motivation to ensure there is a parity between the features they provide and the features F3 can represent. It will be a condition for them to be able to import/mirror software projects originating from other forges. It will take time to get there but it is also the best way for F3 to achieve a healthy lifecycle.

Today’s forges also still lack quite some features. Will you for instance also integrate software translations, which are now often outsourced to external translation tools like Weblate? Will you handle groups, access control/rights, key management/signing etc? Is the spec extensible to cover whatever a project needs?

The coding.social social movement that emerged last year aims at identifying all domains involved in the lifecycle of a Free Software. All of them, including translations, are potentially in scope for inclusion in F3. It is likely that domains identified during dialog in coding.social will lead to proposals to modify the scope of F3.

Lifecycle

How do you see the life cycle/future maintenance of the specification?

F3 is going to be defined by an iterative process based on the following:

  • A feature is identified and defined during informal discussions with stakeholders. It could be within coding.social or because it emerges in some major forges, etc.
  • User Research is conducted and the report concludes the stakeholders (forge users, implementors, operators) value this feature
  • The F3 specifications and reference implementations are modified to include that feature
  • A version of F3 is released

It is very similar to the life cycle of a software. Although the feature set of F3 may change less frequently over time, creating Free Software is essentially a social process and the odds are it will keep being a living specification for the foreseeable future.

Have you considered engaging with a standards body, e.g. OASIS?

Standard bodies are unfamiliar to everyone involved in F3, reason why it is not included in this iteration. It is however the logical context in which to develop a standard and the best efforts will be made to apply and learn about the work it implies.

Adoption

Projects that are currently autonomous could be hesitant to switch away from their existing internal abstractions, serialisations and on disk file formats - unless their developers have 100R0confidence that services are not disrupted by migration and users are guaranteed to not lose information. How realistic do you consider it that others can natively adopt an externally defined file format as-is in their applications, or even spend time looking into such a possibility - unless they are involved early in the definition of the format?

Since F3 emerged from the Gitea internal import/export format, the idea that F3 immeiately becomes a substitute was considered. But that involves significant internal infrastructure changes that are challenging. Even though the feature set of F3 is an exact match with the feature set of the internal import/export.

Instead, it was decided to add support for F3, as an alternate format for import/export which is also capable of mirroring (an important feature for forge federation). The downside of this approach could be work redundancy: the existing import/export needs to be maintained while users gain confidence that F3 is stable enough to match their needs. However, the current codebase is not being worked on actively and there is no indication that it will be within the year to come. Therefore there will be very little redundant work and the hope is that this approach will allow F3 to mature within the Gitea codebase. It will then become the most popular export/import module and replace the old one.

While this strategy may work for Gitea, a different one will have to be defined for Sourcehut, GitLab, Pagure, Fossil etc. Realistically each forge will require an ad-hoc strategy if F3 is to be adopted. From a technical standpoint having Go reference implementation is an asset: it can be used as a binary library in other programming languages. For instance, in order for Pagure to use F3 a python module linked with the Go F3 library can be implemented. Even though this is work, it is an order of magnitude simpler than rewriting the entire F3 implementation from scratch, down to the last detail and the last border case.

To summarize the strategy for adoption is based on:

  • Initial inclusion as an optional import/export format capable of mirroring, with links to federation
  • Availability of a reference implementation in Go to be reused by all languages

And there also is the expected amount of advocacy, code glue and dialog with forge implementors.

Main tasks breakdown

Could you provide a breakdown of the main tasks, and the associated effort?

Here are the main tasks, which can be further subdivided per-feature (assets, issue, pull request, etc.) into a detailed workplan with associated work efforts.

Specification and documentation

The F3 Specification includes:

  • An introduction
  • A guide to concepts
  • JSON Schema with embedded documentation
  • Release notes
  • A normative file hierarchy
  • A glossary of terms and their definition

Milestones:

  • JSON Schema for F3 are published a dedicated repositories
  • A formatted online version of the documentation

Monthly reports and videoconferences

Stakeholders (forge users, implementors and operators) are invited to monthly videoconferences to express their needs and keep up to date with the development of F3. The outcome of this dialog is expected to be included in the User Research report and define the next iteration of the F3 specifications.

Milestones:

  • A report with detailed description of the work done over the past month
  • A recording of the videoconference

Documentation of the F3 lifecycle

  • Guide for newcomers
  • Roadmap
  • Low hanging fruits
  • Reference for specification developers

Milestones:

  • A repository with the documentation
  • A formatted online version of the documentation

First release

The first F3 release is a bundle that includes:

  • The specifications and documentation
  • The Go reference implementation

They are verified to be consistent and tagged with the same version number.

Milestone: simultaneous publication of F3 version 1.0.0 at:

Go package reference implementation

A reference implementation of F3 in Go provides:

  • An API for integration in a forge written in Go
  • Validation of a F3 archive (JSON Schema validation, etc.)
  • Import and Export support for Gitea and GitLab
  • Dataset generators and fixtures to verify the conformance with the specifications

Milestone: The Go package is published https://pkg.go.dev/

Integration in the Gitea codebase

The F3 Go reference implementation is used as an alternative for the internal format used for repositories dump and restore features in the Gitea codebase.

Milestones: pull request merged in https://forgefriends.org or https://gitea.io

User Research

User Research involving forge implementors, forge users and forge operators to determine which feature are most important for them to develop during the next iteration of the F3 specification.

Milestones:

  • A User Research report including three emerging themes

Received today. As instructed I won’t discuss it outside of this topic: this is one step forward, which is good news indeed. But this is not final and some administrative steps are required and it is entirely possible that there is a blocker.


From: nlnet
Subject: Good news about your proposal to NLnet

Dear Loïc,

you applied to the NGI Assure open call from NLnet, round August 2022. Currently a selection of the projects is pending the final stage review by an independent review committee to validate their eligibility, and we are happy to inform you that this includes your project “Friendly Forge Format (F3): an Open Standard for secure communication between software forges” (2022-08-025). Should your project pass that final hurdle (which under normal circumstances it should, but please do not seek external publicity until it is officially confirmed), the selection will be made public and we will contact you for some checks and subsequent negotiation of a Memorandum of Understanding. The final amount of the grant will be determined at that point.

We will then also need to share some information about the project both with the general audience and with the European Commission. In the interest of time, we ask you to prepare a one paragraph management summary of the project. For examples we refer you to NLnet; NGI Assure

We kind request you to send us this summary as soon as possible.

If you meanwhile have any questions, please let us know.

Kind regards,
on behalf of NLnet foundation,


From: loic@dachary.org
To: nlnet
Subject: Re: Good news about your proposal to NLnet

Hi [redacted],

Thanks for the good news :slight_smile: Here is the one paragraph management summary, just in case all goes well:

The Friendly Forge Format (abbreviated F3) is an Open File Format for storing the information from a forge such as issues, pull/merge requests, milestones, release assets, etc. as well as the associated VCS (Git, Mercurial, etc.). F3 is designed to exchange the state of a software project between GitHub, GitLab, Gitea, etc. for backup, mirroring or federation. F3 is essential for a forge to provide key requirements. (i) Portability: the entire state of a software project can be dumped and restored at a later time, on a different development environment (ii) Versatility: when published and updated as a F3 archive, a software project effectively is Open Data on which an unlimited range of applications can rely, even outside of the forge domain (iii) Consistency: it provides a common language to use when talking about the forge related domains (iv) Trust: cryptographic signatures on each F3 dump guard against malicious or unintentional tampering that could compromise the integrity of a software project.

I keep my fingers crossed and hope there won’t be unexpected problems!

Cheers


From: nlnet
Subject: Re: Good news about your proposal to NLnet

Hi Loïc,

Thanks for the good news :slight_smile: Here is the one paragraph management summary, just in case all goes well:

thank you very much for the summary, much appreciated.

We will keep you posted on the outcome of the external review committee.

Meanwhile, take care and bon appetit!
Best,

Here is a draft workplan to be prepared in case the grant is accepted. See this topic for a detailed explanation of how it is structured.

2023-f3-nlnet-assure-workplan.ods (30.2 KB)

Given the recent code contributions of @earl-warren to the Go F3 codebase, I think it would make sense to add him as a beneficiary to the grant, when and if it is approved.

I am willing to work on tasks as laid out in the workplan above if given the opportunity.

Sent today:


From: loic
Subject: Re: Good news about your proposal to NLnet

Hi [redacted],

A gentle ping to make sure I did not miss anything. I have not received news since the mail from you dated October 12. I’m not in a rush, just checking.

Cheers


From: NLnet
Subject: Re: Good news about your proposal to NLnet

We got your email and will get back to you asap! Sorry for the delay, we are very busy rounding up two previous grant programmes, which finish today.

— [redacted], NLnet

I’ve been told verbally that the external review is still in progress.

Mail sent today.


Hi [redacted],

And happy new year :slight_smile: It’s been a while now and I hope I did overlook a mail from you. How is the external review going?

Cheers


Received a reply the same day:

Hi Loïc,

And happy new year :slight_smile: It’s been a while now and I hope I did overlook a mail from you. How is the external review going?

[redacted]. I’ll try to give it a new swirl, and will
get back to you hopefully next week with a decision - left or right. You
need to be able to move on.

Have a great 2023!

Best,


Replied the same day

Thanks for the quick reply. To be perfectly candid it would be a great relief if this grant application was agreed on.

As you may know, the birth of https://forgejo.org project was very demanding over the past three months. It will be the cornerstone of my work on F3 and I’m more optimistic than ever on the outcome. What I need now is a few months of quiet time to do the technical work that F3 deserves to become useful.

That being said, even if there is no grant I won’t give up. It will be more difficult sure, but it won’t be the end. Just so you know that, whatever the outcome is, I appreciate your continued support over the past years, including the time you spent on reviewing this proposal and monitoring its progress.

Received today


Hi Loïc,

it has taken a while but we finally were able to resolve the issues raised by the external reviewers! The final conditions set by them are as follows:

"Standardising based on too limited an overview of the field can cause long term sustainability issues, and harm innovation. Project 2022-08-025 (Friendly Forge Format/F3) should make a thorough comparative analysis of solutions prior to standardising, along the approach of timesheets/apps-list.md at main · federatedbookkeeping/timesheets · GitHub

The project should build in adequate feedback from and collaboration with other forge maintainers, and recommend these request support from NLnet if necessary to have enough team resources to adequately participate in the process."

All in all, that seems quite doable. Do you think this is feasible? If so, we can move ahead…

[redacted]

Best,


Replied sent today:


Hi,

This is excellent news and I agree to the final conditions. Not only is it doable, it also makes perfect sense. F3 has matured in the past six months and it is in line with how it is being developed.

Cheers


Reply from NLnet received the same day.


Hi Loïc,

This is excellent news and I agree to the final conditions. Not only is it doable, it also makes perfect sense. F3 has matured in the past six months and it is in line with how it is being developed.

wonderful. In that case, please find the draft MoU attached.

You know how it works, we need to add the plan. Will you add other people to this MoU? Will you execute as Easter Eggs, or as individual? In that case, I need to send a slightly different variant.

Best,


My answer to NLnet. The draft MoU is not published here because it contains private data. The final MoU will be published with the private data redacted.


Hi,

Thanks for the quick turnaround. I’ll execute as an employee of Easter-Eggs will send you the draft workplan this week. The draft MoU looks good as it is.

Cheers

Sent today to NLnet


Hi,

Please find the draft workplan at Project Plan: Friendly Forge Format (F3) - HedgeDoc

Let me know if it should be modified or explained further, I’d be happy to do that and include it in the MoU if it meets your approval.

Cheers

Project Plan Friendly Forge Format (F3).md (4.3 KB)

Sent today to NLnet


Hi,

A gentle ping in case this message was overlooked.

Cheers

Recevied from NLnet today


Hi Loïc, aplogies for the delay. [redacted] has been swamped by work so I’ll have a look at this now. I hope I don’t ask stupid questions that you had already cleared with [redacted], but reading the plan, the following questions&thoughts came up:

  • Could you help us understand the plan better by adding a sentence or two to the tasks? The section “Specifications Tooling” has a nice explanation, but e.g. “Idempotency” leaves me guessing what the task’s context, scope and and purpose is.
  • In the first task: “as published in WikiData” → is wikidata reliable and up-to-date on software forge features? Or do you also expect to contribute data to wikidata here?
  • With downloading/uploading from/to “the API”, which API are we talking about? The API of a particular forge software?
  • In the proposal you write about the relation to ForgeFed, e.g.: “Improvements to the ForgeFed specifications will be proposed so that data contained in a F3 archive can be translated and sent over ActivityPub.” We don’t see this reflected in the plan, while it seems worthwhile to try find maximum convergence between the projects. Might it be worth trying to create shared schemas, (RDF) vocabulary, or clearly defined mappings? When I see both ForgeFed Modeling and Friendly Forge Format (F3) / F3 schemas · GitLab I wonder if we are not inventing two wheels here.
  • With the V1/“first release”, do you mean the release of both the spec&tooling?
  • What form will the tooling take? A command line tool that I can give a gitlab and gitea URL, and it will migrate my project? Or/and an integration (e.g. plugin/webhooks-based) in those forges in some form, to mirror a project to another forge? Or/and some web interface? Or…?
  • The compliance tests for Forgejo, Gitea, and GitLab; does that mean a test suite that creates actual instances of those forges with test data, exports and imports the data between them, and checks the results?
  • Is GitHub out of scope in this project?

Again apologies for the delay, and for the amount of questions. (: To start with, a few more sentences on each task, rather than just bullet points, may help answer most questions already!

Kind regards,

Reply sent to NLnet today


Hi,

URL of the WorkPlan: Project Plan: Friendly Forge Format (F3) - HedgeDoc

Thanks a lot for taking a close look, it is helpful and the questions are relevant. I’ll try to answer them as much as I can but do not hesitate to let me know if I fail to clarify.

  • Could you help us understand the plan better by adding a sentence or two to the tasks? The section “Specifications Tooling” has a nice explanation, but e.g. “Idempotency” leaves me guessing what the task’s context, scope and and purpose is.

My bad, it is indeed subject to multiple interpretations. I added the following:

The API or the internals of a forge are not usually designed to be idempotent. For instance deleting an issue that does not exist, either because it never did or because it was just deleted, will not succeed. However an implementation of F3 must be idempotent: uploading the same F3 archive twice must not lead to the creation of two different set of objects. For that to be possible the F3 format must ensure it contains all the information required for an implementation to be idempotent despite the lack of idempotency of the API or of the internals of the target forge.

  • In the first task: “as published in WikiData” → is wikidata reliable and up-to-date on software forge features? Or do you also expect to contribute data to wikidata here?

I added this, good point. I have spent month working on WikiData in the past and I know what it entails.

  • Update WikiData as needed if information is found missing

I was pleasantly surprised by the forge inventory that exist in WikiData and I’m not expecting it will need too much work. It is not perfect of course but the very important thing is that it is the one place where such an inventory can be maintained collaboratively.

  • With downloading/uploading from/to “the API”, which API are we talking about? The API of a particular forge software?

Yes. To clarify I added the following definition:

An API is a REST API published by a given forge. For instance Forgejo API for Forgejo or REST API | GitLab for GitLab.

  • In the proposal you write about the relation to ForgeFed, e.g.: “Improvements to the ForgeFed specifications will be proposed so that data contained in a F3 archive can be translated and sent over ActivityPub.” We don’t see this reflected in the plan, while it seems worthwhile to try find maximum convergence between the projects. Might it be worth trying to create shared schemas, (RDF) vocabulary, or clearly defined mappings? When I see both ForgeFed Modeling and Friendly Forge Format (F3) / F3 schemas · GitLab I wonder if we are not inventing two wheels here.

When the proposal was written the situation was quite different. Neither Anthony Wang nor fr33domlover were funded to work on ForgeFed. Today they both are and we’ve had discussions about how F3 fits with ForgeFed. In a nutshell it is a layer ForgeFed can rely on for its implementation and we are coordinating to unify the terms.

Here is a list of what F3 and ForgeFed share as of today.

Mapping

Only the fields that have a correspondence are represented here

Not yet represented in F3

Not in scope for F3

It is great that we have the mean and the will to work together and I fully expect this will continue to be the case during the duration of this grant. However, I cannot commit to a deliverable that would be specific enough to be included in the workplan, primarily because I can’t be sure where ForgeFed is going to be in six months from now.

  • With the V1/“first release”, do you mean the release of both the spec&tooling?

Yes. The general idea is that a release contains everything a third party would need to improve the specification on their own and verify it works as intended. I added the following:

A F3 release consists of the specifications, the compliance tests and the release tooling.

  • What form will the tooling take? A command line tool that I can give a gitlab and gitea URL, and it will migrate my project? Or/and an integration (e.g. plugin/webhooks-based) in those forges in some form, to mirror a project to another forge? Or/and some web interface? Or…?

The tooling is a set of CI pipelines. They will rely on scripts that could also be run independently but that is an internal detail. Someone willing to use the tools (compliance and release) will simply add them in a forge instance, trigger the CI to run them and wait for the result to show in the forge interface.

  • The compliance tests for Forgejo, Gitea, and GitLab; does that mean a test suite that creates actual instances of those forges with test data, exports and imports the data between them, and checks the results?

Exactly. I added the following to clarify.

Compliance testing is a fully automated CI pipeline that create a new forge instance for the duration of the test. Each test demonstrates a particular aspect of the F3 specification can actually be implemented for this particular version of the forge. For instance a test will spawn a Forgejo v1.18 instance, upload a new issue via the API from a compliant F3 issue, download it back using the API and verify the result is a well formed comparable F3 issue.

  • Is GitHub out of scope in this project?

It is not: it will be included in the inventory/comparison. But being proprietary it would be too difficult to include it in the implementation of the tooling and tests in the context of this grant. However, since both Forgejo and Gitea implement a REST API similar to GitHub, it will partly be covered.

Sincerely

Project Plan Friendly Forge Format (F3).md (5.9 KB)

Received from NLnet today (not attaching the MoU as it contains private data, it will be redacted and published when final).


Hi Loïc,

Thanks still for the answers.

I cast your plan into our format (molding it a bit as we lack sub-subheadings etc.), and forged an MoU for you.

It is implied (in the ‘compliance testing’ task description), but not explicit, that you make each tooling feature work for (at least) Gitea/Forgejo and Gitlab. Correct? I added this line in the intro about tooling (which moved into the plan intro):

Each feature of the F3 tooling will work with Gitea, Forgejo, and Gitlab (to the extent each has the required features).

In the code and documentation it will probably be helpful to be explicit about which versions of which forges the tool works with.

I also added descriptions to the tasks about down/uploading using internals, basing on your explanation. With internals, do you mean reading directly from the database, or using a (command-line) data export tool provided by the forge? (asking just for curiosity; it’s similar enough, and fine to leave it open in the task description.)

Please check if everything looks right, and if so add (a scan of) your signature. Then we’ll do the same and we are (officially) started. :slight_smile: (but also feel free to come back with further questions/suggestions)


Sent the following reply:


Hi,

Hi Loïc,

Thanks still for the answers.

I cast your plan into our format (molding it a bit as we lack sub-subheadings etc.), and forged an MoU for you.

It is implied (in the ‘compliance testing’ task description), but not explicit, that you make each tooling feature work for (at least) Gitea/Forgejo and Gitlab. Correct? I added this line in the intro about tooling (which moved into the plan intro):

Each feature of the F3 tooling will work with Gitea, Forgejo, and Gitlab (to the extent each has the required features).

This is correct, thanks for adding this.

In the code and documentation it will probably be helpful to be explicit about which versions of which forges the tool works with.

The test pipelines will be pinned to specific versions of forges.

I also added descriptions to the tasks about down/uploading using internals, basing on your explanation. With internals, do you mean reading directly from the database, or using a (command-line) data export tool provided by the forge? (asking just for curiosity; it’s similar enough, and fine to leave it open in the task description.)
It could be reading directly from the database, but it is unlikely to be the case. The more general case is using function calls that are in the forge codebase but which are not exposed via a publicly available API. Either because the API endpoint is missing entirely. Or because the API endpoint does not accept some parameters (such as forcing the creation date of something).

Please check if everything looks right, and if so add (a scan of) your signature. Then we’ll do the same and we are (officially) started. :slight_smile: (but also feel free to come back with further questions/suggestions)
Everything is correct. I’m grateful for the effort you made to format this into the MoU: it is a tedious task.

I fixed a few minor typos and attached the modified document with revisions shown so you can quickly verify them.

I attach the signed MoU and I look forward to getting started as soon as possible.

Cheers

Received the signed Memoradum of Understanding today, anonymized and attached here. The amounts were also redacted as per NLnet request.

2022-08-025-MoU-Loïc Dachary-Friendly Forge Format (F3)-anonymous.odt (109.5 KB)

1 Like