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

[Imre Solti]

Nice to see that the thread I started with an innocent technical 
question (How to get the RHEL Errata) has such a long life. :-)

A few comments to Sebastian's email.
1) RH is a company with business interests.
2) If RH the company will start bleeding serious money because of the 
popularity of WBEL (or other similar projects) then RH will do 
everything within the letters of the GPL (and not necessarily the 
spirits) to make WBEL's life harder. They should because they have 
shareholders and the management will be responsible to them.
3) The biggest potential problem with WBEL is that it depends on RH's 
good intentions or the GPL's protection whichever is stronger here to 
"provide" some sort of access to the errata's source code and this code 
should be easy enough to compile and generate binaries for WBEL.

IMHO, one way to ensure that RH will tolerate us is not to become "too" 
successful. If only those people and organizations will use WBEL that 
otherwise would never subscribe more than one box to official RHEL-RHN 
and would just "cheat" and install unofficial copies of RHEL and move 
binaries to these boxes by violating the RH EULA then I think WB - RH 
relationship will be OK. I am talking about individuals (SOHO), small to 
medium size businesses and potentially Universities. If "real" big 
business would start to use WBEL instead of subscribing hundreds of 
boxes to RHEL then RH will start tinkering with their errata to make 
existence of WBEL harder or impossible.

Intentionally staying small means that organizational structure remains 
somewhat fuzzy, no money involved (other than occasional donations) and 
most importantly it means that WBEL remains a download only and no CD 
distro. So, although the generating and selling (even for a nominal fee 
only) CDs idea (saw in an other thread) is understandable from the point 
of convenience of users, it might not be the best interest of WBEL on 
the lung run.

Only a few thoughts. I think only time can tell how the RH - WB 
relationship will work out.

Imre

Sebastian Welsh wrote:
> 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
> 
> 
> _______________________________________________
> Whitebox-devel mailing list
> Whitebox-devel@beau.org
> http://beau.org/mailman/listinfo/whitebox-devel
>