I'm baffled at best by their mentality... even in the past, it was shocking how at times the edge, current, release and sometimes even the stable version were all the same build (1 build number difference between them which most probably means zero changes except for building it to the different trees). But the last couple of days were the "best" this far, after months without a single update to the Release branch, there were new Release builds every night. I am asking myself, why do they create 4 different branches if their own developers don't seem to be able to grasp the meaning of all this? :smash:

I think CPanel has catching up to do... I mean look at...

buildapache2-ALPHA_TESTERS_ONLY.tar.gz (Mon Aug 18 19:47:12 2003)

2003?? How much longer do we have to wait for Apache2?

cPanel has a huge number of unfinished or buggy parts and instead of taking care of them DarkOrb is constantly working on new ones like the Fantastico-competitor I just read about yesterday. This is a sorry state of affairs. :(

I agree.

When I was initially told about the "cpAddons" concept, I thought it was a good idea. (Well, it still is a good idea. Just a very poorly executed good idea.)

But now I realize they didn't hire more programmers to work on it.. they merely diverted existing resources to work on it.

So now we have now is yet another buggy cpanel "feature" that few people will ever use for at least another year once the bugs are worked out. (Not to mention that many many cpanel hosts already use fantastico and have little intention to stop...)

I can't help but think the 30 or so bugs and feature requests we've submitted into their "ticket system" over the last two years would have been a better investment of their time.

Whomever owns cpanel is NOT a business person, that's for sure.

One day that person is going to wake up and wonder what ever happened to their lock on the market.

Either that, or the owner is incredibly rich and just doesn't give a fart as long as the cash cow continues to pay.

DirectAdmin could do well if they'd ever get their marketing act together.

I also think it's a bit slow lately... but as far as updates that end up screwing the system I've seen less of those. What I would like in Cpanel is a built in way to limit users to a maximum amount of CPU and RAM and better load monitoring, say a process is using lots of resources for a long period Cpanel could email the admin to let him know (other than when it's trying to run stats). I did this manually but it wouldn't be hard for cpanel to actually include this in chkdserv or something.

Work on the basic features Web Hosts want and then you can work on add-ons... but as a web host I give a lot more importance to the stability and security of a server than having the ability to install phpbb from the click of a mouse.

I also think it's a bit slow lately... but I've seen less "f*ck ups" following updates than in the past (maybe because there aren't any hehe). What I would like in Cpanel is a built in way to limit users to a maximum amount of CPU and RAM and better load monitoring, say a process is using lots of resources for a long period Cpanel could email the admin to let him know (other than when it's trying to run stats). I did this manually but it wouldn't be hard for cpanel to actually include this in chkdserv or something.

Work on the basic features Web Hosts want and then you can work on add-ons... but as a web host I give a lot more importance to the stability and security of a server than having the ability to install phpbb from the click of a mouse.

i dont know how they get by with charging what they do, but then offering only forum board support.

i dont know how they get by with charging what they do, but then offering only forum board support.
That's easy. We pay them.

If we stopped paying them, they'd lower their prices and/or start listening to their customers.

well we certainly wouldnt want them to start listening to us!

ummm.... support@cpanel.net works too, I believe ;).

i dont know how they get by with charging what they do, but then offering only forum board support.

Hi Folks, I'm going to try to address all issues in this thread, firstly, we offer a very extensive support option for every cpanel client. As a matter of fact, the forums are not a support option. We have a fully staffed support desk available here (http://support.cpanel.net) or through WHM, and available to our Partner NOCs, through the manage2 interface. Our support staff is grown incredibly over the past 12 months.

But now I realize they didn't hire more programmers to work on it.. they merely diverted existing resources to work on it.

The developer who leads the cPaddons project is dedicated exclusively to this project (although the project has hit release status now). This was his first project with cPanel, although he was with the company prior, he was not diverted from other development resources.

If you have any concerns with the cpaddons project, please do not hesitate to let me know. If you're looking for more scripts to be added, this process will begin within the next 14 days, although I do know we have one third party vender who has roughly 50-60 scripts available for cpaddons already (cpskins.com).


I am asking myself, why do they create 4 different branches if their own developers don't seem to be able to grasp the meaning of all this?

Not sure what the concern here is. Here's a basic overview of how our build system currently works:

Beta - mostly internal/QA, we do not recommend or even make it easily possible to use this build.
Edge - Already either through QA, or in last stages of QA.
Current - Has been tested in QA, however, does not have ample 'production' testing yet.
Release - We feel features/etc are ready for production use
Stable - has been through most testing.

With this said, it took us 4-6 months to feel comfortable with building a release due to the amount of new features and bug fixes done. However, once this release was done, and properly tested, we pushed a few more releases out which included minor bug fixes that did not require extensive QA testing, therefore, our development team was comfortable making the process from edge->release shorter.

I hope this clears up some confusion, please do not hesitate to PM or email me if you have any questions at all. I'm here as your liaison/advocate. That's my duty. :)

