We are evaluating building packages from Fedora Extras for RHEL

[Toshio Kuratomi]

On Mon, 2006-09-11 at 09:17 +0530, Parag N(पराग़) wrote:
> Hi,
> On 9/10/06, Toshio Kuratomi <a.badger at gmail.com> wrote:
> > On Sun, 2006-09-10 at 13:17 +0100, Paul wrote:
> > > Hi,
> > >
> > > >  = The name question =
> > > >
> > > > We don't have a proper name for this effort yet. The "codename" until
> > > > now was Enterprise Extras (EE) (it is used in this document in several
> > > > places due to the lack of a better one), but we are currently evaluating
> > > > other names. There were several suggestions:
> > > >
> > > >  * Fedora Extras (e.g. no special name)
> > >
> > > Problem with having Fedora in any of the proposals is that despite
> > >- Fedora being a recognised "brand", the Extras is known to be a community
> > > contributed area with none of the QC that goes into the paid for product
> > > - for example, say any of the mono packages in FE goes wrong, the report
> > > usually ends up on my intray. I'm just some bloke, sitting behind his
> > > Linux boxes in his house extension, but with a full time job and full
> > > time family to contend with. I doubt any company worth their salt would
> > > want to use (say) Monodevelop without someone from RH being able to
> > > support the product - I know my former boss wouldn't even entertain such
> > > an idea.
> > >
> > > Now we all know that the support from anyone involved with FE and FC is
> > > the best there is anywhere, but the linking of a commercial product with
> > > something just added on may not entice many folks.
> > >
> > You have a different vision for Enterprise Extras than we have been
> > discussing so far.  What we have been discussing really is Fedora Extras
> > rebuilt for RHEL/CentOS/etc.  We aren't making additional guarantees to
> > the consumer of the packages about the suitability of the packages for
> > running on their servers (except that we will be supporting the packages
> > for the increased lifetime of the CentOS/RHEL distro.)
> 
>   So is there any preliminary information about which RHEL version is
> decided fo rebuilding all FE packages for RHEL? I mean there are
> currently RHEL 3,4,5 with various updates that mean totally if i am
> correct 13 version in all present of RHEL.

I don't believe this has been discussed yet.  I would vote for starting
the project with the latest RHEL at the time.  That way we can start off
slow with a single EE branch to try out.

>   And how can i solve then dependencies problem if i decide to rebuilt
> my FE package for RHEL3? RHEL is known as stable product because it
> always contains old but stable packages from upstream releases. So how
> can we solve dependencies problems like if some packages need latest
> or newer version of dbus or hal for any FE packages?

I'd think we'd branch from the FC branch that the relevant RHEL was
based on.  We'd branch FC3 for RHEL4, for instance.  (This hasn't been
discussed either.)

At that point, deciding how to deal with upgrades, security fixes, etc
will begin to diverge from FE since the base distro won't have the
latest versions of many of the base packages; making the "upstream
mantra" not applicable in all cases.

A side thought: How does the Security SIG fit into this?  Hopefully,
since the expectations for EE branch maintainers are plainly stated,
there won't be too many abandoned packages that they have to step in to
deal with but someone still has to track the Security Issues that occur
in these versions of the programs and whether we've patched the sources
to fix those problems or are still vulnerable.  Do they feel this is a
task they want or does there need to be a separate EE-Security-SIG?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060910/0015c70e/attachment.sig>