Re: Choice of distribution for new sourceware.org server?

[Carlos O'Donell <carlos@redhat.com>]

On 2/6/20 9:49 AM, Frank Ch. Eigler wrote:
> Hi -
> 
>>>> How much non-distro software is there on sourceware?
>>> Well, quite a bit.
>>
>> If non-distro softare impacts our maintenance costs, should we be evaluating
>> the list of non-distro software for value vs. cost?
> 
> We evaluate regularly.  It's not just software that substitutes for
> distro bits (there's only a bit of that).  Remember things like
> multiple wikis, bugzilla.

Awesome. Do you need any help with regular evaluations? Is there a meeting
for that? Or is this tactically driven when something can't be upgraded?

I'm surprised the wiki is non-distro software. I recently setup a dokuwiki
backed by git, and it was all distro-software with just configuration data.

Moinmoin is basically dead upstream.

Dokuwiki is actively maintained and there are migration paths from moinmoin
to dokuwiki.

Also if we did a git-backed wiki we could use the same git access mechanisms
for the wiki and not maintain distinct lists of users!

And I would switch to gitolite following the kernel's lead here for serving
git, and we could do that with relatively little effort (pickup all the pub
keys people have, populate gitolite keysdir and copy the raw git repos).

This would also allow us to restrict shell access to only those that ask for
it and thus limit our security exposure (best practice).

Then we'd only have one process for registration, hand over your pub key,
and you get immediate access to git, including the wikis now stored in git.
 
>>>> When you say "activity" do you mean that users would be impacted
>>>> once every 8 months for a small window of downtime?
>>>
>>> Probably, if nothing goes wrong.  And if there's an incompatible
>>> rebase of python or php or whatever, then we (?) have to fix the
>>> thing.  There is a downside to upgrade churn, in terms of our
>>> manpower.
>>
>> Best practice is to have a production and development server to
>> avoid these kinds of problems and shake out such changes.
>> Do we have 2 servers now?
> 
> rawhide level upgrade churn has to bring tangible value that is in
> excess of the costs (to all the parties, not just users).

I agree completely. I don't suggest we run Rawhide at all.
 
>> In which case RHEL8 with ELS as an option is even more valuable?
> 
>> In summary:
>> - Why not stick with RHEL8 to get ELS and avoid CentOS 8 early phase out.
> 
> Already said I'll look into moving from centos8 to rhel8.  centos
> lifespan does not look materially different from rhel.

CentOS 8 is EOL when RHEL 8 ELS starts. RHEL 8's lifespan is 10 years,
with RHEL 8 ELS adding another 4-5 years of support. That's almost a
50% increase in lifespan to schedule and upgrade. That looks materially
different to me and impactful for managing the upgrade.

CentOS 8 forces you to keep upgrading through the changing y-stream.
Some y-stream upgrades for AppStream may be rebases of pakcages
that break your deployment.

With ELS you can camp out on RHEL 8.4 *without* upgrading to
RHEL 8.5/8.6/8.7, and then upgrade to RHEL 8.8. It gives you the
flexibility to camp out on an ELS release and schedule around
the upgrade.

Please review the following details:
https://access.redhat.com/support/policy/updates/errata

We would have to ask Red Hat for licenses.

-- 
Cheers,
Carlos.