Enterprise Extras Discussion
Participants:
- BillNottingham
- KarstenWade
- ThorstenLeemhuis
- GregDeKoenigsberg
- SethVidal
- ElliotLee
- MaxSpevack
- DanWilliams
- JeremyKatz
- PaulWFrields
- TomislavVujec
Enterprise Extras is a process to include different distributions and separate package-maintainers by distro in the Extras build process. This supports, for example, Extras that are built for Red Hat Enterprise Linux, in an open, community-centered manner. The support model is a community model, meaning if you want these packages to be there for your enterprise-supported distribution, you may need to get involved in maintaining the packages.
Starting This Way
1. Pitch the idea of multiple-maintainers based on distro for each package in Extras to FESCO.
1. Make a RHEL4 branch for each package, maybe basing off of FC3 or FC4
1. Make the plague builders capable of building on RHEL4
1. Start asking folks about wanting to fix spec files to work with RHEL4
1. At this point bring repackager maintainers into the fray to help with the spec file fixes, etc.
1. Release through http://enterprise-extras.devnation.redhat.com ?
1. Figure out how to include packages from people with other architectures, or find a way to obtain/create a pool of different architecture resources. A worldwide test pool based on Fedora Test Suite?
Questions and Topics That Need Answers (and sometimes the answers)
1. How do people get these bits?
Assume RHN is not an option. This means a yum repo and the associated unsupportable/you break it, you keep it nature.
1. Having to build and maintain yum details for earlier (and future) RHEL build trees.
1. How do we message the connection between "Enteprise Linux" and "Unsupported Extras"?
Red Hat Marketing to lend a big hand, but what else?
Concentrate on explaining the unsupported nature of Enterprise Extras, rather than trying to find a way to maintain them until the end of the RHEL support. After all, they are open source packages, if they are that valuable to a customer, the customer can pay their own team or a third-party to have them maintained/contribute to ongoing maintenance, and probably at a decent value.
But... if we're offering something with absolutely *zero* maintenance guarantees, why would there be significant uptake on it? We may say that Fedora is 'unsupported' from a mission-critical deployment standpoint, but we do more or less guarantee that will be maintained, have security updates issues, etc.
It may be that Red Hat has to grow this part of its support organization, to help maintain legacy packages. Alternately, we succeed in our mission of dragging these organizations into the open source era and they maintain their own packages.
1. Who updates Enterprise Extras in 2012 when there is a security update?
While people want builds of stuff for RHEL 4 and RHEL 3 now, are they still going to be interested in upkeep of RHEL 3 packages in 2010? If not, how do you differentiate them as such? This is basically the Extras legacy problem writ large.
One answer is that bringing larger organizations (academia, corporations, governments) into reliance upon Extras packages also brings them in as a resource for ongoing maintenance. Advantage of open source, a maintainer can leave but if it is valuable enough, you can pay for it to be maintained. One of the major goals of Developer Nation is to guide and teach these open source newbie organizaitions how to use FLOSS best practices internally and externally.
1. Concerns over using the Fedora Extras buildsystem because there are going to be vastly different requirements on how things are "released" as well as resource contention
Red Hat may need to provide (more) hardware and sysops.
1. Extras maintainers are already concerned about inability to test on older releases -- how can they test on RHEL which many of them don't even have access to?
Do we require a maintainer to help with the package who comes with access to the appropriate versions? In other words, only maintain where there is a version?
1. What to do about different architectures?
Could start with what we have (x86, x86_64, PPC), and grow from there according to demand. IHVs may put their own hardware into the 'pool' to spur package maintenance.
1. How to interact with repackager maintainers?
1. Different POV for package deployments, for example, with RHEL, you arguably don't want the same 'upgrade all releases to latest and greatest' that you'd get with the Fedora model.
1. Which developers are we trying to attract? Some people would be into this because they're running RHEL boxes and want their stuff available on RHEL. There are other people who package for Fedora Extras that don't run any RHEL boxes, and so wouldn't be contributing out of any particular self-interest. How do we motivate those people?
This is closely tied in with who are the users of these packages.
Must be a higher set than just the developers themselves.
Initially -- existing FE packagers who want their package(s) included, and support/activity from system administrators who want those packages available.
Soon After -- some early-adopter Red Hat partners (big IHV, ISVs) might be interested here, we'll certainly be trying to get their attention; other early-adopter open source developer shops and smaller ISVs; RHEL et al system administrators and users.
Middling -- more ISVs and IHVs are maintaining; customers and users of additional distros in Extras.
Eventually -- the world!
1. How far back in RHEL versions should there be packages for?
Red Hat Enterprise Linux 4 or later.
1. Multiple maintainers serves the needs of providing redudancy and coverage for packages, as well as being a method to cover multiple distributions. Make sure that our solution covers both needs.