Hi,
Yesterday during the engineering meeting
(http://wiki.osafoundation.org/bin/view/Journal/EngineeringMeetingNotes20060831),
we discussed the wisdom of bundling parcels with the end user binaries.
It's an interesting story with several levels so I'm going to bullet
point it to make the discussion easier.
Status and Issue (in no particular order):
- The Feed parcel was originally developed as a "proof of concept" of
how 3rd party parcels ought to be developed. At the time it was known as
Zaobao.
- As it was the first of its kind, the Feed parcel evolved into an
"example" parcel which is the basis of the parcel tutorial
(http://chandler.osafoundation.org/docs/0.6/feeds-tutorial.html). This
is the one devs goes to learn about parcel development. We get all our
interns for instance to go through it as a learning experience.
- After PyCon 2005 we added a couple of other similar 3rd party parcels
developed during the sprint (Flick, Amazon, EVDB). Those are also part
of Chandler's svn trunk right now.
- Some users (interns for instance) considered that the Feed parcel was
actually a bona fide core feature of Chandler and were expecting a level
of support and polish as good as the other features (say, calendar).
This is clearly a misunderstanding. Note however that one could argue
that, may be, such a feature should be in the core set of features
considering its popularity. Debatable. For now though, we're not
investing in making it such.
- We are not spending any PPD or even dev time on parcels beyond making
sure we don't break them. So we update them when we change APIs for
instance.
- We moved to egg: just to contradict a little the point here above, we
did spend dev time recently on parcels in 0.7alpha4, moving their
packaging to egg.
- Supporting parcels: we do not want to support end users having
problems with the Feed (and Flickr, Amazon, Photo and EVDB) parcels in
the 0.7 time frame. We'll have enough work with the core features
(calendar, email, dashboard...). If we don't do anything though, we'll
get bugs and requests from end users on the features provided by those
parcels.
Proposal: Objective: prevent support issues with those parcels from end
users while continue to promote the development of parcels by 3rd party
developers:
1- The "business as usual" part:
- Continue to maintain the current set of parcels: there's no reason to
change svn, functional tests and our way of working as devs. Since we do
want to make sure Chandler can be expanded, we need to make sure we
don't break this too badly.
- Don't invest in improving the parcels themselves: as above but for
PPD, we're not trying to improve those UIs and, unless devs have an itch
to scratch, we're not investing dev time in polishing them either. We
just want them to continue working and pass functional tests.
- Don't change anything for the source code distribution (tarballs) or
debug builds: those are used by developers (likely) and we want them to
have as much things as possible to do their job.
2- The "changes, work to do" part:
- Provide end users' binaries *without* those parcels: this is a change
compared to our current way of doing things. End users' distribution
won't include those parcels in the binaries. Users won't get those
parcels from the official build page and milestone builds
(http://downloads.osafoundation.org/chandler/milestones/). Currently,
the only parcel I think makes sense in an end user distribution is
Ashkan's Chandler-EventLoggerPlugin, since, precisely, its objective is
to learn more about end users patterns.
- Provide those parcels as downloads in an egg form: this is may be too
much for the March time frame but, eventually, we should provide those
as download off a "parcels" (or "extensions", or "plug-ins"... but I
don't want to start another marketing naming battle here... :) ) page.
That would be a good way to seed and test such a system. I realize
writing this that this is a sizable project if we want to do it right so
I'm not setting any time frame on purpose. We could in the meantime
provide the eggs for download off a Wiki looking pages as we do for
snapshot builds so, for those who want them, they're not impossible to
find in a user digestible form.
I may have forgotten a couple of things (pros and cons doing this) but
that's all I can muster right now on this subject.
Thoughts?
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
