wip: docs: march resolutions #256

decentral1se · 2024-03-30T11:48:03Z

decentral1se commented

2024-03-30 11:48:03 +00:00

Feedback is most welcome! I'm putting these our for feedback now.

I will unleash them one by one in some $order of priority not to overwhelm.

See https://git.coopcloud.tech/coop-cloud/organising/issues/583. Feedback is most welcome! I'm putting these our for feedback now. I will unleash them one by one in some `$order` of priority not to overwhelm.

decentral1se added 1 commit 2024-03-30 11:48:03 +00:00

a7566256a9

wip: docs: march resolutions

See coop-cloud/organising#583

p4u1 added 1 commit 2024-03-30 12:23:30 +00:00

4f767420fb add hours

basebuilder commented

2024-04-02 21:00:16 +00:00

Resolution 020

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.

I like the concept of having three states of membership:

Active - doing member duties, all good
Atrophying - not meeting duties, after period of X one is auto-exited. Allows for course-correction
Exited - listed as honorable past member, but must they must re-apply

Resolution 021, 022

No comment. Too far out of my element 😄

Resolution 023

Great plan. I would vote in favor of it. My only changes are about naming of Gitea orgs. I propose:

git.coopcloud.org/recipes - currently coop-cloud
git.coopcloud.org/tools - for abra and any other original software..
git.coopcloud.org/federation - non-recipe, non tools repos like sites, etc...

These org names are discreet, totally explanatory, terse, and non-jargony

`Resolution 020` > 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. I like the concept of having three states of membership: - `Active` - doing member duties, all good - `Atrophying` - not meeting duties, after period of X one is auto-exited. Allows for course-correction - `Exited` - listed as honorable past member, but must they must re-apply `Resolution 021, 022` No comment. Too far out of my element 😄 `Resolution 023` Great plan. I would vote in favor of it. My only changes are about naming of Gitea orgs. I propose: - `git.coopcloud.org/recipes` - currently `coop-cloud` - `git.coopcloud.org/tools` - for `abra` and any other original software.. - `git.coopcloud.org/federation` - non-recipe, non tools repos like sites, etc... These org names are discreet, totally explanatory, terse, and non-jargony

❤️ 1

decentral1se reviewed 2024-04-02 22:26:33 +00:00

docs/federation/resolutions/drafts/021.md Outdated

						
				@ -0,0 +64,4 @@

				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

decentral1se commented

2024-04-02 22:26:33 +00:00

This is seeming less feasible as a solution now that it also came to light that abra app cmd --user root <domain> app <command> is affected... where --user in the "after" style is not working also 😬

This is seeming less feasible as a solution now that it also came to light that `abra app cmd --user root <domain> app <command>` is affected... where `--user` in the "after" style is not working also 😬

3wordchant commented

2024-04-02 23:00:05 +00:00

