Discussion on: more stable than stable

[Drysh]

First of all, read GLEP 19. Then read around the forums and notice how many complains we have about gentoo not being stable enough for a working enviroment. Let's stop complainning and help with this problem.

I imagine an alternative to GLEP 19: A frozen gentoo. Most of the probelms arrive from the fact that gentoo doesn't have releases, so it will always be harder to make it stable. When you are managing a lot of boxes, you need something that's more predictable than gentoo, that won't update things randomly (when they reach stable) but will keep a defined version of each package.

The idea, and I'll call it +arch (we have -arch ~arch and arch, +arch is the next logical step), is to freeze the distfiles twice a year. For the date, I suggest using 1st july and 1st january.

- Default to arch, if the user needs something more predictable, change ACCEPT_KEYWORDS to +arch.
- On the 1st july and 1st january, a script would mark avery package that is in the stable tree (arch) as +arch.
- Aditional packages could be manualy added to the +arch tree, if they meet the following: are only new releases (security updates, bug fixes), not new versions; are proven to be absolutely bug free (well, if you ever manage to do that you deserve to be included); or they are dependancies of stable packages that were included in +arch but failed to be added as well.

Why I'm proposing this? Because I want that more stable than stable version, that has a predictable update cycle, but I don't want to "steal" people from the main development. This should be easier than what GLEP 19 proposes.

Ideas? Questions? Suggestions? Rants? Anything?

[NeddySeagoon]

Drysh,

You can already do this if you wish - only run

[Hauser]

[NeddySeagoon]

Hauser,

I saw that in the post too - but it also mentioned fixed dates.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Drysh]

If I "emerge -uD world" I'll get the last updates for every package. What I mean is to have a fixed date, and those who need extra stability would only get security and bug fixes, not upgrades.

That mean I'll have the source for every package I have still in gentoo (no old packages droped), and I'll be sure that all computers use the same versions. "emerge -DNuva world" is simple if you are talking about a single box (or 2 or 3) but when you are managing more than 20 boxes it becomes impossible to use gentoo. Having a frozen distfile, you could iron out the bugs and use the same version in all machines.

GLEP 19 is too far away to become a reality (and I think it never will) because it "steals" men-power from the main thing (that is from arch tree). This alternative doesn't. The development of +arch (bug fix / security update) is already done, but it's hard to tell wich package has a bug fix / security update and wich is a new version that may break things in a critical server. We have to many updates of "useless" things that won't change the way a box works but may break things (example: libraries that run faster won't make a huge diference, but they may break a obscure package that may have been instaled manualy). I would like to get the new versions, but only when I have time to fix things in case something goes wrong.

I'm tired of having to use a release based distro when gentoo works better. The only problem is that it's easier to manage the first than gentoo. A frozen tree would take the best of both worlds, and something extra: with fixed dates we could plan ahead when we will update the machines.

[NeddySeagoon]

Drysh,

Ah ... I see. You would have twice yearly 'releases' with security updates only, in between.
Packages in these releases may be older than the 'stable' branch too.

Its a good idea and as you say, could lead to the wider uptake of Gentoo.
I'm not sure how you would implement it, other than the GLEP you cited.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[omp]

Good idea, but AFAIK, ACCEPT_KEYWORDS="+arch" wouldn't be the way to do it because if I understand it, correctly that would still accept everything using the default keyword.

Also, + is already used for the default 'arch' as you call it. If you look on packages.gentoo.org, you will see that ~ denotes testing and + denotes stable.

[rokstar83]

Definetly a good idea, although just to nit pick I would prefer a quarterly upgrade vs semi-anual. The question is, is this the where people would like gentoo to go. I don't want to start a flame war but gentoo at the current moment seems to me to be more of a hobby distro. Don't get me wrong, I love it and use it for my two computers, however there is quite a bit of micromanagement involved (more than other distros). This is not the ideal type of distro (currently) for a enterprise environment/server farm/mission critcal systems. Can it work? Sure, but its probably going to drive a sys-admin nuts trying to maintain it for more than a handful of systems. I think the flexibility of gentoo certainetly could allow for such a think to happen without a fork but it would require new maintainers and admins. Personally I think man power is the issue that might cause this to fail. But hey its a great idea and i'd love to help. Gentoo is still below the radar for a lot of people, I think that is something that should change.

[Centinul]

I believe that this is something that can be done with current tools. Like someone said above you have the emerge --sync && emerge -uD world option. But there is also glsa-check for security related issues. I envision using this periodically and then a couple times a year using the emerge commands above. I think it is easier to do that then to use the idea of snapshots. I believe snapshots is not where Gentoo is heading since it's considered a metadistribution. Just my two cents

