Op vrijdag 9 juni 2006 08:25, schreef Dries Buytaert:

Thanks CivicSpace Labs. :)

There is also an installer patch in the patch queue.  (I don't have   the URL handy as I'm no the train.  Sorry.)  We need people to   carefully review and refine that patch.  This is an important part of   the next Drupal release, and it is our task to get it into Drupal   core.  CivicSpace Labs did their part; it up to _all_ _of_ _us_ now   to get it into core ...

I know I am not going to make myself popular. I know my proposal makes very little chance, bu trying anyway: Lets leave installers and profiles OUT of core for at least another release. Why: In contribs they can settle out. Become nice. Grow onto people. In contribs they can conpete. I still think that there are other ways that make just as well a candidate for core. My own sympal scripts are just one of the possibilities. we are now getting apt-get alike module installers in. Fixtures are still in the make. No! This is not a sneaky way to get my own installer and profile stuff higher on the ladder. This is just a way to sya: lets not stare blind on one solution. Lets leave the communities dynamics to decide. After a half year in contribs we can tell wich is best. We can include a MATURE system, one that has withstood several rounds of revisions and improvements. We all saw how well integrating an immature system such as forms api went. With respect to all those behind it, Drupal was not ready for such an immature system. Fact is that still; some rather critical elements are not sorted out well (files uploads required stuff). Views, CCK are all coming along in contribs just fine. I beleive views needs just another few months and it might prove ready for core. It is by far one of the most groundshaking improvements to Drupal, just not ready for core. If ever. Why stare blind on one install system that is not tested, not mature and has not proved to be the Right Solution? Why depend only on those that can review patches, when we have a huge reviewing organism called "contribs"? Only because the Mob demands install systems? If they do so, lets give it, in contribs. And let that Mob sort out what the best stuff is, what needs fixed and what should be changed. Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ] Drupal upgrade repareert kritiek beveiligingslek: http://help.sympal.nl/drupal_upgrade_repareert_kritiek_beveiligingslek

Op vrijdag 9 juni 2006 21:06, schreef Gabor Hojtsy:

Sometimes these replacements get into core in place of outdated stuff. This is how parts of CCK are hopefully going to get into core in place of story, page, etc modules. This does not mean story and page should not have been there, and we should have been waiting for (a simplified) CCK all along. Or does it?

Yes. But this time we are putting somthing in that has no equivalent yet. Somthing that is not proven to the The Right Way. Note that CCK is already a second revision (flexinode?) and still needs TLC as well as a lot of rounds of improvment. "There is no better test environment then the real world". (quoting no-one) Thing is: I investigated a lot of stuff before starting my sympal installer stuff, and my conclusion was twofold: There is *no* such thing as a safe online install system. Joomla, e.g. fails on a lot (I recieved a number of 1/4th) of servers. Only servers with a *lax* security program let Joomla install itself, and write its own code from the web. Plesk and brethren (and even .debs etc) rule the market of Small Sites. IMO Drupals People. I esitmated (wild guess) that over half of our Drupal installations are installed trough such systems. So: why not offer a plesk installer instead? Or even better: a way to make building a plesk-Drupal-instaler Very Easy. What is better: a button in plesk that says: "install Drupal" or a way to allow FTP-ing your site, browsing to some Secret URL, install your Drupal-With-Drupal? Again, I'd like to mention "staring blind". We should really move away from the idea that a web installer is crucial. And focus on the underlying issue: Make *deploying* Drupal very easy. That does not start and end with a web-based installer. That starts wtih a vision and a good founded "thing" to install Drupal. From whatever: Plesk, MyOSServerManager, debian, ubuntu, OSX app installers, Hell, even a .exe, or .msi would be grand, or a live CD, etc. But not by walking like geese behind all the other CMSes that have web based installers. Bèr

On Jun 9, 2006, at 11:54 AM, Bèr Kessels wrote:

Op vrijdag 9 juni 2006 08:25, schreef Dries Buytaert:

...

Thanks CivicSpace Labs. :)

There is also an installer patch in the patch queue. (I don't have the URL handy as I'm no the train. Sorry.) We need people to carefully review and refine that patch. This is an important part of the next Drupal release, and it is our task to get it into Drupal core. CivicSpace Labs did their part; it up to _all_ _of_ _us_ now to get it into core ...

I know I am not going to make myself popular. I know my proposal makes very little chance, bu trying anyway:

Lets leave installers and profiles OUT of core for at least another release.

Why: In contribs they can settle out. Become nice. Grow onto people.

CivicSpace, has had an installer for 18 months. It's been downloaded over 20, 000 times in the first few months of the year alone. It supports advanced configuration of over 30 contributed modules and even wraps 2 full other open source projects PHPList and CiviCRM. It handles multi-database installs and multi-site configuration. We have also debugged it live in dozens and dozens of different hosting environments and even video taped people installing it just to make sure it was as usable as possible.

In contribs they can conpete. I still think that there are other ways that make just as well a candidate for core. My own sympal scripts are just one of the possibilities. we are now getting apt-get alike module installers in. Fixtures are still in the make.

So you think the path to usability is through command line scripts? Have you ever actually watched someone who has never seen a command line in their life try to use the command line? I have, as part of the user research for this installer. I watched a sixteen year girl who was just learning how to use a computer install CivicSpace. Why? This installer is intended to make it possible so that even the least technically savvy people who would like a website have a chance to create and use a website. In this case, so they can write music lyrics and develop the skills to give themselves a better life. http://youthmovementrecords.com Send me a video of someone using the command line for the first time that you have watched. Then we can discuss how command line scripts will help us win in a battle of "the easiest to use CMS" wins. Not everyone will be able to afford a fully managed and hosted solution and they deserve a fighting chance to install Drupal. It's free software, as in free to use on your own server.

No! This is not a sneaky way to get my own installer and profile stuff higher on the ladder. This is just a way to sya: lets not stare blind on one solution.

We did a code review of the Wordpress installer, the CivicSpace installer, the Joomla installer before we wrote a single line of code for the new installer. We did a 40 page review of the main CMS installer's to compare on features and ensured we were state of the art: http://civicspacelabs.com/files/DrupalInstallerAnalysis.pdf. Then we worked with an existing Drupal provisioning system, Hostmaster, to ensure it's compatible.

Lets leave the communities dynamics to decide. After a half year in contribs we can tell wich is best. We can include a MATURE system, one that has withstood several rounds of revisions and improvements.

The installer was committed as a patch 2.5 months before 4.7 shipped where it's been available for public review.

We all saw how well integrating an immature system such as forms api went. With respect to all those behind it, Drupal was not ready for such an immature system. Fact is that still; some rather critical elements are not sorted out well (files uploads required stuff).

Views, CCK are all coming along in contribs just fine. I beleive views needs just another few months and it might prove ready for core. It is by far one of the most groundshaking improvements to Drupal, just not ready for core. If ever.

We re-wrote again from scratch after 18 months of live user testing.

Why stare blind on one install system that is not tested, not mature and has not proved to be the Right Solution? Why depend only on those that can review patches, when we have a huge reviewing organism called "contribs"? Only because the Mob demands install systems? If they do so, lets give it, in contribs. And let that Mob sort out what the best stuff is, what needs fixed and what should be changed.

Did you see how it has modified the Drupal bootstrap? Contributed modules are contributed, which means they rely on Drupal. The install profile system is one of the key features for the next release of Drupal. This has been stated publicly for months. Dries said it was the number one thing he wanted added to Drupal in the state of Drupal talk in Vancouver. Kieran

Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

Drupal upgrade repareert kritiek beveiligingslek: http://help.sympal.nl/ drupal_upgrade_repareert_kritiek_beveiligingslek

On 10 Jun 2006, at 12:14 AM, Dries Buytaert wrote:

Ideally, Ber's command line tools would be able to re-use parts of the installer (shared API). If that's not possible with the proposed install system, we should massage it until it is possible. (We can do this after the current system hit core. Incremental improvements are fine.)

Ummm .. you guys do realise there's nothing stopping you from running drupal as a command line script ? right. At the top of the install.php file, just add this : if ($argv[1]) { $_SERVER['HTTP_HOST'] = $argv[1]; $_SERVER['REQUEST_URI'] = '/install.php'; $_SERVER['SCRIPT_NAME'] = '/install.php'; $_SERVER['PHP_SELF'] = '/install.php'; $_SERVER['SCRIPT_FILENAME'] = $_SERVER['PWD'] . '/install.php'; $_SERVER['PATH_TRANSLATED'] = $_SERVER['SCRIPT_FILENAME']; } And then you can run install.php via the php command line as './ install.php www.mysite.com' In fact, I think it's entirely practical to turn install.php and update.php into scripts that can be run on the command line. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

On 10 Jun 2006, at 3:53 PM, Karoly Negyesi wrote :

Gordon Heydon has written a nice script for that. http://drupal.org/ node/59863 From the perspective of multi-site drupal installs, I think we should seriously look at making install.php and update.php shell runable.

After updating the source, being able to do : for i in `ls -1 sites/*`; do php update.php --site $i --upgrade; done; To upgrade the schema of all your sites, versus having to go and update every one by hand, is an important distinction. Additionally, install.php can be built to accept the form fields from the command line ie: install.php --site www.domain.com --db_type='mysql' -- db_name='something' --db_username='root' --prefix='prefix_' -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

Op vrijdag 9 juni 2006 23:35, schreef Kieran Lal:

So you think the path to usability is through command line scripts?   Have you ever actually watched someone who has never seen a command   line in their life try to use the command line?  I have, as part of   the user research for this installer.

You did not understand me there. This needs clarification. I NEVER said that commandline nistallation is the end-goal. NEVER. Commanline tools, or better: common install APIs, is what I think is the route to go. Then, *on top of that*, one can build a web-based installer. Bot *also* an apt package. Or a Plesk addon. Or ... and so on. IF we develop primarily a webbased installer, I ( stress that I) feel we are getting to the ultimate goal (easy Drupalinstallation) via the wrong road. Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | Drupal repareert wederom een kritiek veiligheidslek: http://help.sympal.nl/drupal_repareert_wederom_een_kritiek_veiligheidslek

Op zondag 11 juni 2006 17:06, schreef Jenny Hsueh:

I wonder, Ber - is your sympal script a starting point to focus on the "deployment" aspect that we can combine the energy with civicspace install

You state it correct: I beleive we should focus on the underlying part first. The underlying part being a set of Apis and scripts to install a site, or more then one site. You call that deployment. If you want more detail on why and how read on. Else: exit; :) And my scripts are indeed focused on deployment of Dupal site. They are a formalised, centralised, and reniced first version of all the "stuff" I had lying all over the place that I used to manage my growing flock of Drupal sites. I generalised these, rewrote them all in PHP (I used a lot of Ruby all over the place) and bound them in a single contrib. I use them with success to manage my host, now running 35 sites. It costs me no time to instal sites anymore, since I call the scripts from a webhosting environment (like Cpanel) called dischosting. Because I use them this way, they are still ery much focused on managing a multisite Drupal. But that is not the end-goal. The goal is, to get a solid installation system worked out. One that can be tied to any other system. Example to explain my point why a route bottom up is better: Firefox: Linux, OSX and the likes have perfect installation and software managers, in a whole range of flavours. Yet even 1.5 does not manage to hook into that properly. The upgrade system is still a private firefox thing. Now: Had FF designed a solid deployment system, instead of focussing on an interface for upgrading, all the linux and the OSX systems would have had a proper integration in their native software manager. And Then they could have built a standalone installer and upgrade system for the folks using MS. (MSwindows has no proper software manageing system). ut because it was chosen to be done the other way around, firefox has been in a broken state on Kubuntu, has not been going with the osX auto-updates, nor could Novell etc provide security updates for it. If Drupal goes the same way: design and develop a Drupal-only installer, then we will only serve a subset of people. While, when we develop a good deployment system, one cuold easily keep Drupal up-to-date with e.g. apt-get (on debian servers) or install it using native Plesk installers. While we could hook a Civicspace alike web-installer to it very well, for all those deprived of plesk, a linux installer, or some other webhosting environment. It should be *really* easy to tie my scripts to a CS instaler alike webform, or even to a single Drupal module (multisite_manager.module?). I did a proof of concept with a singel drupal site running of a special server on a special port, that had write permissions. I managed to install sites from within this one-ring-to-rule-all Drupal site. So you could even replace Cpanel or plesk with a special Drupal site! How cool is that! Bèr -- -- [ Bèr Kessels | Drupal services www.webschuur.com ] Drupal repareert wederom een kritiek veiligheidslek: http://help.sympal.nl/drupal_repareert_wederom_een_kritiek_veiligheidslek