@decentral1se to clarify (I'm still confused by the problem Nick was facing), do we understand that abra app cmd --user root <domain> app <command> works, but abra app cmd <domain> app <command> --user doesn't?

@decentral1se to clarify (I'm still confused by the problem Nick was facing), do we understand that `abra app cmd --user root <domain> app <command>` works, but `abra app cmd <domain> app <command> --user` doesn't?

decentral1se commented

2024-04-04 13:39:53 +00:00

@3wordchant yes, that is what I got from the issue. @nicksellen can you confirm?

My troubleshooting shows that it is the case:

# .abra/recipes/foodsoft/abra.sh.
foo() {
  echo "FOO: whoami: $(whoami)"
}

$ abra app cmd -C <domain> app foo --user root
FOO: whoami: nobody

$ abra app cmd -C --user root <domain> app foo 
FOO: whoami: root

@3wordchant yes, that is what I got from the issue. @nicksellen can you confirm? My troubleshooting shows that it is the case: ``` # .abra/recipes/foodsoft/abra.sh. foo() { echo "FOO: whoami: $(whoami)" } $ abra app cmd -C <domain> app foo --user root FOO: whoami: nobody $ abra app cmd -C --user root <domain> app foo FOO: whoami: root ```

decentral1se commented

2024-04-02 22:30:10 +00:00

git.coopcloud.org/recipes - currently coop-cloud

I'd be up for this. Sadly, we'd need to include some migration steps due to @3wordchant finding out that org renames break git remotes: coop-cloud/organising#377 (comment) luckily, running abra recipe fetch will grab all the recipes tho, so maybe not the worst outcome? Probably plenty of other breakages tho to consider...

> git.coopcloud.org/recipes - currently coop-cloud I'd be up for this. Sadly, we'd need to include some migration steps due to @3wordchant finding out that org renames break git remotes: https://git.coopcloud.tech/coop-cloud/organising/issues/377#issuecomment-15011 luckily, running `abra recipe fetch` will grab all the recipes tho, so maybe not the worst outcome? Probably **plenty** of other breakages tho to consider...

3wordchant referenced this pull request from coop-cloud/organising

2024-04-02 22:59:03 +00:00

Consider migrating Recipes to own Gitea organization #569

basebuilder commented

2024-04-03 05:40:08 +00:00

Sadly, we'd need to include some migration steps due to @3wordchant finding out that org renames break git remotes:

Wait, in your proposal you say

Rename co-op cloud to "Co-op Cloud Configuration Commons (CCCC)".

Which is also a rename. How is that less difficult for @3wordchant than renaming to recipes or am i misreading you?

> Sadly, we'd need to include some migration steps due to @3wordchant finding out that org renames break git remotes: Wait, in your proposal you say > 1. Rename [co-op cloud](https://git.coopcloud.tech/coop-cloud) to "Co-op Cloud Configuration Commons (CCCC)". Which is also a rename. How is that less difficult for @3wordchant than renaming to `recipes` or am i misreading you?

decentral1se commented

2024-04-04 08:54:38 +00:00

Which is also a rename.

Ah, I meant the "display name" rename vs. the URL rename. But the migrations plan is coming together tho so I think we could adapt this proposal: coop-cloud/organising#569 (comment). Feeling like we're ready for one audio call to thrash out final deets and then a re-write of this could get voted on. /cc @basebuilder @3wordchant

> Which is also a rename. Ah, I meant the "display name" rename vs. the URL rename. But the migrations plan is coming together tho so I think we could adapt this proposal: https://git.coopcloud.tech/coop-cloud/organising/issues/569#issuecomment-20302. Feeling like we're ready for one audio call to thrash out final deets and then a re-write of this could get voted on. /cc @basebuilder @3wordchant

decentral1se commented

2024-04-04 21:51:54 +00:00

OK things are coming together for 022 (test suite automation) and I'm gonna propose it proper 🎉

decentral1se force-pushed resolutions-march from 4f767420fb to 7de2547f10

2024-04-04 21:53:48 +00:00

Compare

3wordchant commented

2024-04-05 19:57:16 +00:00

RE 021 "Flag handling in abra", I think returning to requiring the "before" style for all commands would be a significant usability regression for all subcommands except cmd.

To adapt urfave/cli#1113 to the abra context, the "before" style requires extra keystrokes every time we're adding or removing an option, for disambiguation that seems unnecessary ("after" options have no other meaning, except for cmd).

And, to expand on #284, most of the ~8people who I collaborated with on Co-op Cloud deployments when "before" style was required regularly got confused by it, and the only 2 who didn't were abra developers…

Generally, optimising for the usability of the majority of commands seems better than optimising for abra app cmd, which will be run comparatively rarely, and often (as in @nicksellen 's example, and recipes like Outline and Nextcloud), is something that users will be copypasting from docs anyway.

So I think my preference of the options presented is "upgrade to v2 and include a patch which automatically re-orders 'after' style options into the 'before' style transparently".

But I'm a bit worried about corner cases, and present mystery fourth option of "add INFO output to abra app cmd to show which options are being passed to the command and a note that 'before' style is required for abra app cmd".

RE 021 "Flag handling in abra", I think returning to requiring the "before" style for all commands would be a significant usability regression for all subcommands except `cmd`. To adapt [`urfave/cli#1113`](https://github.com/urfave/cli/issues/1113) to the `abra` context, the "before" style requires extra keystrokes every time we're adding or removing an option, for disambiguation that seems unnecessary ("after" options have no other meaning, except for `cmd`). And, to expand on #284, most of the ~8people who I collaborated with on Co-op Cloud deployments when "before" style was required regularly got confused by it, and the only 2 who didn't were abra developers… Generally, optimising for the usability of the majority of commands seems better than optimising for `abra app cmd`, which will be run comparatively rarely, and often (as in @nicksellen 's example, and recipes like Outline and Nextcloud), is something that users will be copypasting from docs anyway. So I think my preference of the options presented is "upgrade to v2 and include a patch which automatically re-orders 'after' style options into the 'before' style transparently". But I'm a bit worried about corner cases, and present mystery fourth option of "add INFO output to `abra app cmd` to show which options are being passed to the command and a note that 'before' style is required for `abra app cmd`".

👍 1

decentral1se referenced this pull request from coop-cloud/abra

2024-04-06 22:21:41 +00:00

WIP: upgrade urfave/cli to v2 #404

basebuilder commented

2024-04-08 09:02:07 +00:00

Alternative names for atrophying which are likely easier to pronounce for non-native English speakers:

chilling
freezing
ghosting
inactive
sleeping
stale
rotting
rusting

I think sleeping might be best of those or as @kawaiipunk suggested elsewhere inactive but I guess there is some fun in other names too...

Alternative names for `atrophying` which are likely easier to pronounce for non-native English speakers: - `chilling` - `freezing` - `ghosting` - `inactive` - `sleeping` - `stale` - `rotting` - `rusting` I think `sleeping` might be best of those or as @kawaiipunk suggested elsewhere `inactive` but I guess there is some fun in other names too...

😆 1

decentral1se reviewed 2024-04-14 10:52:58 +00:00

docs/federation/resolutions/drafts/023.md

						
				@ -0,0 +2,4 @@

				title: "Resolution 023"

				---

				- Topic: Budget XXX: Improved project organisation

decentral1se commented

2024-04-14 10:52:58 +00:00

Note: to be discussed on the upcoming fedi meet: https://pad.local-it.org/KJtskhS1RaGEYIF6lZ3ffA#Agenda

This pull request is marked as a work in progress.

This branch is out-of-date with the base branch

You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.

git checkout -b resolutions-march main

git pull origin resolutions-march

Step 2:

Merge the changes and update on Gitea.

git checkout main

git merge --no-ff resolutions-march

git push origin main

Sign in to join this conversation.

No reviewers

No Label

No Milestone

No Assignees

4 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/docs.coopcloud.tech#256