[rokstar83]

[Centinul]

The reason I mentioned it (although I didn't say it in my prevous post) is that I think time and effort should go into getting glsa-check out of beta instead of working on GLEP 19. This has already had a lot of effort put into it and I'm sure everyone (including server admins) would love to have this option and not have to worry about it being unstable

[rokstar83]

glsa-check would be a wonderful tool and I agree that many people would find it useful, however I think (and please correct me if i'm wrong) that Drysh meant more than just creating a means to update security and bux fixes. I think the point is that there are many packages and dependancies that do not belong in what is now considered stable atleast in the workplace sense. The definition of stable goes beyond packages that don't work properly by their lonesome but instead any entire tree of packages that doesn't colide or bork each other. This tree would remain constant and not be updated until the next release date. This would allow for more long term stability as systems will not upgrade to newer version until the tree is tested to be stable with the new versions. In the mean time a utility like glsa-check would allow people to update their systems with the security patches without updating to newer versions.

Unfortunetly this goes against in some ways what gentoo is. It would remove some of the flexibility in order to create stability. Gentoo is a distribution that allows the user to have the latest and greatest in the way of software packages which is not nessessarily what people want in a work environment where stability is the paramount issue. So the question comes back to, is this a direction that gentoo wants to go and thats a question i know i'm not qualified to answer.

[Sven Vermeulen]

Actually implemening something similar isn't all that difficult, but it does require manpower (doesn't have to be "much" manpower depending on your needs).

For instance, companies that use Gentoo workstations might want to "support" only a fraction of the software that Gentoo offers. Those companies can manage their own repository easily. They need to know what software they use (check /var/db/pkg on a fully installed system) and keep track of security/stability improvements. They don't even have to do much ebuild hacking - in most cases they can use the ebuilds that Gentoo provides, albeit sometimes with some fiddling on the DEPEND settings.

Such method isn't too resource consuming - after all, the Gentoo workstation they support will probably only run one kernel for all machines, one graphical environment, ...
_________________
Please add "[solved]" to the initial topic title when it is solved.

[pjp]

Sven:

While that could be done, it does add a not insignificant amount of effort (maintaining a seperate tree). Obviously this would be good for a short term solution, or if the needs justified the effort. However, is there a practical/technical reason -- other than insufficient developers -- to not implement something like this with "official support?"
_________________
Quis separabit? Quo animo?

[Sven Vermeulen]

Politics?

Not only the number of developers should be taken in account, also the discussions about how often the set is updated, what can be updated and what can not, what to be included in the set and what not, if USE flags should be frozen or not, etc.

Most developers are also not really waiting for this to happen. They rather update the ebuild to the latest version available. Not only because it is the latest version, but also because that version is deemed the most stable/important by the project itself. For instance, Mozilla Firefox 1.5 is out; its developers work around the clock to maintain the 1.5 version and keep it stable and secure.

If a Gentoo developer (or other project that offers some "stable tree") stays with the 1.0.7 version, how will he deal with the possible vulnerabilities that 1.0.7 might have? Either he fixes them himself by backporting the fixes from 1.5 (or developing his own fixes) or offers an upgrade to 1.5.

You might want to defend the upgrade "because of security issues", but then why would you still need a stable tree? If Gentoo's security mechanism (glsa-check currently) is improved and stabilized, then the first solution given in this thread (never emerge -uDN world but rather update security stuff only) is sufficient.
_________________
Please add "[solved]" to the initial topic title when it is solved.

[Genone]

[Drysh]

Genone:

I was saying that we ONLY freeze the distfiles. We don't need a separate developer team, nor a new tree. Only a frozen one. That's simple to do, and we could implement fast. After that we could work towards GLEP19 or something similar.

Example: On 1st january 2006 a script marks all arch as stable:arch (I'm using GLEP19 terms, since +arch already exists and is the same as arch). Lets say mypackage-1.0.0-r2 was in the stable tree (arch), then it will be marked stable:arch. After that, lets say 15th jan, the gentoo developers of mypackage create an ebuild for mypackage-1.0.0-r3 that only fixes some bugs. They may mark this release as stable:arch instead of arch, because it won't change the version, only fix some bugs. But if they release mypackage-1.0.1 they will have to wait untill july to mark that as stable:arch.

That's much less than GLEP19. It doesn't create a separate tree that needs to be maintained, it doesn't require extra manpower, and it doesn't take gentoo away from its mission. The point is that it's too hard to create a new tree, but if people starts using gentoo for critical systems, we may attract enough people that is interested in maintaining that new tree (GLEP 19).

How to:

- mark all packages that are arch as stable:arch twice a year (or 4 times/year wichever works better).
- let each developer choose if a new release should be marked as arch or stable:arch.
- let packages that are dependancies of the stable:arch be included as well when they become stable (arch).

- Attract new business that want to use gentoo for their computers.
- Maybe they will let their developers take a few hours to help keeping the stable:arch branch.
- Implement something like GLEP 19, but with more experience on how it will work, and with more support than we could have now.

I'm not against GLEP 19, I'm trying to find a way to implement it without hurting the rest of gentoo.

[NeddySeagoon]

Drysh,

You don't freeze the distfiles - you freeze the ebuilds. Its the ebuids that determine what distfiles are requred.
There will be extra work back porting security fixes into the 'snapshot' ebuilds, since versions of packages can have moved on and extra stable users will want the security without the other enhancemts - thats two version to maintain.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[96140]

Still, the problem with doing an update only once or twice a year is that it will be a massive update: in this case, you are far, far more likely to run into package breakages or configuration problems. A steady trickle of more minor updates means that you'll average fewer breakages, even with the more frequent increments of package versions. And, if necessary, it's a heck of a lot easier to downgrade from foo-1.0.2 to foo-1.0.1 than to go from foo-1.9.1 to foo-1.0.1. Just an example, but something to keep in mind.

And you wonder why other distros pretty much require a complete reinstall/upgrade twice a year and have problems and reports of things not working the same way, etc. Much better to do a larger amount of smaller updates than to just give yourself a completely new (possibly not working) system twice a year, with all the possible conflicts that entails.

[omp]

[Drysh]

Maybe that's not the best idea, but I'll explain why I was thinking about it.

My main problem when "selling" gentoo as a business solution isn't security because compared to other distros gentoo is far more secure than the average (linux) system (and some/most of them are using windows). The problem is that I cannot predict when it will be prone to fails due to an update. Most critical servers in business enviroment aren't war zone's machine, some are even in DMZ (I'm not talking about net business or tech business, but average midle sized old economy business). These business need reliable machines, not high security machines. Usualy there system has a firewall for that protection, dennying most services to the WZ; for that box I would use a normal gentoo.

I was imagining file servers for internal clients, office server, groupware servers (not connected to the internet, but only intranet), mail storage (imap), and things like that. They need to have security, but they don't need to be hacker-proof. But one thing they need is to be stable. The very nature of gentoo (no release cycle) makes it hard to use with those machines. I was also aiming desktop use of linux in coorporative enviroment -- sometimes a simple change of visual design of an application may cause troubles.

Not upgrading those machines isn't the ideal solution, because sometimes we need to set a new machine exactly like those of a client. Example: to test something he wants to implement, or to find out (without having access to his machines) how to fix a bug (or something he messed up). When someone buys a new box, we'll need to install a system with the same versions of the working software.

I'm not against GLEP 19, I want it to be implemented. This is not a solution, this is a bait to attract new developers. I think that creating a release cycle for gentoo may remove the limitation we have now when compared to other distros, but since this is what makes gentoo special, I'm trying to create a solution that will provide us the work force to have GLEP 19 (or something like it) without sacrificing the main thing about gentoo (the instant release cycle).

I believe that creating the choice of using a release cycle may attract those companies developing solution for business environment. I think the best way to implement that is by freezing a tree for 6 months (or 3 if you like), so they won't have to stay up to date with our last stable tree (that changes daily) to know what to expect. I hope that will make them look at gentoo with better eyes, not as a geek-oriented or expert oriented distro. Haven't you ever heard "Gentoo is great for you that knows everything about computers, but I cannot use it, because I cannot fix it when it breaks"? I heard it a lot, and it has been less than a year I'm here. I would set gentoo for my server any time, but I won't do it for someone else's computer, because I know they will panic at the next update they make.

Do you think companies that offer service of linux solution would eat this bait and help us with something like GLEP 19 to make it better? Would they give us developers (a few hours of their developers) to maintain a separate tree, if they see a working gentoo in an enviroment with no computer experts? Do you think we should, instead, implement GLEP 19 now, using the avaliable work force we have now? Which will be "less against" gentoo phylosophy?

Any better ideas?

[Sven Vermeulen]

[Sven Vermeulen]