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

[donavan nelson]

> 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 sanitize new releases will be identical 
> to preceding package releases/errata. 

Agreed.  I don't think the list is all that big either (20-30 packages
excluding the install packages).
 
> 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.

Agreed again.  2-3 days after a RH release shouldn't be all that hard to
accomplish.
 
> 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

Proving that the same problem exists in RHEL requires access to RHEL.  And to
have RHEL available in a similar fashion to the configuration of the WBEL install.

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

Excellent point, WB could easily become the stepping stone to RH for some WB
users.  FYI, I have serious doubts about the driving forces behind Fedora.  I
think people will use and maintain it, but those are the tinkers.  Some of us
want a stable environment to do real work in.  If WBEL didn't exist as an
alternative to RHEL I would be looking for a new Linux platform.  Fedora
doesn't have any life in any production environment and I really wonder how
that is going to effect the RHEL product line down the road.  (BTW, I don't
consider on your desktop in the offace a production environment.)  I have one
Fedora and one WBEL desktop at work.  Both do the same thing equally well
(except for the outdated OpenOffice shipped with WBEL).

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

Here again, access to legal errata is an issue.
 
> 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!)

I'm not sure John maintained his current changes as patches to the RH src.  I
hope he did, but I'm not certain he did from prior discussions (and looking at
the "how I did it" section of the website).
 
> 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 think a centralized distribution point for WBEL errata (and sources) would
go a lot further towards developing end user trust than having a way to
backtrack to the RH SRPM.
 
> 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.

One person can't possibly do this.  Once we get past the inital release, I
hope John goes the direction of setting up some sort of management structure
for the build team.

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

Not to mention how it would look if WBEL is releasing errata for WB before
Redhat gets it released for RHEL.
 
> 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?

Again, "good faith" has a lot to do with this.  We have a clean package list,
if Redhat releases a Security/Bug fix for a package, I'd think we could
presume it was clean.  If it's an update, that is another story.  Even if we
release an errata package with an issue wrt Redhat copyright/tm/sm/whatever we
can alway release a second errata package to clean up the problem.  "Good Faith"
 
> Hope that this is food for thought.

You bring up many interesting and valid points.  You now have my food for
thought regarding some of them.

.dn