collective.solr?

[Alan Runyan-3]

what is collective.solr?

and could someone tell me why no one has approached enfold
to reuse our solr implementation?

cheers
--
Alan Runyan
Enfold Systems, Inc.
http://www.enfoldsystems.com/
phone: [phone]x111
fax: [phone]

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[tesdal]

On 7. mar. 2008, at 23:43, Alan Runyan wrote:

what is collective.solr?

collective.solr is the Solr component for collective.indexing.

and could someone tell me why no one has approached enfold

to reuse our solr implementation?

collective.solr is more like a reimplementation based on lessons learned, like Membrane is a reimplementation of CMFMember, or plone.multilingual is a reimplementation of LinguaPlone is a reimplementation of I18NLayer.

As it lives in collective and has collective namespace, anyone with collective access is of course welcome to contribute.

--

_______________________________________________________

 Helge Tesdal · Senior Developer, Jarn · www.jarn.com

   Plone Solutions, Development, Hosting and Support

_______________________________________________________

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[Alan Runyan-3]

so you are reimplementing enfold.indexing and enfold.solr?
our integration is already proven and almost in production.
may i poignantly ask, "Why are you re-inventing the wheel?"

> collective.solr is the Solr component for collective.indexing.

why not use enfold.indexing?

> and could someone tell me why no one has approached enfold
> to reuse our solr implementation?

i like how this question was side stepped. looks like collaboration is
no longer the point in the plone community?

> collective.solr is more like a reimplementation based on lessons learned,

what lessons learned?  where?

> like Membrane is a reimplementation of CMFMember, or plone.multilingual is a
> reimplementation of LinguaPlone is a reimplementation of I18NLayer.

so collective.solr is a reimplementation of enfold.solr but using the
collective namespace?

> As it lives in collective and has collective namespace, anyone with
> collective access is of course welcome to contribute.

sure and we would have no problems giving people access to our svn.
until we deploy
our software we are very worried about putting stuff into collective.
but as we have
shown we have a history of putting stuff into collective once we feel
its stable.

I, personally, feel like this is some sort of fork of effort (all in
the name of namespace?).

Enfold has eaten a lot of time doing this R&D and we are meaning for
our implementation
to be the canonical solr integration.  Now people will and up having
two implementations - not one.
(We ate the R&D because *enfold* did not charge our customers for
enfold.solr/indexing; we only
charged them for the integration of enfold.solr/indexing into their Plone sites)

Of course having TWO implementations instead of ONE is a waste of
effort and customer dollars
(if your customer is paying for the implementation).  So before this
goes further - how about you
guys tell Enfold -- what the issues you have with existing code base
(that has LOADS of tests
and is sensitive about memory consumption + supports out-of-process indexing).

If this is how we are going to "collaborate" then we can forget about
*EVER* making Plone
a product.  Because we will constantly be re-implementing infrastructure!
Which is great for Plone consultants but awful for customers!  Oh and
also it doesnt make
Plone *any* better because its the same outcome! It adds *nothing* to
the end user experience.

This re-implementation seems either very petty or a huge
miscommunication failure. I really
hope its the latter.

--
Alan Runyan
Enfold Systems, Inc.
http://www.enfoldsystems.com/
phone: [phone]x111
fax: [phone]

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[Paul Everitt-3]

Alan Runyan wrote:
> what is collective.solr?
>
> and could someone tell me why no one has approached enfold
> to reuse our solr implementation?

Yeh, I'm kinda dismayed to see this.  I remember seeing this:

   http://tarekziade.wordpress.com/2008/01/20/snow-sprint-report-1-indexing/

...and thinking, "Cool, I have a project that might consider Solr, good
to see some traction."

Now there's a second Plone project that ignored the first, making me
wonder if it's premature to do Solr and Plone until things settle out.

--Paul


_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[Alan Runyan-3]

>    http://tarekziade.wordpress.com/2008/01/20/snow-sprint-report-1-indexing/

The snow sprint was very co-operative.  And we should be finished our project
in the next week.  Once our project is done we will import it into collective.
We can not have outages (like the one last week) during customer
development.  Luckily there is a 100% working, scalable implementation of
Plone/SOLR integration which should land in the next 160 hours.

>  Now there's a second Plone project that ignored the first, making me
>  wonder if it's premature to do Solr and Plone until things settle out.

It is unfortunate because it sends mixed messages to outsiders.  Of course
Jarn and Enfold have their own understandings.  But the world (outsides to
privy information) may certainly be confused and punt on Plone/SOLR until
the messages are consistent.