Op zondag 11 juni 2006 19:16, schreef Jenny Hsueh:

be that the sympal solution or something else,

Yes. I am not sure what Bryght could offer ni this. They developed something too, But I remember it is closed still. (?) I also recall Vlado presenting some really cool apt-get alike dependency systems. But maybe there are others? Can people who know about any comment here?

Given drupal's flexibility which can suit many different uses, I think it is wise to focus our energy on building those infrastructures and to expose the APIs at different layers, as we will never be able to satisfy all "end-users" so providing the tools to enable the middle-tier, who are the larger drupal community other than the regular drupal contributors, to build drupal value-added services/packages for the real end users seems a way to expand drupal adoptions .

Exactly! But it seems I either misunderstood Civicspaces installer system when I looked and tested it, or that they did not take this approach? Can someone from CS explain how they envision to serve the middle tier? How we can use their install system in a musltisite hosting? Or wit some 3rd party installation and configuration script? Bèr -- [ End user Drupal services and hosting | Sympal.nl ] Drupal repareert wederom een kritiek veiligheidslek: http://help.sympal.nl/drupal_repareert_wederom_een_kritiek_veiligheidslek

Thanks for the clarification. Obviously I must have missed the important parts, because my first attempt for my install stuff was built on top of CS, but that Just Did Not Work Right, for me. then. Op zondag 11 juni 2006 19:58, schreef Boris Mann:

Go and ahead and *try* to build some install profiles and/or automate   installs, then come back and submit patches.

So: I have built my scripts off the CS stuff that I grabbed from CS about 5 months ago. And what I have seen untill today, did not allow me to achieve all that you stated. Not in an easy way, a way that /I/ could code, at least :). And talking about an approach: fixing stuff with patches afterwards is bit the wrong way around, if it could have been done slightly different from the beginning, not? ;-) Bèr

Why: In contribs they can settle out. Become nice. Grow onto people. In contribs they can conpete. I still think that there are other ways that make just as well a candidate for core. My own sympal scripts are just one of the possibilities. we are now getting apt-get alike module installers in. Fixtures are still in the make.

Why stare blind on one install system that is not tested, not mature and has not proved to be the Right Solution? Why depend only on those that can review patches, when we have a huge reviewing organism called "contribs"? Only because the Mob demands install systems? If they do so, lets give it, in contribs. And let that Mob sort out what the best stuff is, what needs fixed and what should be changed.

