Hi Olaf,

On Sat, 2022-10-22 at 11:46 +0900, Olaf Meeuwissen wrote:
..cut..
> Maybe Devuan can eventually host its own runners for GitLab CI/CD
> (and GitHub too?).  I'm thinking of using Gitea's push mirror
> functionality to set up read-only mirrors there and then piggy-back
> on their CI/CD infrastructure when the mirror gets updates.  Assuming
> things work that way.
>
> # I guess I could also set up runner(s) on my own mini-PC to process
> # these jobs.

Most of us can do something similar, but I see that as a last resort
option only. IMHO the proper way is to use proper infra.
GitLab/GitHub/whatever are only good if there is a path to migrate off
them in the case we need to.

..cut..
> > > Looking at the Gitea Package Registry[1], Devuan could add that
> > > (for some kinds of "packages", after upgrading to 1.17?) but
> > > seeing the bandwidth limitations that Boian mentioned a bit below
> > > that might not be advisable.
> > >
> > >   [1]: https://docs.gitea.io/en-us/packages/overview/
> >
> > Upgrading gitea from 1.15.11 to 1.16.x did not work at all - it
> > segfaults on something, most probably an inconsistency in the DB or
> > missing/failed schema upgrade. I tried but couldn't find the reason
> > for the segfault and just reverted gitea back to 1.15.11. I didn't
> > try any version from the 1.17.x series since the upgrade test
> > itself is quite intrusive and includes a DB restore after a failure
> > and possibly losing stuff that was done in the meantime.
>
> I maintain a self-hosted GitLab CE instance at the office.  Update it
> every month, i.e. with every minor release.  I start with a restore
> from full-backup to a test instance and test/troubleshoot the upgrade
> there.

I did also prepare a test instance, but did not separate everything -
only the gitea application and the database with shared git folders.
This didn't prove to be a good way, because the new version overwrote
all git hooks with different ones during one of my tries...

> When you upgraded, you did, of course!, nitpick the Changelogs for
> breaking changes, right?

Yes. But didn't notice anything of concern.

> I see quite a few in 1.16.0 already ... more in 1.16.1, 1.16.4 and
> 1.16.5.  Does Gitea have any info on upgrade paths like GitLab does
> (one minor at a time works, skipping my requiring you to upgrade to a
> certain minor first)?

I did follow 1.15.x quite closely and everything there went smooth.
After the release of the first 1.16.x, I started trying to upgrade
without success to any of them (0, 1, 3, 4 and 5). There was no db
schema upgrade failure. I didn't find time to dig deep into debugging
what is the problem - most probably a broken or incompatible web
template or some content in the gitea's db.

Most probably the best path would to be set the separate test instance
again, but this time with cloned git folders, so it is fully separate
and does not interfere with the main instance of gitea...

..cut..
> > https://www.docker.com/community/open-source/application/
> >
> > Which is Docker Hub from your list above. Seems most appropriate,
> > especially from the point of view that docker users will easily
> > find the images there.
>
> ACK and seeing that Devuan has been approved, we really should push
> container images there.  It's the *natural* place to look for them,
> anyway.

We are now waiting for the Docker Hub team to create an account for
Devuan. Since the existing https://hub.docker.com/u/devuan looks empty
and abandoned, I hope they will allow a takeover. Or even better, the
one who made it to cooperate with the process.

..cut..

With best regards,
b.