I would like to see more cooperation and communication.  And since there
are such few points of entry (helge and alan) -- I'm surprised that
communication
has been so limited/poor.  I hope to find out what the mix up was so we do not
repeat work in the future and that we can all be on the same page.

--
Alan Runyan
Enfold Systems, Inc.
http://www.enfoldsystems.com/
phone: [phone]x111
fax: [phone]

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[tesdal]

We did consider enfold.indexing and enfold.solr. You even offered us SVN access. After code review we decided we would need major changes for us to be comfortable deploying it, and we did not consider those changes to be compatible with the the current solution and your desire to finish it for a customer project. We did not notify you of this decision, and in retrospect it is clear that we should have discussed this thoroughly with you before starting our own implementation.

We can do the technical discussion off the list, I'm sure our views and opinion on the implementations differ.

My question is - who decides what warrants a new product or a rewrite, and who gets to do the new implementation? Should we sit around and wait for your solution because you want to do the canonical Enfold Solr integration for Plone? Should we do R&D for Enfold just because you have chosen a business model with upfront R&D expenses and sell licenses afterwards? I have to admit that I'm not comfortable doing massive changes in Enfold SVN on enfold.* products unless I'm part of Enfold. It might be petty, but I read company names in namespace and company code repositories as big red stop signs when it comes to collaboration. You might interpret things differently, and we should have discussed that at an earlier stage and would probably have come to some kind of understanding. I think collaboration and communication is a big point in the Plone community, and in this case we could have been better at it.

--

_______________________________________________________

 Helge Tesdal · Senior Developer, Jarn · www.jarn.com

   Plone Solutions, Development, Hosting and Support

_______________________________________________________

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[Alan Runyan-3]

> We did consider enfold.indexing and enfold.solr. You even offered us SVN
> access. After code review we decided we would need major changes for us to
> be comfortable deploying it, and we did not consider those changes to be
> compatible with the the current solution and your desire to finish it for a
> customer project. We did not notify you of this decision, and in retrospect
> it is clear that we should have discussed this thoroughly with you before
> starting our own implementation.

I believe everyone who is interested in solr/indexing would be interested in
the differences.  Either on or off list.  I am REALLY interested in feedback.

> We can do the technical discussion off the list, I'm sure our views and
> opinion on the implementations differ.

maybe.  until we communicate - I have no idea what your views are.
it looks like most of the collective.indexing/solr is re-implementation of
enfold.indexing/solr.

> My question is - who decides what warrants a new product or a rewrite, and
> who gets to do the new implementation? Should we sit around and wait for
> your solution because you want to do the canonical Enfold Solr integration

Nope not at all.  And you didnt necessarily know that I was shooting for that!
What is frustrating is the *seemingly* re-duplication of effort and lack of
communication.  Also if we continue in parallel - then what happens?
The community gets to pick between two implementations?

> for Plone? Should we do R&D for Enfold just because you have chosen a
> business model with upfront R&D expenses and sell licenses afterwards? I

huh?  we arent selling licenses with regards to enfold.solr/indexing.  its open
source software -- that is why Tarek was working on it.

The point is that enfold was trying to consume R&D costs by writing
enfold.indexing/solr/etc.  and then we charged our customer with the
integration.  and what ended up happening is we did the R&D (instead of
letting customer pay) and you guys came behind and reimplemented the
work (whether your customer is paying for reimplementation of our work
is not my concern).  And called it collective.

There are

> have to admit that I'm not comfortable doing massive changes in Enfold SVN
> on enfold.* products unless I'm part of Enfold. It might be petty, but I
> read company names in namespace and company code repositories as big red
> stop signs when it comes to collaboration.

so we should forgot most of the code in svn.zope.org repo? anything
with ore, zc and
lovely namespaces are unusable or you would rather fork effort?  I wanna
get MORE code into svn.zope.org and make bridges into the zope community.
Making more ZPL software so everyone can share (*especially* stop using
ZPL software and licensing new works as L/GPL).  And stop living on the
plone/collective island.  The zope3 guys are doing really good work.
They obviously
dont seem to care much about namespaces.

And if namespace was an issue.  And you said "Alan, we would like to work on
enfold.xxx but we really want it to be collective.xxx" -- do you think
I would say No?
I dont think you do.  We have all known each other for over 4 years.

> You might interpret things
> differently, and we should have discussed that at an earlier stage and would
> probably have come to some kind of understanding. I think collaboration and
> communication is a big point in the Plone community, and in this case we
> could have been better at it.

