Hi,
On 30/06/10 00:39, Nitro wrote:
>
> This is all very useful information. Thanks for the pointers Laurence.
>
I'm glad you(we)'ve come up to a useful conclussion: we need clear,
ordered, findable, consensued information (documentation) on a very
complex technological organism.
(Thanks Alan
Am 28.06.2010, 23:42 Uhr, schrieb Laurence Rowe :
> On 28 June 2010 21:27, Nitro wrote:
>> ZODB is a general python object database with a much wider audience than
>> just plone. It suits desktop applications just as well as applications
>> you'd normally use twisted and pickle for. Forcing all t
On 06/28/2010 07:29 PM, Nitro wrote:
> P.S.: This will be my last lengthy mail about this topic. I'll rather
> spend time writing blog entries for the docs project.
That sounds fine.
Shane
___
For more information about ZODB, see the ZODB Wiki:
http://w
Am 28.06.2010, 23:30 Uhr, schrieb Shane Hathaway :
> Matthias,
>
> You are conflating two conversations, and as a result you are reacting
> to the non-stated suggestion that the packaging system provides
> sufficient stability information to consumers.
I've experienced the packaging system is
On 28 June 2010 21:27, Nitro wrote:
> ZODB is a general python object database with a much wider audience than
> just plone. It suits desktop applications just as well as applications
> you'd normally use twisted and pickle for. Forcing all those zope
> dependencies like buildout on people does no
Matthias,
You are conflating two conversations, and as a result you are reacting
to the non-stated suggestion that the packaging system provides
sufficient stability information to consumers. That suggestion would
obviously be false, since anyone, including people with hostile
intentions, can
On 28 June 2010 19:31, Nitro wrote:
> Am 28.06.2010, 16:52 Uhr, schrieb Laurence Rowe :
>
>> So why don't we all work on the same packages? The main reason is one
>> of legacy. Plone is built on Zope2 and ZCatalog. It works, but it is
>> not without it's issues - we can't have queries that join fr
Am 28.06.2010, 20:31 Uhr, schrieb Shane Hathaway :
> Around here, Python packages are how we communicate code. Think of a
> released package as a well-refined email. If you choose not to release
> packages, you are really choosing not to communicate through the
> established channels, so m
On Mon, Jun 28, 2010 at 2:30 PM, Alan Runyan wrote:
...
>> No it can't. ZODB isn't a namespace package and can't be one without
>> breaking backward compatibility.
>
> Should it be a namespace package over the long term?
Not IMO. That's partly because I think ZODB should be small.
I also don't t
Am 28.06.2010, 18:23 Uhr, schrieb Leonardo Santagada :
> Although I think this sounds like an optimal solution, I think it isn't
> necessary. I wish only that there was a "complements" in ZODB wiki with
> a simple list of best of breed package for each task and maybe a list of
> alternatives
Am 28.06.2010, 17:52 Uhr, schrieb Alan Runyan :
> I have similar feelings as Matthias.
>
> - We could use something similar to the Apache incubation process.
Yes.
I think in general the library should be rather flexible. I.e. (minor)
things can be deprecated and removed rather fast. I'd also
On 06/28/2010 04:44 AM, Nitro wrote:
> I do not like the current packaging approach as I discussed in length in a
> recent message to this list [1]. Until this changes I am not going to
> spend time creating random packages.
Around here, Python packages are how we communicate code. Think of a
re
Am 28.06.2010, 16:52 Uhr, schrieb Laurence Rowe :
> So why don't we all work on the same packages? The main reason is one
> of legacy. Plone is built on Zope2 and ZCatalog. It works, but it is
> not without it's issues - we can't have queries that join from that
> catalog to a zc.relation catalog.
> Mixing meta data into names is a bad idea. You don't want to change
> the name of something just because some of its meta data changes.
Your right. It's just that sometimes people may have a package name
that is not agreeable to the broader community.
>> The namespace could be, zodb.
>
> No i
On Mon, Jun 28, 2010 at 11:52 AM, Alan Runyan wrote:
...
> - Have a canonical namespace which denotes quality, proven,
> and widely used packages.
> Packages should never be in this
> namespace unless the package can meet some quality level.
Mixing meta data into names is a bad idea. You don't
Although I think this sounds like an optimal solution, I think it isn't
necessary. I wish only that there was a "complements" in ZODB wiki with a
simple list of best of breed package for each task and maybe a list of
alternatives. To make it even better a good "deprecated" section would be good
I have similar feelings as Matthias.
My thoughts:
- Have a canonical namespace which denotes quality, proven,
and widely used packages. Packages should never be in this
namespace unless the package can meet some quality level.
The namespace could be, zodb.
- We could use something similar t
On 28 June 2010 15:23, Nitro wrote:
> Am 28.06.2010, 14:10 Uhr, schrieb Dylan Jay :
>
>> I don't use a lot of other indexes other than what comes with plone but
>> I can see the value of what your suggesting in having an installable
>> tested collection of indexes. I can also see that this is a re
Am 28.06.2010, 14:10 Uhr, schrieb Dylan Jay :
> I don't use a lot of other indexes other than what comes with plone but
> I can see the value of what your suggesting in having an installable
> tested collection of indexes. I can also see that this is a really big
> itch for you and you've al
Am 28.06.2010, 08:21 Uhr, schrieb Thomas Lotze :
> Nitro wrote:
>
>> packaging: I don't plan to create a package for this as I don't see much
>> point in adding yet another package to the clutter of packages
>> surrounding
>> zodb.
>
> Just a quick remark: Without being available as a package, y
Nitro wrote:
> packaging: I don't plan to create a package for this as I don't see much
> point in adding yet another package to the clutter of packages surrounding
> zodb.
Just a quick remark: Without being available as a package, your code will
be far less useful (if not outright useless) to a
21 matches
Mail list logo
