On Thu, 25 Jan 2007 06:42:34 -0800, George Lee
<
[hidden email]> wrote:
> (1) The people working on other calendar projects -- what is your
> opinion about
> work on CalendarX? Does it fill a role that others don't, do you really
> see it
> just duplicating functionality, what would be most productive for
> CalendarX to
> incorporate from other products, what would be most productive for it to
> focus
> on, etc.? My hope actually is that there is some stronger generic
> calendar-constructing code in its own lib or python product that a
> modernized
> CalendarX will use but other products can use too; I know some exists in
> calendaring, etc.
I am not working on any of the calendar-based projects, to take my opinion
with a grain of salt:
- It seems like the major value of CalendarX is that it has explored a lot
of the common use cases and templates needed
- It seems like P4A calendar has a better infrastructure
These things are just from reading the various lists, though — so it's
definitely an uninformed opinion.
> (2) Is there interest on working together on CalendarX or other calendar
> functionality?
If we could make one calendar project instead of two (and if not, I would
love to know the reason why), that would be the best.
> (3) What do I need to do to move CalendarX over to the Collective?
http://plone.org/documentation/tutorial/importing-product-into-collective> - Are there legal issues? CalendarX is GPL but does something need
> to be
> indicated about who owns other rights to it? (I don't understand the
> relationship between GPL, copyrights, etc.)
Copyright and licensing are two related (but different) matters. The
author usually retains copyright of the material he has produced, but the
license says that it can be reused in other projects as long as they
follow the conditions set out in the license. In general, this isn't a
problem unless you believe in software patents.
> - Right now it has a CVS repository; how does this get changed to
> the SVN
> set up?
We can import the history if required (this is more work), or if you don't
need the project history, it's easy to import (for example) the 2-3 main
branches using SVN import. In general, the history of the app is available
on SF.net, so I wouldn't worry too much about that. For a project like
Plone itself (which has a lot more structure, contributor agreements,
copyright assignment to the Foundation etc), it makes a lot of sense to
centralize the history, but add-on products seem to get by without history
in the same repository since they usually have fewer developers and always
move forward.
> - The current code structure uses different version numbers to
> indicate a
> few different major branches, which is not the standard use from what I
> understand. Is it best to maintain that?
Standardizing the branches in the same way as most projects in the
Collective use is recommended to minimize confusion — but you're
essentially free to do whatever you want. It's easier for people to help
out if the structure is predictable, though. :)
--
Alexander Limi ·
http://limi.net_______________________________________________
NGO mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/ngo
