Re: upgrade instructions for 3.2.1

> ...  If a tried-and-true procedure for moving to
> buildout from a traditional platform exists, please let me know.  I
> suspect many others would be grateful for such a procedure as well.

I think we can make a real improvement here with some documentation,
and I've cc'd the documentation team list. We've probably got a few
candidates (one of them me) for writing a low-pain migration strategy
document.

Steve

On Mon, Feb 9, 2009 at 9:30 AM, deesto <[email protected]> wrote:
> Hey Steve,
>
> On Feb 9, 2009, at 12:06 PM, Steve McMahon-2 (via Nabble) wrote:
>> I believe there are two issues here:
>>
>> 1) The move to Python packages as distribution mechanism;
>>
>> 2) The strong recommendation of buildout as a mechanism for managing
>> installation configuration.
>
> Right, thanks.  To this I would also add: 3) The timing/versioning of
> such a change in distribution (why not at v3 or v4 instead of v3.2.x?).
>
>> The move to Python packages as distribution mechanism is indeed a
>> fundamental change, and is going to cause some pain for folks wedded
>> to the traditional product tarball. However, the advantages are
>> overwhelming. Among them are that if we didn't do this, we'd be
>> setting ourselves up in a little backwater of the Python/Zope
>> community and would not benefit from any of the other work done in the
>> larger world.
>
> I've seen the movement in Python toward buildout and can't argue with
> this.  Also can't argue with your point about inducing pain for
> traditional installations.
>
>> Buildout is our *recommended* -- not *required* -- way of managing and
>> simplifying the complexity of a Python-package distributed platform.
>> There are other ways to do this (e.g., virtualenv), and many of our
>> best developer/integrators use them. But, since it's difficult to
>> document and provide support for all of these, so we consciously chose
>> buildout as our mainstream configuration tool for integrators.
>
> True that buildout is "recommended and not required", and we have seen
> this said many times of late.  But the official instructions cited
> earlier seem to suggest otherwise, and as you point out, the
> suggestions for upgrading in a non-buildout environment are somewhat
> daunting and nebulous.
>
>> Both of these changes went through full PLIP review, and have been
>> widely discussed. A great many of us have been loudly proclaiming this
>> change for some time, and I think it's fair to say that there hasn't
>> been any documentation written in the past year that's said anything
>> else about our direction.
>
> As someone who's not a core Plone developer, I have no right to an
> argument here, other than the points given earlier, especially the
> timing and the fact that the "old school" base of Plone users are
> being left in the dust.  I have production instances that are in heavy
> use that were deployed two years ago (or less) that are now running on
> what is, as of today, considered a deprecated distribution platform,
> and I don't have the time and resources to develop a migration
> strategy from scratch.  If a tried-and-true procedure for moving to
> buildout from a traditional platform exists, please let me know.  I
> suspect many others would be grateful for such a procedure as well.
> And I would gladly contribute time and effort to developing one if
> necessary.  I can't easily replicate my current instances on test
> environments, as I don't have the test equipment necessary to do so.
>
> I am not trolling or looking for fights; I'm looking for a solution
> that will make everyone happy, particularly existing, non-buildout
> users who might feel bullied into using a new architecture they don't
> necessarily understand, or even see the need for in their particular
> case.
>
> Thanks,
> ~John
>
>
> ________________________________
> View this message in context: Re: [Plone-Users] upgrade instructions for
> 3.2.1
> Sent from the General Questions mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code
> to
> build responsive, highly engaging applications that combine the power of
> local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Plone-Users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/plone-users
>
>



-- 

Steve McMahon
Reid-McMahon, LLC
steve-HR5nRXif9uVv8oa/[email protected]
[email protected]

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com