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

[RftD]

On 27 Nov 2003, Sebastian Welsh wrote:

> 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'd probably want to check this with redhat itself first.  They may 
prefer something along the lines of just mentioning that other software 
providers (link) include more well supported (etc) products for people who 
need this.  The way things are said above may sound too much like we are 
trying to use their market image or branding (ie violating their 
trademark) to promote ourselves (even if that is not how we intend it).

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

This is *definitely* something we'd have to discuss in detail with redhat, 
and we'd probably have to be legally incorporated so that someone could 
sign a binding agreement with redhat, in order to ensure we aren't 
violating their trademarks, since we'd be including them within the 
package.

> 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.

Well, getting bug reports to the right place is definitely something we 
want to ensure.  Not only would that antagonize redhat, it would also 
make it harder for us to find and fix WB specific bugs.  Determining that 
problems are redhat specific or WB specific will be the tricky part.  
Assuming nobody has access to both systems for testing, it will be 
extremely difficult without identifying the exact bug and then seeing if 
it is in the RH standard SRPM as well - in effect fixing all bugs in both 
WB and RHEL ourselves.

> 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!)

Requirements would actually be two files, one diff that updates 
SPEC/package.spec and creates SOURCES/package-wbel.patch and one tgz file 
that contains the image replacements needed.  The problem would be that 
redhat probably wouldn't conveniently place all their trademarked images 
into a single external source file (which we could simply replace) but 
would more likely place them in all the source files.  I've not examined 
this issue closely, but judging from the difficulty mentioned on the page 
so far, I'd say that redhat didn't take the convenient road.  If anyone 
thinks they can convince redhat to separate their trademarked images (and 
other binaries if there are any) into something like 
Source99: package-version-redhat-tm.tar.bz2
be my guest. :)

> 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.

I think that we *should* be creating a spec diff and a unified diff of
package changes for maintainability, but because of the images and other
possible trademark issues etc, it still won't be simple.  When I did this 
on the past (I work at a hoster where we often keep slightly modified 
versions of RPMs for our own internal use) we keep one directory for each 
SRPM, inside it would be {orig,modified}/{SOURCE,SPEC} which contain only 
the files that changed (or added/removed) by the srpm. That way we can 
quickly see what files have changed.  The problem that WB has more than we 
had, would be that we didn't need to worry about distributing RH 
trademarks, since we aren't distributing the packages outside.  Presumably 
that means our SRPMs also shouldn't ditribute the files, so simply adding 
a tar.gz with replacements wouldn't be sufficient, we'd actually have to 
make new tar.gz files.  That is probably much harder to keep updated.

> 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.

I'd very seriously doubt that would be a good idea for redhat, at least in
the case of security patches.  They might (though probably not) be
persuaded to tell us what changes they made at the same time they make the
errata release (which would let us just apply the same patch to our
version).  If they'd do that, and if the patches were relatively small,
(as would typically be expected for enterprise only-fix-what-is-broken
style patches) this would be a huge help to us.  But I don't think it
would be a good idea for them to delay the errata release at all, and we
wouldn't want to get "we think this will fix it, but we haven't released
yet because we are testing" because if we released that, and then they
found a problem, we'd have to do a extra errata for it.

> 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.

Well, this might be a good idea in terms of speed, but I think in terms of 
manpower this could be prohibitive.  Plus, since we can't anticipate what 
packages will need errata, it would be hard to know how many people to 
assign to each package in order to properly distribute the workload.  This 
isn't nearly as much of a problem for the original developers (ie redhat) 
because they already have people working on updating the packages for new 
releases.  For this project, there is going to end up being times 
(hopefully!) when there isn't much to do, and then times when there is a 
huge flurry of activity (eg kernel, XFree, gnome, kde, etc update).

> 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?

I think as long as we are making a reasonable effort to clean the
packages, we'll be OK.  IANAL.  I could ask our corporate lawyer, but I 
think he probably has other things to do, and it might be frowned upon for 
me to "borrow" his time for this. :)  I believe that if we make a mistake 
we'll need to correct it within a reasonable amount of time, not kill 
ourselves trying to get a patch out in minutes.