| Previous · Next | |
| User | Message |
|
koen
|
Date: 5/26/2009 2:53 am · Subject: WRE development maturing · Rating: 0
I have posted a reply to the Black Blog about The Future of the WRE and I would like to invite everyone interested to a IRC discussion about the WRE to discuss the following:
What would be the best time/date to have such an IRC discussion? Koen de Jonge - ProcoliX |
| Back to Top |
Rate [ | ]
|
|
patspam
|
Date: 5/27/2009 0:25 am · Subject: Re: WRE development maturing · Rating: 0
Chances are I'll be asleep when any IRC discussion happens, so I'll chime in here instead.I started off without the WRE when I was developing on FreeBSD, but I've been WRE-powered for a couple of years now and don't plan on changing. The more "standard" things I can assume about peoples' servers the better, so I'm a fan of the WRE. And even more so as we head towards better cluster support, and value-add features such as differential backup, etc.. Others can corrent me if I'm wrong, but the only wg developer I know who doesn't use the WRE is Colin. A scheduled release cycle for the WRE would be nice. The perl 5.10 release impressed on me that regular releases, even if only for the sake of releasing regularly, are a good thing. Perhaps one day we'll split the WRE into developer and production distros, with the developer bundle containing extra testing modules, wgd, Padre, etc.. Just my 2c. Patrick On Tue, May 26, 2009 at 5:53 PM, <koen@procolix.com> wrote: koen wrote: |
| Back to Top |
Rate [ | ]
|
|
perlDreamer
|
Date: 5/27/2009 9:30 am · Subject: Re: WRE development maturing · Rating: 0
webguidev@plainblack.com wrote:> patspam wrote: > > Others can corrent me if I'm wrong, but the only wg developer I know > who doesn't use the WRE is Colin. There's also SquOnk, and the fellow who is working on getting us into Ubuntu. However, I believe that there are way more people who use the WRE. Colin |
| Back to Top |
Rate [ | ]
|
|
cap10morgan
|
Date: 5/27/2009 8:17 am · Subject: Re: WRE development maturing · Rating: 0
As we move into Rightscale/EC2 for our web hosting, I'm excited to hear about clustering tools in the WRE. Depending on the implementation, that could solve the use case for which I created the uWRE RFE. Namely, vertically scaling the WRE so that mod_proxy / static content serving, mod_perl / dynamic content serving, and MySQL all live on different (clusters of) servers. So that's exciting. The other thing I'd love to see in the WRE is better handling of upgrades. Specifically 2 things come to mind: 1. When a WebGUI version requires that you upgrade to it before moving on (as many of the 7.7.x series do), it should specify that in some metadata so that the WRE's webguiupdate.pl script will just do that for you transparently (i.e. download that version, upgrade, if everything looks OK, download the next version it's safe to jump to, lather, rinse, repeat). 2. When a new WebGUI version has additional Perl module dependencies, it should specify those in some metadata that the WRE can read and then automatically install those modules from CPAN. It could possibly just run the testEnvironment.pl script for you and then it wouldn't even need to specify the modules anywhere else. The less manual intervention required to upgrade WebGUI, the better. That makes it much easier to track recent versions of WebGUI, which is a lesson we learned the hard way with our WebGUI 6->7 transition. |
| Back to Top |
Rate [ | ]
|
|
patspam
|
Date: 5/27/2009 8:50 am · Subject: Re: WRE development maturing · Rating: 0
1. When a WebGUI version requires that you upgrade to it before moving on (as many of the 7.7.x series do), it should specify that in some metadata so that the WRE's webguiupdate.pl script will just do that for you transparently (i.e. download that version, upgrade, if everything looks OK, download the next version it's safe to jump to, lather, rinse, repeat). As JT pointed out to me last week in irc, ALL upgrades require that you run them on the codebase version indicated in the "from" version number in the name of the upgrade script, e.g. upgrade-fromX-toY.pl requires that you run it on wg codebase version X. It's because we use API methods in upgrade scripts, and unless you're using the intended version there's no way to guarantee that the API method will do what the upgrade script author intended. Patrick |
| Back to Top |
Rate [ | ]
|
|
cap10morgan
|
Date: 5/27/2009 9:34 am · Subject: Re: WRE development maturing · Rating: 0
1. When a WebGUI version requires that you upgrade to it before moving on (as many of the 7.7.x series do), it should specify that in some metadata so that the WRE's webguiupdate.pl script will just do that for you transparently (i.e. download that version, upgrade, if everything looks OK, download the next version it's safe to jump to, lather, rinse, repeat). Right. I'm not arguing against that. But many upgrades allow you to install the destination version of WebGUI and then run the upgrade, and it runs all the intermediate upgrades in sequence for you. So, for example, if I'm running 7.5.34 and I want to upgrade to 7.5.40, I can just untar the 7.5.40 codebase on top of my 7.5.34 installation and run upgrade.pl (or run webguiupdate.pl from the WRE, which does the same thing). This then runs upgrade-7.5.34-7.5.35.pl, upgrade-7.5.35-7.5.36.pl, etc. etc. But some versions you can't do this with, probably for the API reasons you describe above as well as some database changes (it seems, I'm not super clear on all the details, but I know it's not something that can just be changed; it has to work this way). In other words, if I want to upgrade my 7.6.14 installation to 7.7.7, I can't just untar 7.7.7 on top of 7.6.14 and run upgrade.pl. I have to untar several intermediate 7.7.x versions first and upgrade each of them manually. I'm just suggesting that we automate that. If a particular version of WebGUI must have its codebase installed (as opposed to a later version's) for its upgrade script to succeed, then it would be nice if the WRE would just do that for me. There's nothing involved there which requires manual intervention, as far as I can see. It just isn't automated right now. Please correct me if I'm wrong, though. |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 5/27/2009 10:15 am · Subject: Re: WRE development maturing · Rating: 0
That's a great idea. I'm not entirely sure how to do it right this second, but it's definitely worth some serious investigation. |
| Back to Top |
Rate [ | ]
|
|
patspam
|
Date: 5/28/2009 1:46 pm · Subject: Re: WRE development maturing · Rating: 0
Right. That's how I used to do my upgrades too. But ever since the upgrade scripts started using API methods this hasn't been safe. In fact, it's probably a bug for the upgrade script to even support that. Take for example, the latest beta release 7.7.7. The most recent version that noted in the changelog that it required a specific WebGUI version was 7.7.6: "You must upgrade to WebGUI 7.7.5 before going to this version". So after you updade to 7.7.5, you might think it's reasonable to assume you can upgrade from 7.7.5 to 7.7.7 on the 7.7.7 codebase. However, in upgrade_7.7.5-7.7.6.pl you'll see that the installSurveyTest() sub uses: Â WebGUI::Asset::Wobject::Survey::Test->crud_createTable to create a new db table. If you run this upgrade script on 7.7.6 codebase you'll get a db table corresponding to the Crud definition as it was at version 7.7.6 (which, among other things, has a field called 'spec'). Whereas, if you run the same upgrade script on the 7.7.7 codebase, you'll get a db table corresponding to the 7.7.7 Crud definition, where that 'spec' field has been renamed to 'test'. So you really need to assume that ALL upgrades must be run on the target codebase. And since this could become quite tedious, I agree, some form of automation would be nice! Patrick |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 5/28/2009 2:15 pm · Subject: Re: WRE development maturing · Rating: 0
> So you really need to assume that ALL upgrades must be run on the > target codebase. And since this could become quite tedious, I agree, > some form of automation would be nice! *No* you don't. You need to assume that all BETA upgrades need to be run on the target codebase. Once we're past beta you won't need to do that anymore. Not arguing against automation, just trying to set you straight. JT Smith ph: 703-286-2525 x810 fx: 312-264-5382 Create like a god. Command like a king. Work like a slave. |
| Back to Top |
Rate [ | ]
|
|
patspam
|
Date: 5/28/2009 6:55 pm · Subject: Re: WRE development maturing · Rating: 0
On Fri, May 29, 2009 at 5:15 AM, <jt@plainblack.com> wrote:JT wrote: Why is that? Or are you talking about shunt upgrades? Patrick |
| Back to Top |
Rate [ | ]
|