so lets do it!  Let's be good citizens.   Let's work together and
communicate about
PROs and CONs about codebases before starting parallel efforts that mix messages
and split effort in the community.  Let's stop taking BSD/Apache/ZPL code and
making useful redined code on top of those libraries and licensing it
under t L/GPL.
Let's talk about problems before jumping to solutions.

if this 'reimplementation' is going to be a pattern the community
follows. I think
it bad citizenery.  And we should all understand why it upsets people and how
we can prevent it.

--
Alan Runyan
Enfold Systems, Inc.
http://www.enfoldsystems.com/
phone: [phone]x111
fax: [phone]

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[Hanno Schlichting-2]

Alan Runyan wrote:
>> As it lives in collective and has collective namespace, anyone with
>> collective access is of course welcome to contribute.
>
> sure and we would have no problems giving people access to our svn.
> until we deploy
> our software we are very worried about putting stuff into collective.
> but as we have
> shown we have a history of putting stuff into collective once we feel
> its stable.

Just as a side, I have seen Jim using a simple trick on his new packages
in svn.zope.org. As long as he is developing them, he doesn't use
<packagename>/trunk but /dev instead and only after being satisfied with
the implementation renames dev to trunk.

Maybe this is a trick we can use in the collective as well to make
packages more easily available and visible at first while still marking
them clearly as 'use-at-own-risk'.

Hanno


_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[Vincenzo Di Somma]

On Sun, 2008-03-09 at 12:45 +0100, Helge Tesdal wrote:

...snip...
> It might be petty, but I read company names in namespace and company code repositories as big red stop signs when it comes to collaboration.
...snip...

How many of you think that the company names namespace doesn't encourage
the collaboration?

I do.  

I'd like to know if anybody is interested in discuss this topic.


                vds


--
Vincenzo Di Somma               [hidden email]
Reflab S.r.l. - Design, Development and Consulting
Phone: [phone]        http://www.reflab.com




_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[ajung]

--On 12. März 2008 16:47:23 +0100 Vincenzo Di Somma <[hidden email]>
wrote:

>
> On Sun, 2008-03-09 at 12:45 +0100, Helge Tesdal wrote:
>
> ...snip...
>> It might be petty, but I read company names in namespace and company
>> code repositories as big red stop signs when it comes to collaboration.
> ...snip...
>
> How many of you think that the company names namespace doesn't encourage
> the collaboration?

A company namespace basically tells me: get in touch with the people behind
the package and ask them when making major changes and discuss issues with
them. But this should also be true for any other package. Major changes and
contributions can always happen on dedicated branches. As a maintainer of
several packages I am reluctant of accepting changes on the trunk or
maintenance branches unless I know the person and trust in their work.

Andreas


_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[David Sapiro - Pilot Systems]

Some javascript/style in this post has been disabled (why?)

Le 12 mars 08 à 16:47, Vincenzo Di Somma a écrit :

On Sun, 2008-03-09 at 12:45 +0100, Helge Tesdal wrote:

...snip...

It might be petty, but I read company names in namespace and company code repositories as big red stop signs when it comes to collaboration.

...snip...

How many of you think that the company names namespace doesn't encourage

the collaboration?

I do.  

+1

Dave

I'd like to know if anybody is interested in discuss this topic.

vds

-- 

David Sapiro - [hidden email]

Pilot Systems - 9, rue Desargues - 75011 Paris

Tel : [phone] - http://www.pilotsystems.net

Hébergement Zope et Plone gratuit - http://www.objectis.org

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[David Sapiro - Pilot Systems]

Some javascript/style in this post has been disabled (why?)

Le 12 mars 08 à 16:57, Andreas Jung a écrit :

--On 12. März 2008 16:47:23 +0100 Vincenzo Di Somma <[hidden email]> wrote:

On Sun, 2008-03-09 at 12:45 +0100, Helge Tesdal wrote:

...snip...

It might be petty, but I read company names in namespace and company

code repositories as big red stop signs when it comes to collaboration.

...snip...

How many of you think that the company names namespace doesn't encourage

the collaboration?

A company namespace basically tells me: get in touch with the people behind

Nope. The credit part tells you this, right?

the package and ask them when making major changes and discuss issues with them. But this should also be true for any other package. Major changes and contributions can always happen on dedicated branches. As a maintainer of several packages I am reluctant of accepting changes on the trunk or maintenance branches unless I know the person and trust in their work.

+1

Dave

-- 

David Sapiro - [hidden email]

Pilot Systems - 9, rue Desargues - 75011 Paris

Tel : [phone] - http://www.pilotsystems.net

Hébergement Zope et Plone gratuit - http://www.objectis.org

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[Matthew Wilkes]