I'm sorry, but I couldn't disagree more. Contrib is nice, and it's an essential part of Drupal at large. But I don't think anyone would pretend for one minute that contrib modules get as much and as thorough a reviewing as a core patch. In contrib, the rule is "if it works, I'm happy" aka scratch-your-own-itch. Now, I'm well aware that there is a huge range of quality in contributed modules, going from the festering pile of stale spaghetti to the shiny clean and modular approach of e.g. CCK and Views. But nowhere in contrib is there a formalized and highly visible process for review, nor is it necessary. If I don't like a particular approach, I will ignore that module and look for something else. Whereas if a patch hits core that seriously hinders my needs, I'm screwed. If, as you say, making a good installer that works everywhere is a difficult endeavor, do you honestly believe that a mere contributed patch/module/script will get enough exposure for those issues to be discovered and fixed? Our development history has shown time and time again that getting in large changes into core as early as possible (but not earlier!), benefits everyone in the long run. A patch sitting in the queue is about a lot more than just looking for bugfree code. It's about getting everyone's opinion and approval, and making sure that the solution we end up with is good and flexible enough to be installed on /every single Drupal site out there/. If you wait for competing solutions, all you will end up with is N different approaches that will each work in one particular scenario. There is in fact a very analogous issue being worked on: to improve the Javascript functionality in Drupal Core. I have no problem with recoding parts of drupal.js and bringing in an external library, if it helps JS functionality get more exposure and development time. However, I think the JS work that has been done in contrib has had very little effect on this upcoming decision: those efforts are mostly started from a "scratch your own itch" perspective. Again: that's perfectly fine, for contrib. I have nothing against this. But as soon as things come near core, the discussion shifts to the needs of every Drupal developer and every Drupal site. I know that you feel burned by our review process... but your comment that the patch queue is only open "to those that can review patches" is plain nonsense. It is open to anyone who wants. Newsflash: I'm in the middle of my final exams and I still spent over an hour figuring out and reviewing that install patch. Why? Because I /want/ the installer into core, but I also want it to be the right solution. For me, it needs to be secure, usable, flexible and bugfree.... but most importantly, simple and elegant. The only people who consider reviewing to be "staring yourself blind" are those who are never done a proper review. Even more, the best reviewer does not just comment, he takes the patch and starts working on it himself: "Talk is silver, code is gold". It is not a mindless mantra, it is exactly the reason why Drupal is what it is today. Steven Wittens

Op zaterdag 10 juni 2006 04:33, schreef Steven Wittens:

I know that you feel burned by our review process...

I don't. I just feel an urge to improve it. Much larger OSS projects, with equally or better code manage to survive with much openener and fre-er systems. Or even with much closer and more formal systems. But this has nothing to do with the current thread.

but your comment   that the patch queue is only open "to those that can review patches"   is plain nonsense.

No its not. The happy few patches that come with a screenshot and/or large documentation, get some reviews by those that cannot apply patches or read code. All others require alt least good knowledge of Drupal, PHP and patching. I asked a KDE usability 'expert' once to look at certain usabilty issues, but she turned away with horror: "there is nothing to review, only some giberrish code". But again: I only put this in my defence, its not really on topic :)

It is open to anyone who wants. Newsflash: I'm in   the middle of my final exams and I still spent over an hour figuring   out and reviewing that install patch. Why? Because I /want/ the   installer into core, but I also want it to be the right solution. For   me, it needs to be secure, usable, flexible and bugfree.... but most   importantly, simple and elegant.

True. And I meant "review" in a bit larger way. review as in code, is best done in patch queues. Certainly. But I am 100% sure that we wuold have never gotten to CCK as it stands now, without flexinode being beaten and abused "in the wild". Ever. And CCK will go trough the same, I am sure, before it is even considered core worthy. WE should not underestimate the power of our agile quick, and open way of developing contribs. They take time to shape into perfection, but the good stuff ends in a very good shape too. Sometimes much faster, and much better then core. If they don't get enough exposure, then we should not say that contribs are no good because of the, but make sure they do get enough of that exposure. Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | Drupal repareert wederom een kritiek veiligheidslek: http://help.sympal.nl/drupal_repareert_wederom_een_kritiek_veiligheidslek