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.
Just playing Devil's Advocate here...
> * Enterprise Extras (EE)
This is a damned good name IMO for exactly the reasons why FE isn't a
good name!
> * Fedora Extras Enterprise (FEE)
Given RHEL is a chargable product, this is a somewhat ironic name ;-p
> * Fedora Extras for Red Hat Enterprise Linux (FERHEL)
Too long and doesn't sound nice
> * Fedora Extras for Enterprise Linux (FEEL) or (FEfEL)
FEEL the quality.... Nah... ;-p
> There were several comments to this name suggestions. Here are the most
> important ones:
>
> * having "Fedora" in the name...
>
> * ...might be confusing because the results from it are for RHEL/CentOS
>
> * ...might be a good idea because it shows that the stuff is
> unsupported by Red Hat
See above. Look over at the darkside. While there are tonnes of 3rd
party apps out there, how many big ones (such as OpenOffice and mono)
are widely used?
> * having "Enterprise" in the name...
>
> * ...shows that the packages are for Enterprise Distributions like
> RHEL/CentOS
>
> * ...might suggest too much about the _type of software_ that is
> offered, instead of the target distribution the software is built for.
That's the lovely thing about Extras - it's a pot pourri of excellence.
> = 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!
> = 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.
> Closely related is the updates scheme EE should use -- do we use the FE
> "rolling release" approach? Or do we want to try a mix like "Updated
> packages in EE are allowed (Rolling Release), but they normally should
> be build and published a certain time frame in the repositories for FE
> first before they are published for EE"?
This seems almost pointless. Just because a piece of software has had
zarro boogs reported by bugzilla doesn't mean it's clean. If the sandbox
system above is used and the resulting binaries placed in a "testing"
directory until they are fully santised (or QA'd by the RH people) then
there is a progression path available.
> = The co-maintainership problem =
>
> We really need proper co-maintainer soon for this effort together with
> the things co-maintainership implies -- e.g. the package database and
> maybe restricted access in the VCS. We can start without proper
> co-maintainership, but it should make stuff a lot easier.
Personally, I think the co-maintainership should be performed in the
forms of SIGS - that way we have those who know about (say) security or
mono or games doing what they are best (and quickest) at.
TTFN
Paul
--
"Bist Du meine Mutter?" - das leere kind
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
