[neomutt-devel] using sourcehut as alternative, experimental way of contributing (patches with CI)

Ihor Antonov ihor at antonovs.family
Fri Mar 19 19:21:08 CET 2021


On 2021-03-19 14:32, toogley wrote:
> Hello everybody,

Hi toogley,

> Ihor recently expressed slight interest in using sourcehut...
> 
> So i talked to Drew DeVault about this and he said that we should not
> worry. Financial aid, that is using sourcehut for free...
> 
> Now i suggest ...

There are several layers of what I think and I'll try to be systematic
and methodical in laying it all out. Additionally I'll try to explain
flatcap's stance on the subject.

On the surface the idea of using sr.ht is great. That platform has
certain advantages over GitHub, including but not limited to email patch
workflow and more OSes available to CI. And so enthusiasm about using
this platform is understandable.

Now, one has to consider the cost of setup and maintenance that adds up
to existing costs. The term "cost" that I'll use below is somewhat
handwavy, as it is hard to define some of it's components. It is mostly
time and human cognitive capacity to hold and switch contexts. All
humans have very little amount of this both of these resources.
And the cost is not uniform between features, so I'll try to break it
down by feature:

- Mirror on sr.ht is fairly high amount of maintenance, because it is
  one more place to look at, one more place where sync can break, one
  more place to keep secure, update passwords, share access etc.  In
  other words it is one more "house" that somebody has to own and take
  care of. I don't want to own and maintain it. Neither does flatcap.
  If you feel like doing it - you don't need our permission, it is
  opensource, set up an unofficial mirror.

- CI platform itself has probably the lowest cost among the offered
  features. And *just* sr.ht CI can be used without setting up the
  mirror on sr.ht (as I did on opensmtpd project). It integrates with
  GitHub nicely and one can see failed or successful check in a PR, same
  as GithHub actions, Cicrcle CI, Travis or any other CI platform.
  This is the only thing that I thing is worth taking a closer look at. 

- Email patch workflow has the highest overhead in my opinion. It
  requires a mirror to be set up. It also complicates mirror setup as
  now 2 way sync is required to prevent divergence. As much as I like
  emails I think the tooling is for this workflow to be efficient is not
  there yet. It is one more place to context switch to, one more mailing
  list to read. Believe it or not - not many people even know how to use
  emails and patches together these days. Occasional patch sent to devel
  mailing list has significantly lower overhead today than setting up
  and maintaining sr.ht email patch review platform.

Pair this with the fact that neomutt already has a couple of CI
platforms set up. The added benefit of yet nother CI and is somwhat
marginal, the law of diminishing returns an all that.

Now, please don't take offence on flatcap's harsh NO response. Instead
try to put yourself in his shoes: he is the *only* stable maintainer of
neomutt. All others, including me and you, are come-and-go weekend
warriors.  Flatcap has to perform a full range of duties like reviewing
and merging  PRs, categorizing and  replying to issues, rebasing stale
PRs to keep them up closer to master, maintain 2 mailing lists, and take
occasional patches sent there and put them into repo. He also writes a
shit ton of documentation (pardon my French, but have you seen how much
there is?) to make the life of other developers easier, he maintains an
IRC channel and neomutt's website. He has to maintain a mental map of
all the neomutt's code (and the codebase is huge) to be able to review
the code and respond to our stupid questions, ensure stability, make
releases etc.  Finally needs to find time to write some code too.

So as much he might be excited about new things he simply can't afford
them right now.  He is a human and there are only 24 hours in a day and 
we are asking him to do even more. Taking something into official repo
is a commitment.

If you really want to help try to think you how can combine achieving
your goal and help reducing(or at least not  increasing) his burden. 
Here are my suggestions of how this can be done:

- Write build manifests to sr.ht CI, submit them for review, I will help
  you with integrating it into neomutt's CI, I can take care of the rest
  of sr.sh CI setup (I already have an account there). We can run sr.ht
  CI tests as optional as a start, later we can promote them to
  mandatory if they prove to be useful and low overhead.

- It is entirely possible that we are missing an untapped reserve of
  contributors who are willing to work only on sr.ht and contribute by
  sending patches. Set up a mirror, take care of bi-directional sync.
  You can have a branch in main repo to mirror back sr.ht.
  Convert a stream of email patches to Pull Requests in official repo. 
  I am sure flatcap will say "thank you".
  By acting as a mediator between the main repo and your mirror you will
  achieve what you want, and help flatcap, without putting more work on
  his back. See for  yourself how much maintenance this is. Try to automate,
  improve the workflow.  We can mention alternative workflow in the
  README. 

- Alternatively you can help flatcap with his current focus - refactor
  the codebase. Make it more approachable, readable, testable. This is a
  long game, but it leads to sharing flatcap's knowledge of neomutt, and
  taking some of burden off his plate. With time we can return to sr.ht,
  when we have more manpower, or lower maintenance overhead of the
  existing code.

The bottom line is this: you are asking for features, but they mean more
work for us (more different kinds of work). In return I offer this work to
you, as we can't take more work now. This is how community works, by
sharing responsibilities, ownership and work, I hope you understand.


----
Ihor

P.S. Sorry for long email. It would've been shorter if I had more time to
formulate my thoughts better and shorter. 


More information about the neomutt-devel mailing list