[Chandler-dev] Keeping Feed and other parcels out of the end users' binaries

[Philippe Bossut]

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