| 1 |
On Tue, 2004-08-10 at 16:19, Chris Bainbridge wrote: |
| 2 |
> Ok I've been following this thread for a while and have a few observations and |
| 3 |
> a cheeky proposal. Observations: |
| 4 |
> |
| 5 |
> * I don't believe gentoo has many developers who are interested in supporting |
| 6 |
> "old" software. It just doesn't scratch the itch. |
| 7 |
|
| 8 |
Agreed. |
| 9 |
|
| 10 |
> * We don't have the resources to backport security fixes either. Upgrading is |
| 11 |
> not an option for many enterprises, they want backports. Someone mentioned |
| 12 |
> grabbing fixes from other distros... fine, but what if the versions differ? |
| 13 |
|
| 14 |
Fix it for the version in question. It's usually a lot easier to fix a |
| 15 |
broken patch than to discover and patch a problem yourself. |
| 16 |
|
| 17 |
> What about major non-security bug fixes? |
| 18 |
|
| 19 |
This hasn't been discussed. Personally, I think any fix that doesn't |
| 20 |
alter functionality (typo fixes, bug fixes) or add new features is |
| 21 |
fine. Some people will want security fixes and nothing else. |
| 22 |
|
| 23 |
> * A 1 year support cycle isn't long enough for enterprise users. |
| 24 |
|
| 25 |
We're not talking about commercial support here. Also, we aren't |
| 26 |
talking about providing *any* semblance of support. The idea is to get |
| 27 |
a tree out there, as that seems to be enough to satisfy a large number |
| 28 |
of people. Perhaps having the tree out there will bring forth more |
| 29 |
help. Perhaps it'll bring about an interested third party willing to |
| 30 |
offer commercial support. Perhaps it'll bring about nothing. No matter |
| 31 |
what the outcome, it doesn't cost us much in time, and it satisfies a |
| 32 |
good number of our users, so we should do it. |
| 33 |
|
| 34 |
> * Redhat has the resources to run enterprise support. They do backports and |
| 35 |
> bugfixes. For years. |
| 36 |
|
| 37 |
No argument here... They will fix whatever you want, provided you "show |
| 38 |
them the money", so to speak. |
| 39 |
|
| 40 |
> * Redhat is the standard for enterprise linux (if you want oracle, eda |
| 41 |
> software etc.). Many companies don't even test on anything else. I have a |
| 42 |
> stack of commercial chip design software here, and all of it is redhat only. |
| 43 |
|
| 44 |
I'll agree here, too. |
| 45 |
|
| 46 |
> So heres the cheeky proposal... make a "redhat" release. Follow redhats |
| 47 |
> release cycle, and match their versions. Use their backported fixes. |
| 48 |
> Commercial software will work. Bugs will be fixed. This is the power of open |
| 49 |
> source. |
| 50 |
|
| 51 |
Why? So users can have portage and the "commercial vendors" will still |
| 52 |
release their stuff in RPM only and expect the exact same libraries of |
| 53 |
the same versions to be installed with the same features as Red Hat. |
| 54 |
Are you also wanting to get rid of USE flags? How about CFLAGS? To be |
| 55 |
able to ensure Red Hat compatibility, both of those would have to be |
| 56 |
standardized to be exactly like Red Hat's. This means CFLAGS would be |
| 57 |
what Red Hat uses and we would compile with the same ./configure options |
| 58 |
on each package. At that point, we're wasting an enormous amount of |
| 59 |
time trying to be Red Hat, and no time trying to make Gentoo better. |
| 60 |
|
| 61 |
-- |
| 62 |
Chris Gianelloni |
| 63 |
Release Engineering QA Manager/Games Developer |
| 64 |
Gentoo Linux |
| 65 |
|
| 66 |
Is your power animal a penguin? |
Archives