[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Google Summer of Code 2006

On Thu, 20 Apr 2006, Free Ekanayaka wrote:

I see your point. Maybe we should update the wiki then, and talk about
"internal"  and "external" CDDs  (or  whatever naming we prefer)  with
respect to Debian.  The list at  the bottom of  the wiki includes, for
example,  both  projects like  Debian Junior  and  Debian Med, which I
think are  fully "internal" CDDs,  and  others like Skolelinux Lliurex
and A/DeMuDi, which  as far as I  can tell are  "external" CDDs as the

My personal understanding was that they are "CDDs in spe" in the sense
that our CDD tools are not yet fit to solve their needs and my dream
of a Summer of code work would be to enhance the tools to get rid of
the show stoppers here.

ship some  packages which are  not in Debian   (e.g.  the ones holding
customization  data, or   rebuilds  of  official  packages)  and  have
different release schedules.

We talked about ideas to decouple the release schedule inside
Debian.  The issue is not yet solved but there are chances to
get this working.

Well, I definitely agree that being  all "internal" would be the ideal
solution and "the right way".   However in the real  world this is not
possible, especially if you  are delivering a  CDD as product to  some
customer.  Maybe  you need to see your  patch applied in some package,
and  the official  maintainer is  slow   or busy  or simply he  thinks
different than you: in such a case you are compelled to build your own
version of that package.  Or maybe  you have a  deadline and you can't
wait for the next Debian release. This doesn't necessary mean that you
are  "forking", at least  if you do so  you  should strive  to get you
changes eventually integrated back to Debian. At least  this is what I
found myself to do.

Didn't we talked about enhancing Debian in the scope of CDD?? ;-)
If we would get a lever on slow or busy maintainers because CDD
will become some _internal_ importance by implementing more maintainer
groups for important packages - why should we ignore this lever?

As I said,  it might not yet implement  any feature we needs, but  the
code is there, and I think is a very good starting point.

How does it compare to the toolkit Sergio announced?  There
are at least two starting points.

Kind regards



Reply to: