parent
a17d1aee36
commit
a7566256a9
GPG Key ID:
03789458B3D0C410
|
|
@ -0,0 +1,49 @@
|
|||
---
|
||||
title: "Resolution 020"
|
||||
---
|
||||
|
||||
- Topic: Federation member responsibilities
|
||||
- Date: ...
|
||||
- Deadline: ...
|
||||
- Size: Large
|
||||
|
||||
### Summary
|
||||
|
||||
Motivated by the last Federation meeting: [minutes](https://docs.coopcloud.tech/federation/minutes/2024-29-03/).
|
||||
|
||||
New members are joining the Federation, hurray! In the discussion about what it means to join, the question came up: what exactly are the responsibilities of the members? This was raised in [`#581`](https://git.coopcloud.tech/coop-cloud/organising/issues/581).
|
||||
|
||||
Responsibilities were defined in the original [Federation Proposal](https://pad.autonomic.zone/s/MLafJE2jC#Responsibilities). We would like to document and extend those in this proposal.
|
||||
|
||||
Furthermore, some existing members have not been participating, not paid dues/asked for waiver and some have even left the federation chat room. It would seem also time to define some "exit criteria" to keep a healthy balance.
|
||||
|
||||
### Details
|
||||
|
||||
#### Responsibilities
|
||||
|
||||
**Already agreed upon**
|
||||
|
||||
- Pay yearly dues or ask for waiver (if they can't afford it)
|
||||
- Actively participate in all large decisions
|
||||
- Agree to the [Code of Co-operation (CoC)](https://docs.coopcloud.tech/federation/code-of-coop/)
|
||||
|
||||
**New**
|
||||
|
||||
- Actively participate in monthly federation meetings. If they can't make it, updates will be sent by text.
|
||||
|
||||
#### Exit criteria
|
||||
|
||||
> The idea is not to eject people out the federation but to use these clear guidelines as a way to assess if participants should remain federation members. This applies to both sides as it is often unclear how to leave volunteer projects.
|
||||
|
||||
**New**
|
||||
|
||||
- Not paying dues / having an agreed waiver
|
||||
- Not actively participating in all large decisions
|
||||
- Not active in federation monthly meetings
|
||||
- Do not behave in accordance with the [CoC](https://docs.coopcloud.tech/federation/code-of-coop/)
|
||||
|
||||
#### Implementation
|
||||
|
||||
- These criteria + a link to the [Federation proposal](https://pad.autonomic.zone/s/MLafJE2jC) will be clearly linked on a new "Federation handbook" on docs.coopcloud.tech
|
||||
|
||||
- An agenda point will be put on the next federation meeting to chase up dues/waiver agreements and to agree on a collective process for checking on participation of members.
|
||||
|
|
@ -0,0 +1,74 @@
|
|||
---
|
||||
title: "Resolution 021"
|
||||
---
|
||||
|
||||
- Topic: Budget XXX: Flag handling in Abra
|
||||
- Date: ...
|
||||
- Deadline: ...
|
||||
- Size: Medium
|
||||
|
||||
### Summary
|
||||
|
||||
Motivated by the collective release planning: [`#583`](https://git.coopcloud.tech/coop-cloud/organising/issues/583) under "Argument Handling".
|
||||
|
||||
Due to a bug in the underlying library (`urfave/cli`) that Abra uses for command-line argument/flag handling, we have a bug in Abra which cannot be fixed without causing a breaking change. See [`#581`](https://git.coopcloud.tech/coop-cloud/organising/issues/581) for the ongoing discussion. This proposal is the TLDR; and proposal for the fix.
|
||||
|
||||
### Details (Budget XXX)
|
||||
|
||||
#### The problem
|
||||
|
||||
The current help output of `abra app deploy` is as follows:
|
||||
|
||||
`abra app deploy [command options] <domain> [<version>]`
|
||||
|
||||
However, it is possible to do both of the following:
|
||||
|
||||
```
|
||||
abra app deploy --chaos example.org # "before" style
|
||||
abra app deploy example.org --chaos # "after" style
|
||||
```
|
||||
|
||||
However, `abra app cmd` is broken if you try to use the "after" style:
|
||||
|
||||
```
|
||||
abra app cmd <domain> <function> --local -- <args>
|
||||
```
|
||||
|
||||
This results in `FATA[0000] <recipe> doesn't have a --local function` which is a bug in the `abra` code. It tries to read the position of the arguments but `--local` is included as an argument. The bug in `abra` is due to a bug in `urfave/cli` - "after" style options appear as arguments 😱
|
||||
|
||||
The only way to use `abra app cmd` right now is using the "before" style:
|
||||
|
||||
```
|
||||
abra app cmd --local <domain> <function> -- <args>
|
||||
```
|
||||
|
||||
This means that some commands allow both "after" and "before" style and some only allow "before" style. This is a source of confusion, raised issues and frustration.
|
||||
|
||||
#### Our solution
|
||||
|
||||
We propose to remedy this situation by upgrading `urfave/cli` to version 2 which enforces the "before" style. This was the solution from `urfave/cli` developers to fix their bug. You can then only do e.g.
|
||||
|
||||
```
|
||||
abra app deploy --chaos <domain>
|
||||
```
|
||||
|
||||
This is the "simplest" option in terms of development capacity and is the most cost effective option. The upgrade effort is more or less a known quantity, see [`#404`](https://git.coopcloud.tech/coop-cloud/abra/pulls/404) for more.
|
||||
|
||||
We have previously reverted from version 2 to version to 1 to maintain this flexibility. However, this leaves us with an unresolved bug which we want to close off.
|
||||
|
||||
#### Alternatives
|
||||
|
||||
If this restriction is seen as too burdensome, we see some alternatives.
|
||||
|
||||
If you choose to vote against this proposal, please include your preference for an alternative (below or with your own). This allows us to mount another proposal with minimal effort.
|
||||
|
||||
There is no guarantee we can get these right and it will incur an ongoing maintenance cost.
|
||||
|
||||
1. we make a special case hack in the case of the `--local` handling and proceed as usual
|
||||
1. we upgrade to v2 and include a patch which automatically re-orders "after" style options into the "before" style transparently
|
||||
|
||||
#### Budget
|
||||
|
||||
Compensate `@p4u1` for XXX hrs work to get this done. This includes XXX hrs
|
||||
backpay for the initial spike in
|
||||
[`#404`](https://git.coopcloud.tech/coop-cloud/abra/pulls/404).
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
---
|
||||
title: "Resolution 022"
|
||||
---
|
||||
|
||||
- Topic: Budget XXX: Abra integration suite automation
|
||||
- Date: ...
|
||||
- Deadline: ...
|
||||
- Size: Medium
|
||||
|
||||
### Summary
|
||||
|
||||
Motivated by the collective release planning: [`#583`](https://git.coopcloud.tech/coop-cloud/organising/issues/583) under "Automate Integration Test Suite".
|
||||
|
||||
The latest `abra` release (`0.9.x`) was heavily delayed due to several issues.
|
||||
One of those was the need to fix the integration test suite which wasn't run in
|
||||
some time. Many breakages had crept into the test suite over time. This can
|
||||
avoided in the future by automating the running of the integration test suite.
|
||||
|
||||
This proposal describes a way to do this and includes a budget for doing so.
|
||||
|
||||
### Details (Budget XXX)
|
||||
|
||||
The `abra` test suite takes around 1.30 hrs to run on a modest machine.
|
||||
Therefore, we propose to run it only once daily. Some parts of the tests are
|
||||
slow, fast and only a few require public DNS. This means we can break up the
|
||||
tests and run them in separate "builds" to speed things up. This involves some
|
||||
research & experimentation.
|
||||
|
||||
Also, we need a server to run the tests on. This machine should be wiped clean
|
||||
each day (`docker <command> prune ....`) and have the usual DNS machinery
|
||||
attached to it, e.g. `int.coopcloud.tech`, `*.int.coopcloud.tech`. Ideally some
|
||||
federation members will also be provided shell access with root permissions.
|
||||
|
||||
Once all this is wired up, we can implement the CI/CD configuration to make the
|
||||
test suite run automatically once a day. This will be triggered via the
|
||||
`.drone.yml` in the `abra` Git repository.
|
||||
|
||||
Budget details:
|
||||
|
||||
| Item | Cost | Who? |
|
||||
| ---- | ---- | ---- |
|
||||
| Server | ??? | ??? |
|
||||
| Server setup | 2 hrs | `@d1` |
|
||||
| R&D for breaking up tests | 5 hrs | `@d1` |
|
||||
| Implementing CI configs | 10 hrs | `@d1` |
|
||||
|
||||
**NOTE**: budget for server includes yearly costs of server and ongoing maintenance.
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
---
|
||||
title: "Resolution 023"
|
||||
---
|
||||
|
||||
- Topic: Budget XXX: Improved project organisation
|
||||
- Date: ...
|
||||
- Deadline: ...
|
||||
- Size: Large
|
||||
|
||||
### Summary
|
||||
|
||||
Motivated by the collective release planning: [`#583`](https://git.coopcloud.tech/coop-cloud/organising/issues/583) under "Improved Project Organisation".
|
||||
|
||||
Several issues, both social & technical in nature are cominmg up based on our chocies for how to organise our project management in Co-op Cloud. This proposal will present the problems and proposals for solutions.
|
||||
|
||||
### Details (Budget XXX)
|
||||
|
||||
#### The problems
|
||||
|
||||
1. Because recipes and "other" repositories are gathered under a single Gitea organisation, [co-op cloud](https://git.coopcloud.tech/coop-cloud), `abra` has to do some serious acrobatics to understand what is a recipe and what is not a recipe. More details in [`#377`](https://git.coopcloud.tech/coop-cloud/organising/issues/377). See also [`#569`](https://git.coopcloud.tech/coop-cloud/organising/issues/569).
|
||||
1. Several participants have complained that there is too much indirection & noise involved in having a single issue tracker, [organising](https://git.coopcloud.tech/coop-cloud/organising/issues). By noise, we mean that, e.g. there are several conventions (labels, writing "Abra: " / "Docs: ") in marking issues related to different repositories. By indirection, we mean that it is not always clear where the issue relates to.
|
||||
1. There is an old Federation related organisation and related repository, [Federation](https://git.coopcloud.tech/Federation) which has raised questions from new members. It is not used now but it is still there.
|
||||
|
||||
#### The solutions
|
||||
|
||||
For the recipes issue:
|
||||
|
||||
1. Rename [co-op cloud](https://git.coopcloud.tech/coop-cloud) to "Co-op Cloud Configuration Commons (CCCC)".
|
||||
1. Create a new Gitea organisation called "Co-op Cloud Federation (CCF)".
|
||||
1. Migrate all "non recipe" repositories away from [co-op cloud](https://git.coopcloud.tech/coop-cloud) ("CCCC") and under the CCF organisation.
|
||||
|
||||
This creates a clear separation between the configuration commons AKA "the recipes" and "other stuff". This means that `abra` logic can be greatly simplified and become performant once again. Furthermore, we don't break any URLs by keeping the recipes where they always were. The renaming aspect is purely cosmetic, the recipe organisation URL will remain "co-op cloud".
|
||||
|
||||
Then, for the issue management issue:
|
||||
|
||||
1. Re-open all repository issue trackers instead of pointing to [organising](https://git.coopcloud.tech/coop-cloud/organising/issues).
|
||||
1. Migrate all issues by hand from `organising` to their relevant issue trackers. E.g. all issues in organising with the `abra` label will go to the `abra` issue tracker.
|
||||
1. Create a new repository called "Co-op Cloud Federation Coordination" where we have an issue tracker for specific federation discussions (E.g. "tracking every member paying dues").
|
||||
1. Create a single Gitea Project under the CCF organisation called "Federation FTW".
|
||||
|
||||
"Federation FTW" will be the project we collectively refer to in our federation meetings as the "main list of priorities". Issues from every part of the project can be referenced there in a single place. Discussions can happen decentrally in their own issue trackers. It is the central source of truth for our current priorities and a way to stay up to date with what we want to do in the short to medium term.
|
||||
|
||||
#### Budget
|
||||
|
||||
* 5 hrs for migrating labours of the issues to their related issue trackers.
|
||||
* Additional 3 hrs for unseen migration / busy work gotchas.
|
||||
* 4 hrs for `abra` changes to only parse the new recipes repository
|
||||
* Total: 12 hrs
|
||||
Loading…
Reference in New Issue