Progress update - To D6, or not to D6

I am a strong supporter of staying with Drupal 5 at this point. We are going to have some refactoring to do, mostly in the backend, for 0.2. A lot of instability have been introduced on HEAD because of that refactoring, and having Drush as a moving target doesn't help either. So adding into the mix a port to D6 would probably be explosive.

The way I see it, Hostmaster should be able to bootstrap, deploy and upgrade itself. The major new feature in 0.2 is to have multiple platform support, which includes upgrades, so I expect 0.2 to be able to upgrade itself. That's an excellent test of the API of the coherence of a system. I compare this to writing compilers: a good and complete compiler should be able to compile its own source code.

I am sensitive to the arguments brought in for the D6 upgrade, but I feel there's a counterpoint for every one presented so far:

• 0.2 as a required upgrade path: i think this is necessary anyways. 0.1 platforms can't be migrated to 0.2 platforms, so people should be expected to stop by 0.2 to go ahead with the other milestones. Besides, I don't think 0.1 has such wide adoption yet, so that's not a big issue (although it could be if we delay 0.2 because, for example, of a d6 port :P).
• kludges in Hosting and Hosting wizard: those kludges are there now and they work. Porting them to D6 is going to require extra work that should be better spent in improving the backend.
• new features in hosting will need to be ported: of all (13 right now) the critical issues targeted for the 0.2 release, only two really relate to new features in hosting: package dependency checking and platform creation automation, both of which probably will not require much extra work to port to D6. So I don't think the potential instability is worth the risk there either.

I understand that work already has started on this, so maybe all those points are moot and we should just bite the bullet already, but at the very minimum, we should not maintain two branches. I would be very strongly against splitting the tree again, unless absolutely necessary, and I don't feel it is now. If we jump to D6, we jump forever.

I am a strong supporter of frequent releases and I think we should concentrate on getting 0.2 out as soon as possible now, without extra gizmos and bells and whistles. I feel that we have much more important rearchitecture changes to do than a d6 port, the server abstraction comes to mind immediatly. Those are the real roadmap blockers in my opinion, not the D6 port, unless we really expect the hosting code to grow more and more in directions that will add more and more time to the D6 port.

... then it sounds like polishing D5 is a better route.

BUT ... identify THE feature or requirement where moving to D6 means cleaner code. Basically, at that point, the D5 branch is locked, and new development occurs on D6. Then, when anyone asks "when is feature X going to be implemented?", you can point to the decision that moves to D6.

Speaking as a wannabe Aegir end-user and not as an Aegir developer (but as someone with a software engineering background)…

It’s not that difficult to install D5 only to run the Aegir front-end, and if that strategy leads to fewer code branches to maintain, then it might result in faster development of the Aegir system with fewer errors overall.

On the other hand, i am inclined to hold off deploying Aegir until a stable D6 front-end solution is available. Not only is that easier and cleaner on my end, but it sounds like the Aegir code will be cleaner as well (with all those kludges and hacks vanquished). So i am hesitant to deploy a D5 Aegir front-end, even though it is able to support deployment of D5, D6 & D7 sites. I worry about those aforementioned kludges, and the pain i’ll go through when upgrading later. D6 has (finally) come of age, and it is definitely time to retire D5 ASAP.

If my vote matters, then it is cast in whatever direction leads to the quickest path to a stable, mature D6 front-end.

Is that keeping the D5 front end for the 0.2 release allows us to develop the new features on a solid base, instead of a constantly shifting one.

The 'kludges and hacks' i referred to were essentially API's I had to invent to solve problems that were already solved in Drupal 6.

As with our 0.2 release, we will be focusing on standardizing on upstream API's, as ease of maintenance is of big importance to us. We are making excellent headway toward deeply integrating with Drush for this release, reducing the amount of custom code we use and reaching a point where all Drush commands will be able to be integrated into Aegir, and vice versa. (say hello to integration with drupal cvs and ala cart module installation, via the drush pm command set .. for instance)

Another good reason for sticking to D5 at the moment, is that we are very close to being self hosting. Which means that the 0.1 -> 0.2 upgrade will be the last one where you have to do actual manual intervention.

By keeping the 0.1 to 0.2 upgrade on the same version, we reduce the complexity of the problem (ie: you won't be upgrading drupal at the same time, just replacing the hostmaster profile, downloading the new drush and provision and running update.php).

After that point, you should be able to upgrade your Hostmaster in almost exactly the same way as any of your other sites (ie: drush.php provision migrate hostmastersite.com /new/release/of/drupal).

The amount of progress we are making is really astonishing, and when we talk about an 0.2 release, we are talking about a matter of weeks. If we had to roll in the 0.3 update that timeline could escalate into months.

So we're sticking to 'release early, release often'.

--
The future is so Bryght, I have to wear shades.