[Plone-docs] New install add-ons tutorial needs your love

[Mikko Ohtamaa]

FYI someone do proof-read and testing on this:

http://plone.org/documentation/kb/add-on-installation-tutorial

... and after that I'll deprecate the old add-on installation tutorial.

-----

Follow me in Twitter

Download mFabrik News for iPhone
or Android

--
View this message in context: http://plone.293351.n2.nabble.com/New-install-add-ons-tutorial-needs-your-love-tp6756857p6756857.html
Sent from the Documentation Team mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Plone-docs mailing list
Plone...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plone-docs

[Mikko Ohtamaa]

Mikko Ohtamaa wrote:
>
> FYI someone do proof-read and testing on this:
>
> http://plone.org/documentation/kb/add-on-installation-tutorial
>
> ... and after that I'll deprecate the old add-on installation tutorial.
>

More love needed here also (total rewrite):

http://plone.org/documentation/kb/diagnosing-third-party-product-installation-problems

-----

Follow me in Twitter

Read my blog

--
View this message in context: http://plone.293351.n2.nabble.com/New-install-add-ons-tutorial-needs-your-love-tp6756857p6756964.html

[Mikko Ohtamaa]

Hey D,

>
> There are a number of add-ons that provide good-py KGS's to make sure that
> the correct versions of dependencies are included. We probably should
> explain what these are and how to use them.

I think it's the responsible of the add-on author to have the primary
installation instructions and explain the usage of KGS.

> Also I think we should probably teach people how to pin the result of their
> build (using buildout.dumppickedversions) to make sure it's safe to run in
> the future.

I think buildout must be fixed so that it would do it by itself. This
is something computers should do for us, not we doing it for
computers.

-Mikko

>
> David
>
>
> ----------
> David Glick
> Web Developer
> david...@groundwire.org
> 206.286.1235x32
>
> Online tools and strategies for the environmental movement.
> Sign up for our newsletter: http://www.groundwire.org/email-capture
>
>
>

--
Mikko Ohtamaa
mFabrik - Freedom Delivered.

Web site - http://mfabrik.com
Mobile site - http://mfabrik.mobi
Blog - http://blog.mfabrik.com

[David Glick]

On 9/3/11 10:03 AM, Mikko Ohtamaa wrote:
> Hey D,
>
>> There are a number of add-ons that provide good-py KGS's to make sure that
>> the correct versions of dependencies are included. We probably should
>> explain what these are and how to use them.
> I think it's the responsible of the add-on author to have the primary
> installation instructions and explain the usage of KGS.

Perhaps, although I think it would be good for the tutorial to at least
say something like "a number of add-ons use this method; be sure to
check the specific instructions"

> Also I think we should probably teach people how to pin the result of their
> build (using buildout.dumppickedversions) to make sure it's safe to run in
> the future.
> I think buildout must be fixed so that it would do it by itself. This
> is something computers should do for us, not we doing it for
> computers.
>

Hmm, I'm not sure how to make it more automatic. You don't want to
record the versions until you know they work, and you don't know that
until you've started up Zope and/or run tests.

[John Schinnerer]

On 09/03/2011 10:32 AM, David Glick wrote:
> On 9/3/11 10:03 AM, Mikko Ohtamaa wrote:
>> Hey D,

...

>> Also I think we should probably teach people how to pin the result of their
>> build (using buildout.dumppickedversions) to make sure it's safe to run in
>> the future.

+1 on that. Back when I had to figure this out (pinning versions etc.),
it was not presented up front, and not knowing about it could result in
hours of wasted time, DOA buildouts from one little change, etc.

>> I think buildout must be fixed so that it would do it by itself. This
>> is something computers should do for us, not we doing it for
>> computers.
>>
> Hmm, I'm not sure how to make it more automatic. You don't want to
> record the versions until you know they work, and you don't know that
> until you've started up Zope and/or run tests.

I'm not sure how either. However +1 on the idea of having buildout be
"smarter" or more helpful to the user about this, somehow.

My only idea at the moment is to have buildout.dumppickedversion be
built in rather than something that has to be added (and found out about
in the first place).
Why would I *not* want that information readily available, even if I
don't always use it?

cheers,
John S.

>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Plone-docs mailing list
> Plone...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plone-docs

--
John Schinnerer - M.A., Whole Systems Design
--------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
jo...@eco-living.net
http://eco-living.net

[Dylan Jay]

On 04/09/2011, at 6:08 AM, John Schinnerer <jo...@eco-living.net> wrote:

>
> On 09/03/2011 10:32 AM, David Glick wrote:
>> On 9/3/11 10:03 AM, Mikko Ohtamaa wrote:
>>> Hey D,
> ...
>>> Also I think we should probably teach people how to pin the result of their
>>> build (using buildout.dumppickedversions) to make sure it's safe to run in
>>> the future.
>
> +1 on that. Back when I had to figure this out (pinning versions etc.),
> it was not presented up front, and not knowing about it could result in
> hours of wasted time, DOA buildouts from one little change, etc.
>
>>> I think buildout must be fixed so that it would do it by itself. This
>>> is something computers should do for us, not we doing it for
>>> computers.
>>>
>> Hmm, I'm not sure how to make it more automatic. You don't want to
>> record the versions until you know they work, and you don't know that
>> until you've started up Zope and/or run tests.
>
> I'm not sure how either. However +1 on the idea of having buildout be
> "smarter" or more helpful to the user about this, somehow.
>
> My only idea at the moment is to have buildout.dumppickedversion be
> built in rather than something that has to be added (and found out about
> in the first place).
> Why would I *not* want that information readily available, even if I
> don't always use it?

If newest=false was default then it would be less of an issue.