[WBEL-devel] Long- Thoughts on WB maintenance (was Re: How to get the RHEL Errata?)

[Sebastian Welsh]

On Thu, 2003-11-27 at 04:09, Vlad Mazek wrote:
> Either a mailing list or a web page that indicates the package name and the
> severity of the problem. Here is the problem that might come up: 1) package
> xyz has a remote root exploit 2) a day later RedHat comes out with a patch
> 3) x amount of time for WBEL to strip out the copyrights, rebuild the
> package, etc.
> 
> -Vlad 

As the bulk of material requiring removal is static, I anticipate that
most often, patches to sanitise new releases will be identical to
preceding package releases/errata. 

Unless RedHat substantially change the shape of a package in an errata
release (unlikely IMHO), I believe we'll be able to push updates in an
acceptable release window.

This raises a couple of interesting points to consider:
- how we can foster a warm relationship with RedHat. 
- how we can ensure timely release of errata

I believe that the first may assist with the second. Here is a straw man
to work on:

Relationship with Redhat
========================
We need RedHats goodwill, as the viability of WhiteBox depends on the
ease of migration of upstream packages. If RedHat substantially modify
packages between errata releases, we have a whole lot of work to
maintain WB. There is also have no guarantee that we can release errata
in a timely fashion if we have to rework each package from scratch. So,
it seems to me that we should ask the question- what can we offer RedHat
to maintain a good relationship?

My first thought is that WhiteBox can be viewed as a gateway
distribution to the RedHat Enterprise range. An entity using WhiteBox
should be encouraged to use RedHat if they can afford it. We should
highlight the differences which I see as: 
 - the support structures provided by RedHat
 - the best-effort(WB) versus purchased-facility(RH) products
 - release timing of errata
and point out the benefits of this for an organisation. Another term for
this might be "product endorsement".

We may want to emphasise this on the website, in the install
instructions, in the installer splash documentation, with a free
temporary tattoo etc.

As an individual I loathe the intrusion of advertising and product
marketing. However, it seems to me that we are, in effect, riding on the
shoulders of giants and it would be poor manners to leave the impression
that we are ungrateful.

Other people have suggested that WB provides a product proofing
facililty for RedHat. If WB ensures that
 - bug reports generated from WB installs reach WB, rather than RH
 - WB aggregates bug reporting and provides input to RH only after
confirming the bug exists in RHEL
I expect with this approach we are less likely to generate grumbles from
the RH support structure, and WB may be viewed as a benefit rather than
an imposition.

Finally, I believe WB can offer RedHat a similar advantage in the server
environment that Fedora offers in less stable environments: it maintains
an install base of RH compatible products, which means their commercial
offering isn't sidelined.

Errata maintenance
==================
Another straw man here:

First, WB places trust in the integrity of RH supplied SRPMs. A user who
wishes to validate a WB supplied package should be able to easily
compare it against a RH supplied package. Therefore, the WB maintenance
model should not only be easy and compatible with RHEL, it should be
easily reverible, and easily identifiable. 

Modifications to the package contents are applied in 2 ways:
 - modification of the SRPM spec to remove violating dependencies. These
changes are flagged in the SRPM. 
 - insertion of a WB patch to the SRPM spec applied at the end of the
patch list - in other words, the patch unpatches the RedHat patches
(phew!)

It seems to me that this approach makes it easy for an end user to check
the validity of a WB SRPM against a RH SRPM by easily removing the WB
modifications. It also make it easy for an end user to examine the
changes made by WB if they wish.

I believe that this approach is well suited to the good ol package 
maintainer model. However, it still leaves us in a bit of a bind as our
updates will still lag behind those of RedHat, and as a single
maintainer has to do things like eat, sleep, holiday and walk dogs, we
need an override mechanism to push out errata independent of maintainer
availability.

Part of that comes from my earlier discussion about good relationships
with RedHat. If we have good channels of communication we may be able to
prepare for errata release with soem forewarning. However, I don't
expect RedHat would be willing to provide errata ahead of public
release, as to do so would erode some of the business case for RHEL. I'd
be happy to find out I am wrong.

Another part of the override mechanism may be to run a maintainer group
for each package, especially big, ugly packages. This may help when
substantial work is required to sanitise a package.

The final mechanism I can think of is to run a security group that uses
and/or updates the existing patch to run out errata where the maintainer
is unable to do so in a timely fashion. This approach is really only
feasible when the errata package has not changed substantially.

I can see one gotcha with this approach. I'm assuming here that we know
ahead of time what packages require cleaning. If a previously
unencumbered package is released where the new release is encumbered, we
would have a mad scramble to release an update- assuming we identified
it! Any ideas?

Hope that this is food for thought.

Seb