Recent activity

[PATCH] testing/chafa: new aport 5 months ago

From Cosmo Borsky to ~sircmpwn/alpine-aports

 testing/chafa/APKBUILD | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 testing/chafa/APKBUILD

diff --git a/testing/chafa/APKBUILD b/testing/chafa/APKBUILD
new file mode 100644
index 0000000000..bafd4f4b0a
--- /dev/null
+++ b/testing/chafa/APKBUILD
@@ -0,0 +1,28 @@
# Contributor: Cosmo Borsky <me@cosmoborsky.com>
# Maintainer: Cosmo Borsky <me@cosmoborsky.com>
[message trimmed]

[PATCH] testing/brillo: new aport 5 months ago

From Cosmo Borsky to ~sircmpwn/alpine-aports

 testing/brillo/APKBUILD | 47 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 testing/brillo/APKBUILD

diff --git a/testing/brillo/APKBUILD b/testing/brillo/APKBUILD
new file mode 100644
index 0000000000..ebd693b5f1
--- /dev/null
+++ b/testing/brillo/APKBUILD
@@ -0,0 +1,47 @@
# Contributor: Cosmo Borsky <me@cosmoborsky.com>
# Maintainer: Cosmo Borksy <me@cosmoborsky.com>
[message trimmed]

[PATCH] community/redshift: Add wayland support patch 5 months ago

From Cosmo Borsky to ~sircmpwn/alpine-aports

This patch comes from a fork of redshift by minus.
The patch was edited to remove .gitignore, .travis.yml, and appveyor.yml

It didn't quite make sense to fork this package to add in one (large) patch. If
that is the desired action, do let me know.
It has been almost 18 months since this patch for Wayland support was
submitted to redshift with little interaction from the redshift developer,

The patch seems to have been tested by various users, and is
available in upstream repositories for Arch and other distros.

NOTE: I have only tested this on Sway/Wayland. I would advise testing on X11
and other supported platforms before merging.
[message trimmed]

Re: Does it make sense to keep ~alpine/aports running? 6 months ago

From Cosmo Borsky to ~sircmpwn/alpine-devel

If it makes any difference, I am willing to contribute time and resources for SourceHut related Alpine development.

I think it is good to keep to one platform. GitLab is a mature suite which is familiar to a lot of developers, although aspects of it are proprietary.
SourceHut is in alpha, still in (very) active development, and many pain points have been and are being alleviated, on top of it being full FOSS.

However, since there are a good amount of developers contributing patches to the aports list, it makes sense to keep the list knowing that review may take time, and have developers/reviewers use the platform they are comfortable with until several pain points are resolved.

It would be good to put together a comparison list between GitLab and SourceHut that covers what each platform does well, what could be worked on, and what it does not do well.

>From this email thread, what I see as things that need to be worked on with SourceHut are:
- CI builds for patches submitted via list
- Fix compatibility with various hosts, eg Gmail
- Offer alternative methods for submitting patches, for example via web api if SMTP is blocked on a network.

Re: Does it make sense to keep ~alpine/aports running? 6 months ago

From Cosmo Borsky to ~sircmpwn/alpine-devel

We shouldn't be so hot on removing the lists if they are not getting attention.

If the mailing list goes unattended, pinging devs should be OK. If a contributor chooses to make a GitLab account and submit a patch as a PR, they should be able to. If a contributor would like to email a patch in, they should be able to.

This seems more like the mailing list is not used extensively by devs/maintainers because it does not fit their workflow, be it testing patches, merging patches, etc.
IMO, we should discuss what could be done to fit the developer's workflow and be more inclusive of those working on the mailing list.
I've started to adapt a workflow that caters to both systems: the ability to mail and test mailed-in patches, and the ability to ease submitting PRs in eg. GitLab.

Keep in mind the lists are powered by SourceHut, which is still in its early days.
If you have ideas that would improve mailing list flow, submit a PR to SourceHut.

Here is a task related to this thread:

Re: User groups proposal v2 6 months ago

From Cosmo Borsky to ~sircmpwn/sr.ht-discuss

This looks good. The user vs org pricing distinction is great and much easier to imagine scaling.