On Heisei 0020-03-09, at 114535GMT, Helge Tesdal wrote:

> It might be petty, but I read company names in namespace and company  
> code repositories as big red stop signs when it comes to  
> collaboration.

I see it as the collective.* namespace as being a disclaimer of  
ownership, rather than company namespaces being a claim.  In general,  
if I have something that I've had to write but I'm not interested in  
dictating the direction of the project, or mind if somebody wants to  
become the maintainer, it goes in collective.  If I am interested or  
it's a common name and I don't want to use it up in the collective I'd  
company it.

For example, I've been playing with some OpenID stuff, and have put it  
in circulartriangle.openid, not because I don't want other people  
contributing but because other people might want to do openid stuff  
and collective.* is higher profile than company namespaces.

Matt

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[Geir Bækholt · Jarn]

On Mar 12, 2008, at 22:01 , Matthew Wilkes wrote:

> I see it as the collective.* namespace as being a disclaimer of  
> ownership, rather than company namespaces being a claim.  In  
> general, if I have something that I've had to write but I'm not  
> interested in dictating the direction of the project, or mind if  
> somebody wants to become the maintainer, it goes in collective.  If  
> I am interested or it's a common name and I don't want to use it up  
> in the collective I'd company it.


If i wanted stuff to be adopted as a "community standard" or make its  
way into the Plone core — i'd (in the light of previous errors on our  
side) choose the collective namespace, even if i wanted to continue  
contributing to it.

If i wanted to stay more completely in control of the direction it was  
taking, i'd keep it in our own svn. I have, however, done this more  
than neccesary in the past, (LinguaPlone is a good example) and  
noticed that (at least in our case)  it had a very clear effect of  
keeping people away from contributing or feeling anything remotely  
like shared ownership to it.

--
_______________________________________________________

  Geir Bækholt · Managing Director, Jarn · www.jarn.com

    Plone Solutions, Development, Hosting and Support
______________________________________________________

        Plone Solutions is now known as Jarn
              www.jarn.com/name-change



_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[sune]

Hi :)
>  
> ...snip...
>
> How many of you think that the company names namespace doesn't encourage
> the collaboration?
>
>  
I can understand why we are using "collective" in a namespace. In my
mind its to tell other developers that a product is "given" to the
community and you dont mind whos using it or maintain it. At Headnet we
are also using collective for products in our own SVN. In fact using
something like "plonecontrib" instead of "collective" would make this
policy easier for outsiders to understand, but it doesn't matter much if
we just agree on what using "collective" in a namespace means.

Anyway - I can't understand why its important to put your company name
in a namespace - it doesn't tell anything of usage, compatibilty, rights
etc.  If you want other companies to contribute to the product it makes
even lesser sence to me. Why not use the limited "space" in the
namespace for some informative information ?

Maybe its a task for our foundation to define what using "collective" in
a namespace means ?


Br
/sune

>
>
>
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> Enterprise mailing list
> [hidden email]
> http://lists.plone.org/mailman/listinfo/enterprise
>  

--
========================
Sune Toft
Partner, Projektleder

Headnet ApS
Fruebjergvej 3
Symbion Science Park - Box 50
2100 København Ø.

Telefon: [phone]
Fax: [phone]
Mobil: [phone]

http://www.headnet.dk
[hidden email]
=======================

Headnet - devoted to Plone
http://www.plone.org
Vinder af "Bedst til Nettet" 2005 - 2006
http://bedstpaanettet.dk


_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[yvesm]

> If i wanted to stay more completely in control of the direction it was

> taking, i'd keep it in our own svn. I have, however, done this more
than
> neccesary in the past, (LinguaPlone is a good example) and noticed
that
> (at least in our case)  it had a very clear effect of keeping people
away > from contributing or feeling anything remotely like shared
ownership to
> it.

>From "Producing Open Source Software" by Karl Fogel:

"In order to combat incipient territorialism, or even the appearance of
it, many projects have taken the step of banning the inclusion of author
names or designated maintainer names in source files ... A software
project's source code files are the core of its identity. They should
reflect the fact that the developer community as a whole is responsible
for them, and not be divided up into little fiefdoms"

FWIW,

Yves


_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[David Sapiro - Pilot Systems]

Some javascript/style in this post has been disabled (why?)

Le 13 mars 08 à 14:07, Moisan Yves a écrit :

If i wanted to stay more completely in control of the direction it was

taking, i'd keep it in our own svn. I have, however, done this more

than 

neccesary in the past, (LinguaPlone is a good example) and noticed

that 

