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.)
[snip]
> > = The support question =
>
> > So we somehow need to make sure that maintainers for EE know their
> > responsibilities. Suggestion how this could be done are welcomed. Maybe
> > only certain and well know FE contributors get allowed to build for EE
> > in the beginning
>
> That is certainly a good approach. The problem as I see it though is
> (from my point of view) the delay in syncing between core packages. A
> good example is mono. My spec files currently work with both FC5 and
> rawhide and this is because FC-5 and FC-6 currently run on different
> versions on mono (though the main difference is that FC-6 is
> architecturely correct).
>
> If RHEL is synced with FC4, this isn't a problem as FC4 doesn't have
> mono and due to the rolling legacy, is no longer fully supported. As it
> is a commercial product though, if it is synced with FC5, then I would
> imagine that when FC5 is brought into line with FC6 for mono, that RHEL
> will still be on the old FC5 "super stable" branch of mono. Support
> could become a pain!
>
Yes. And this is one of the major reasons that not every FE contributer
will be building for EE and not every package will have a branch for the
RHELX releases. The person maintaining the packages on the RHEL
platform has to be committed to caring for the RHEL packages even when
FC and RHEL diverge.
> > = The quality problem =
> >
> > In Fedora Extras the burden to make sure new or updated packages work
> > fine mostly is -- after the QA during package review -- only in the
> > hands of the maintainer itself as there is no {updates-,}testing repo
> > where updated packages get tested by other people or on archs that to
> > which the package maintainer has no access to. That mostly works fine
> > for FE (some people think that's a problem there, too, but that's
> > another story), but is it wise to lay all the QA in the hands of the
> > packager for a repository that builds for and Enterprise Distribution?
>
> No. There needs to be a sandbox system whereby a contributor submits the
> package, it is built on the architectures RHEL supports and then tested
> by either RH staff or volunteers with the other architecture. Once it
> has passed the testers, it can go into the Enterprise distro.
>
This could be interesting. Wonder if the Fedora Testing stuff would
help here... (wwoods still on honeymoon?)
-Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