What are the implications for an organization looking to self-host SourceHut? Is it fine as long as they are within the GPL?

What happens if a user or org would stop paying? Are their resources (eg. git, wiki, lists) still active? Do they turn read only? Would there be a grace period?

Re: Supporting user groups/organizations on SourceHut 7 months ago

From Cosmo Borsky to ~sircmpwn/sr.ht-discuss

> This is a good idea. Need to think about how to balance it for ad-hoc
> organizations of users, which don't map onto real-life organizations
> with a budget to pay for things like this, but it's a better model than
> what I had in mind for sure.

Are ad-hoc organizations expecting to use more resources than companies/larger orgs? My thinking behind this is that resources are sort of freely available to sourcehut users, where limits are on machine time and not exactly usage of resources (though I may be wrong, I have lurking for the better part of a year). If anything, SourceHut could sponsor organizations with more resources or a discounted/free rate.

Maybe adapting Migadu's tiers, where users are roughly limited by a resource (I.e. emails out per day), and if they hit that limit a courtesy notification would ask the user to upgrade to the next plan, and service would be cut back for the rest of the day if a % above the limit is hit.

A rough pricing model could be:
"Open Source" - organizations that strictly work on open source could be sponsored by SourceHut (similar to a user being sponsored by Drew), where they would have the same limits as the "introductory organization" tier. This group could also be used for ad hoc orgs, where it isn't one sole entity but a group of source hut users pooling a project together (eg. SourceHut itself).
"Introductory" - $25/mo, includes 3 SourceHut user sponsors, and offers 20 Git repos, 20G total Git storage, 50 dispatch events per day, and 20hrs of build time a week.
"Established" - $75/mo, 10 SourceHut user sponsors, unlimited Git repos and 100G total Git storage, 200 dispatch events per day, ...

Re: Supporting user groups/organizations on SourceHut 7 months ago

From Cosmo Borsky to ~sircmpwn/sr.ht-discuss

Why not consider a resource limit on organizations? Sure, there's some overhead to keep track of, but this allows for better flexibility between individuals and organizations, and may serve as a good basis for metric collection on the organization's side (git repo size, build bandwidth and time, dispatch calls, etc)

Resources keeps the model somewhat separate, where users pay for their account (which could be sponsored by an organization), and organizations would pay for usage, whether that's # of git repos, # of dispatch and builds per repo, and/or # of lists.
Sponsored organizations/projects could have a limit to these resources for "free", and it keeps introductory organization rates down for the bare minimum.

One random thought would be the ability for organizations to expand from a resource model to renting servers, where sourcehut staff could set up a dedicated sourcehut instance for the organization.

Re: The happinesses and stresses of full-time FOSS work 7 months ago

From Cosmo Borsky to ~sircmpwn/public-inbox

Hi Daniel,

I can't fill in for Drew here, but I'd love to add my thoughts based on my experience with similar endeavors.

The suggestion for /working less/ is pretty involved, where working less simply leads to duties that build up quickly, and when these duties are not dropped/forgotten, catching up on these duties can lead to burn out... or at the very least one will acquire a larger distaste for doing them.

Starting a new project doesn't necessarily add time to the required tasks on hand. The tasks on hand in Drew's case, as he detailed, extends much beyond just writing software and extends into management, support, maintenance, and PR on top of running a company (executive duties, accounting, etc).

More contributors does help with the burden from the writing software roles, however filling those managerial and executive duties takes much more than a willing volunteer - in most cases: mutual trust, financing, and coordination.


Re: Uses for HDCP other than DRM 11 months ago

From Cosmo Borsky to ~sircmpwn/public-inbox

On October 10, 2019 2:40:05 PM UTC, Simon Farnsworth <simon@farnz.org.uk> wrote:
>What other fields of endeavour do you think that Free Software should
>be excluded from?

Simon, I believe you missed the point.

The biggest issue is proprietary protocols (and software) starting to make their way to FOSS.

>Obviously, private repo hosting (GitHub, Bitbucket etc) has to be
>something I refuse to pay for by the same logic, as it's possible to
>use private repo hosting for completely closed software.