[libre-riscv-dev] [Bug 131] Check out Gitea

[Luke Kenneth Casson Leighton]

On Tuesday, August 13, 2019, Michael Pham <pham.michael.98 at gmail.com> wrote:

> So, Luke, what do you think of Gitea?


Their  bugtracker.. is hosted on github! I mean, what the hell! They have
so little confidence in their own code, they have to use github?? What's
wrong with gitea, so bad is it, they can't run their own issue tracker??

At least sourceforge ran alexandria (sf project 1, which became fusionforge
later), and trac is self hosting, too.

Am not inspired, here :)

Plus, if there *are* any issues, where am I going to report them? I'm
certainly not going to report them on github, am I?

And if things go wrong, they *really* go wrong, very fast, and I have to
stay up no matter what time it is, until they're fixed.



>  It's much leaner than GitLab and you
> can self-host with it. I think Jacob generally agrees with upgrading to
> something over what is currently being used. Of course, since you're the
> one hosting the server, it's completely up to you.
>
>
Hosting is a lot more than just installing and paying for the server, it's
being ready to deal with bugs, attacks, failures and as a last resort total
rebuilds, at any time.

Knowing the codebase, as a series of small simple packages (the UNIX
philosophy) rather than a behemoth of code that would need me to learn an
ENTIRE new programming language, AND to install and learn its build
environment, this is not inspiring me with confidence.

Perl is truly dreadful, buzilla, gitolite3 and ikiwiki are all written in
it. However they are simple enough that I can actually investigate without
expecting the developers to drop everything and help get a site back up and
running in an emergency.

Which is what I would have to do because gitea is written in golang.

At least with perl it is not necessary to do a full rebuild. I can hack one
line of code, hit refresh, and see if it fixed the problem.

Yes I have actually had to do that, in both bugzilla and in ikiwiki, over
the years.

Aside from the technical qualities, I think the biggest benefit would be
> the much nicer interface which would be more welcoming to newcomers.


When those newcomers are also prepared to take on the full time permanent
long term responsibility for keeping that code up and running 24 x 7 for
the next 5 to 10 years, I will assess whether it is a good idea to let
them.  They will need to demonstrate full competence in golang *and* in
systems administration.

This is how Software Libre works.

Meeting peoples' expectations without them actually taking responsibility
for what they want does neither party a favour.

The last team that hijacked the domain of a project that I led, it not only
cut my already seriously low income in half (resulting in us being evicted
from our home some five months later), the hijackers self-sabotaged the
project and it is now abandoned.

Why did they hijack the project? Because they "disagreed" that a web
framework should be self-demonstrating, self-sufficient and self-hosting:
they ripped out the self hosted wiki that showcased the project's
capabilities, refused to help out getting the bugtracker working, refused
to help with the git web frontend viewer, dumped everything on github,
ripped the website to shreds (replacing it with static HTML).

and then three years later they abandoned it as, unsurprisingly, with it
being completely hypocritical and no longer having self hosting as a way
for its *own developers* to experience and empathise with the end users, no
end user wanted to use it.

Bottom line is, there is a lot more to project hosting than people realise,
and use of github (and other "monetarily zero cost" services) is teaching
people that they can "get good looking service" for free, disempowering
them in the process in so many ways it's just not funny.

L.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68