ummm.... support@cpanel.net works too, I believe ;).

Our support procedures can be found on http://support.cpanel.net, they include:

Please submit all direct support requests from your manage interface (Support), through WHM (Support Center), or from the cPanel Store (Manage Licenses). All requests submitted through one of the aforementioned interfaces will be given high priority. If you do not have access to one of the above interfaces, you may submit a request below. Any request submitted below will be given low priority unless a valid Support Access Number is entered in the form.

With the above said, our support team has grown tremendously in the past 12 months, our development team as well is growing by the month. Admittingly, it's a hard process finding perl developers we feel meet the cPanel standards, however, we have added 2 additional development team members starting next week, an additional QA member, and additional technical support members all in the past 30 days.

We are growing to meet your needs. Our Houston office was opened roughy 12 months ago in order to support the growth needed in our technical support and development teams.

I think CPanel has catching up to do... I mean look at...

buildapache2-ALPHA_TESTERS_ONLY.tar.gz (Mon Aug 18 19:47:12 2003)

2003?? How much longer do we have to wait for Apache2?

Admittingly, this 'alpha test' should have been removed from our site years ago, however, as our web/design team has been working on a completely revamped and update site, it hasn't.

Although, to directly answer your question, not long. Apache2 support is done, and in QA stages. Instead of simply pushing our apache2 support, we decided to completely revamp the EasyApache system to address many of your concerns. I expect to see it in EDGE within the next 10-14 days at most, hopefully much sooner.

Thank you for your patience, it'll be very worthwhile.

Hey Nick any plans at cpanel to support NAS or SAN so that cpanel can be scaled to a load balanced set up any time soon?

Clustering is in the future, however, will not become a priority immediately as we've focused on bug fixes, and coming up to date with many of the other more minor feature requests.

However, when clustering is done, this will be one of the features. I can't yet give a solid ETA.

Good to hear it straight from cPanel what is going on and what is coming soon. Sometimes you wonder after awhile what is happening when you don't hear about any changes/updates.

Not sure what the concern here is. Here's a basic overview of how our build system currently works:

Beta - mostly internal/QA, we do not recommend or even make it easily possible to use this build.
Edge - Already either through QA, or in last stages of QA.
Current - Has been tested in QA, however, does not have ample 'production' testing yet.
Release - We feel features/etc are ready for production use
Stable - has been through most testing.

With this said, it took us 4-6 months to feel comfortable with building a release due to the amount of new features and bug fixes done. However, once this release was done, and properly tested, we pushed a few more releases out which included minor bug fixes that did not require extensive QA testing, therefore, our development team was comfortable making the process from edge->release shorter.

