Thank you for the objective reply. I realize I've been on a tangent today. And it's mostly caused by outside influences. However, since the conversation is open: ;)
Todd Lyons wrote:
Which was exactly my point. The version point releases need to be just that. Point releases. Bug fixes, and security rapairs, etc. Not content changes. Leave the content changes to the major revision rolls. So, you are only dealing with a finite set of problems at a time. Then, you can dedicate a 6 month block of time to getting the bugs out of 9.0, to release 9.1, which is exactly that. A point release of 9.0.-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tibbetts, Ric wrote on Tue, Feb 25, 2003 at 12:15:56PM -0500 :
Mandrake on the other hand, insists on trying to match Redhats release schedule, but they're including major content changes in a point release, and they're beating themselves up trying to keep up.
Mandrake releases X.0, X.1, X.2. Then it jumps to Y.0, Y.1, Y.2. It has nothing to do with "point" releases or "version" releases. Technically, they are ALL "version" releases.
Once 9.x series is stable, THEN start developing the 10.x series. Put the new content in there. And spend the next couple of point releases bug fixing, and such to that.
Yes, SOME content can be slipped in to a point release. But the core needs to remain fixed, so you can get it stable.
Otherwise you're working around the clock, trying to track a zillion bugs, and interdependancy problems, as you keep changing the tires on the buggy while you're driving it.
Again, that's just my humble opinion. But I've worked around enough development projects to know the drill.
But I still see them making the same mistakes. Rushed releases, with too much content change to be controlable in such short cycles. They're
Back around the time of 6.x, there was one CD for Main and one CD for Contrib. Now all of Main won't fit on three CD's, and Contrib is about the same.
Which is again, exactly why you can't try to change ALL of it, EVERY release.
See my point above. That could be remedied. Mandrake needs to address their project management, configuration management, and version control. You can do as much with far less effort with good management practices.
IMHO, if there has been any one failure of Mandrake, it's been the inability to say "No, we won't put that in Main." The attempt to be everything to everybody requires more manpower than we have, resulting in everybody pulling 60-80 hour weeks trying to get things to a cohesive point.
Yup, I understand that they're trying to meet with a competitive market, and meet customer demands. But... The customer is ALWAYS going to want the latest & greatest software, whether it's stable or not. And THEY WANT IT STABLE. Well, it can't always be done. Mandrake needs to learn when to say no.
You're approaching it from a slightly different angle, but you arrive at nearly the same conclusion.
The general feel about Mandrake around the people, and companies I work around is not good. If a Linux box is built, it's Redhat. Why? Stable releases, Stable company.
Yes, in the US, RedHat is the brand that's known and that's what we're trying to address.
And believe me Todd. I'm actually not just trying to attack. I was actually intending to offer suggestions that just might help.
I've been running Mandrake for a couple of years now. And in all honesty, I will probably continue to do so.
Ric
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
