| 1 |
>>>In my humble opinion, Gentoo is missing too many points to be an |
| 2 |
>>>enterprise Linux. We commit to a live tree. We don't have true QA, |
| 3 |
>>>testing or tinderbox. We don't have paid staff, alpha/beta/rc cycles. |
| 4 |
>>>We don't really have product lifecycles, since we don't generally |
| 5 |
>>>backport fixes to older versions, requiring instead for people to |
| 6 |
>>>update to a more recent release. We don't have, and probably will |
| 7 |
>>>never be able to offer, support contracts. We support as wide a range |
| 8 |
>>>of hardware as the upstream kernel, plus hardware that requires |
| 9 |
>>>external drivers; we don't have access to a great deal of the hardware |
| 10 |
>>>for which we provide drivers. We understand when real life gets in |
| 11 |
>>>the way of bug-fixing, because all our developers are volunteers. |
| 12 |
>> |
| 13 |
>>QA is a problem. Bugs get fixed, but often they are only fixed in ~x86 |
| 14 |
>>versions, not in the stable x86 series. For example baselayout: there |
| 15 |
>>are lot of ~x86 - miles ahead of that is marked x86. Maintainers think, |
| 16 |
>>it's sufficient to only fix the most recent version. How do they |
| 17 |
>>legitimate that? |
| 18 |
> |
| 19 |
> This one is easy. A stable package's ebuild should not change. Period. |
| 20 |
|
| 21 |
I agree with you there - though sometimes, stable ebuilds are changed - |
| 22 |
even without changing the version-number. |
| 23 |
|
| 24 |
> To "fix" the stable version, means that a new revision of the latest |
| 25 |
> stable version would need to be made, and that revision would need to be |
| 26 |
> tested, before it would go to stable. The only real exception to this |
| 27 |
> is security bugs. Also, in many cases, the bug in question requires |
| 28 |
> changes that are simply not feasible easily in the current stable |
| 29 |
> version, but quite easy in the latest version. It really boils down to |
| 30 |
> this: If you're having an issue with a package in Gentoo and it is |
| 31 |
> fixed in the latest ~arch version, then you should *use* the ~arch |
| 32 |
> version (remember, it doesn't mean "unstable" it means "testing") and |
| 33 |
> you should report back to the maintainers that this is working for you |
| 34 |
> so that they can get it moved into stable quicker. We don't have the |
| 35 |
> staff or the time to backport every fix to every stable version. |
| 36 |
> Remember that in many cases the "latest stable" version varies between |
| 37 |
> architectures. |
| 38 |
|
| 39 |
I chose baselayout for a particular reason. There is baselayout 1.9, |
| 40 |
1.11 and 1.12. (i think there was 1.10 too - some time ago - perhaps) |
| 41 |
|
| 42 |
I i reported bugs - as usual - but the bug was fixed for 1.11 or 1.12 (i |
| 43 |
can't remeber, it was about a year ago). The problem: the fix was not |
| 44 |
backported to 1.9 (which was stable at that time). Since baselayout is a |
| 45 |
very important part of Gentoo, i didn't think that it would be a good |
| 46 |
idea, to upgrade my x86-version 1.9 to a ~x86-version 1.11. So i would |
| 47 |
have expected that such changes would go into a new 1.9-version which |
| 48 |
could have become stable after some testing - but they didn't. So |
| 49 |
patches the scripts manually - well, and easy task, although i had to |
| 50 |
pay attention so they my changes weren't overwritten. |
Archives