I strongly think that the time frame between a CURRENT and a RELEASE build must be at least 48 hours so that reports of server owners actually have time to come in. Else the distinction between these builds is non-existent. What kind of a "production" testing can be done if you push them out with a couple of hours difference? I still vividly remember the case of 10.6.0-R147 when I spent literally hours trying to solve a Fantastico problem working together with Netenberg, just to find out it wasn't a Fantastico problem - and I couldn't do anything about it because not only RELEASE, but also CURRENT and even EDGE were within the same couple of hours, nearly identical build numbers --- all of them containing the same bug. Until it was fixed in R158 the following day, there was no way to provide promised services to my customers, they had to live for a day w/o Fantastico, through no fault of my own (or even Netenberg's).

What was even more shocking, when I posted about this on the cPanel forums to warn other people, I was jumped by moderators. Also, at no point did anyone from the cPanel team or any of the changelog entries talk about this bugfix, it was swept under the rug. And after this incident, similar "build frenzies" did occur again, showing that the development policy didn't change. And the R series from last week I posted about at the beginning of this thread is the very same mentality all over again.

I strongly think that the time frame between a CURRENT and a RELEASE build must be at least 48 hours so that reports of server owners actually have time to come in.

It depends on the changes. If there is 1 bug fix between the two builds, there is no need to wait that long. There was weeks initially between the current and release, and then a few releases were pushed out pretty quickly, but each of these only included a few bug fixes. We rather do this than push out one new version every 4 months.

I still vividly remember the case of 10.6.0-R147 when I spent literally hours trying to solve a Fantastico problem working together with Netenberg, just to find out it wasn't a Fantastico problem - and I couldn't do anything about it because not only RELEASE, but also CURRENT and even EDGE were within the same couple of hours, nearly identical build numbers --- all of them containing the same bug. Until it was fixed in R158 the following day, there was no way to provide promised services to my customers, they had to live for a day w/o Fantastico, through no fault of my own (or even Netenberg's).

This was 6 months ago. I can't pull up record of such bug exactly, only see forum posts.


What was even more shocking, when I posted about this on the cPanel forums to warn other people, I was jumped by moderators. Also, at no point did anyone from the cPanel team or any of the changelog entries talk about this bugfix, it was swept under the rug. And after this incident, similar "build frenzies" did occur again, showing that the development policy didn't change. And the R series from last week I posted about at the beginning of this thread is the very same mentality all over again.

Our lead developer at the time posted directly to you regarding not being able to reproduce the bug. (forum post (http://forums.cpanel.net/showthread.php?t=43456&highlight=R147)).

However, as said, the RELEASE was not pushed out for nearly 3-6 months. Once pushed out, a few bugs were found (many customers only run RELEASE and there is frequently bugs that are very isolated.). It's not fair to make a customer live with a bug (no matter how isolated) for 6 months until we push out another release.

I assure you EVERY release pushed out in the past week included very few lines of code changes. Nothing that risked any harm, they were all very simple bug fixes, no new features, nothing that our development team felt justified more QA time then was issued.

Our build and development process has changed and improved over the past 6 months. As you could see by the fact it took 3-4 months to push the CURRENT to RELEASE. Granted a few bugs were found in the RELEASE when it was pushed, but those were quickly patched, and the patches were pushed up the chain.

Now, as a result of this thread, we will discuss in our weekly meeting having a much more detailed changelog as to comfort your fears that more changes are being made between these pushes of releases then should be.

Also it sounds to me, like you should be running STABLE instead of RELEASE. :)

I like it that you listen to what people say in this thread and consider changing internal processes. :) As for running STABLE, I did that back in 2002/2003 but in the end I gave up on it because it was too often too far behind the RELEASE build. I'd be most comfortable with a RELEASE that comes every couple of weeks or at times a bit more often, and I'd be interested in the STABLE branch again if it'd have a release cycle that's not longer than a month.

A question regarding this, are these different release types actually different branches in the CVS repository, meaning you can e.g. push out a STABLE today that contains no new code since, say, last month, although there've been three RELEASE and five CURRENT releases in the meantime? Or is it all one tree and if you make a STABLE release at any given time, it includes all the code that's been released in previous builds, no matter what branch?

I like it that you listen to what people say in this thread and consider changing internal processes. :) As for running STABLE, I did that back in 2002/2003 but in the end I gave up on it because it was too often too far behind the RELEASE build. I'd be most comfortable with a RELEASE that comes every couple of weeks or at times a bit more often, and I'd be interested in the STABLE branch again if it'd have a release cycle that's not longer than a month.

A question regarding this, are these different release types actually different branches in the CVS repository, meaning you can e.g. push out a STABLE today that contains no new code since, say, last month, although there've been three RELEASE and five CURRENT releases in the meantime? Or is it all one tree and if you make a STABLE release at any given time, it includes all the code that's been released in previous builds, no matter what branch?

No. Each patch must go through BETA -> EDGE -> CURRENT -> RELEASE -> STABLE. A patch can not be entered directly into CURRENT. Most often, when it is time to push out a new RELEASE, there is a complete code freeze, barring any patches. That way when we push a patch through the chain, there are no other code changes involved.

We're here to listen and improve.