(at least in our case)  it had a very clear effect of keeping people

away > from contributing or feeling anything remotely like shared

ownership to 

it.

From "Producing Open Source Software" by Karl Fogel:

"In order to combat incipient territorialism, or even the appearance of

it, many projects have taken the step of banning the inclusion of author

names or designated maintainer names in source files ... A software

project's source code files are the core of its identity. They should

reflect the fact that the developer community as a whole is responsible

for them, and not be divided up into little fiefdoms"

+100 :)

Thansk for reminding the basics of FOSS. 

Dave

-- 

David Sapiro - [hidden email]

Pilot Systems - 9, rue Desargues - 75011 Paris

Tel : [phone] - http://www.pilotsystems.net

Hébergement Zope et Plone gratuit - http://www.objectis.org

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[yvesm]

> Thansk for reminding the basics of FOSS. 

I wouldn't be so pretentious as doing that myself, whence the quote.  Another quote I very much like from the same book :

"If you consider 'politics' a dirty word, and hope to keep your project free of it, give it up right now.  Politics are inevitable whenever people have to cooperatively manage a shared resource".

That's a lesson I have to remind myself all the time in my quest for opening up my colleague to a different computing universe ...

Yves

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[Damien Baty (ML)]

   Note: this thread is getting off-topic, I guess.

Le 13/03/08 14:07, Moisan Yves a écrit :
>>From "Producing Open Source Software" by Karl Fogel:
>
> "In order to combat incipient territorialism, or even the appearance
> of it, many projects have taken the step of banning the inclusion of
> author names or designated maintainer names in source files ... A
> software project's source code files are the core of its identity.

   But then, how do you know who you should contact when you would like
to contribute? As the main developer/maintainer of a product, I would
definitely appreciate being contacted before someone mess with the trunk
of the code, or create another branch. (I reckon that this might sound a
little bit patronizing.) And as a potential contributor to a project, I
prefer asking the maintainer: am I on the right track, should I commit
to the trunk or create a new branch, is there anybody else working on
the same thing who I should contact? These are informations that might
not appear in source files or documentation.

> They should reflect the fact that the developer community as a whole
> is responsible for them, and not be divided up into little fiefdoms"

   It might be true for large code base (e.g. Plone), where
responsibility is naturally diluted because of the large number of
committers. And that does not cause a lot of problems since the barrier
of entry is relatively high, because of the size of the code base.
However, third-party products usually have a lot less developers
involved and are smaller. The barrier of entry is naturally lowered,
which is good because contribution is a key aspect of free/open source
softwares. But I do not think that a F/OS software has to a free-for-all
playground, where anybody can just "barge in" and mess with the code.
And I believe that having a defined maintainer or a list of people that
know how to help any new contributor is a solution to this potential
problem.

   Now I'm sure: this _is_ off-topic. :)

--
Damien Baty
Pilot Systems - 9, rue Desargues - 75011 Paris - France
Telephone : [phone] - http://www.pilotsystems.net
Free Zope & Plone hosting - http://www.objectis.org

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[Tarek Ziadé]

On Thu, Mar 13, 2008 at 2:39 PM, Damien Baty (ML) <[hidden email]> wrote:

  Note: this thread is getting off-topic, I guess.

Le 13/03/08 14:07, Moisan Yves a écrit :

>>From "Producing Open Source Software" by Karl Fogel:
>
> "In order to combat incipient territorialism, or even the appearance
> of it, many projects have taken the step of banning the inclusion of
> author names or designated maintainer names in source files ... A
> software project's source code files are the core of its identity.

  But then, how do you know who you should contact when you would like
to contribute? As the main developer/maintainer of a product, I would
definitely appreciate being contacted before someone mess with the trunk
of the code, or create another branch. (I reckon that this might sound a
little bit patronizing.) And as a potential contributor to a project, I
prefer asking the maintainer: am I on the right track, should I commit
to the trunk or create a new branch, is there anybody else working on
the same thing who I should contact? These are informations that might
not appear in source files or documentation.

I think *all*  Zope 2 style package should clearly define:

- the name of the initial Author
- the name of the releaser

These infos should be located ihmo in CONTRIBUTORS.txt

-> Now for new egg-based package, we do have everything:

the name of the author is in meta-data in setup.py, and the name of the releaser,
which is the person able to upload a new version to Plone.org and/or the cheeseshop

So we have everything available I think, and anyone who wants to contribute must talk to the person that has the rights to upload a new version..

I think the namespace discussion is out of date with eggs, since a company that creates an egg can use the collective namespace, and still has its name in the author field.

Tarek

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise