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

Re: Google Summer of Code 2006

|--==> Andreas Tille writes:

  AT> On Thu, 20 Apr 2006, Free Ekanayaka wrote:
  >>Definitely, PDK could be just a  tool for those goals,  and I think it

  AT> Perhaps you dived deeper into the details than I. I had only a some
  AT> minutes view onto the web page.

Yes, the web documentation  is not very well written  and a bit out of
date at times.

  >>However if you take into the scope even CDD developed by third parties
  >>(and it's  becoming  more and  more   common),

  AT> Well, according to the Definition of a CDD at
  AT>            http://wiki.debian.org/?CustomDebian
  AT> something *like* a CDD developed by third parties is actually no CDD.
  AT> I do not say that something is wrong with an external CDD-like thing,
  AT> but I would love if we stick to our nomination to avoid confusion.
  AT> It is completely OK if somebody outside adopts *some* main ideas from
  AT> the CDD effort but one of the main ideas - to make Debian a better
  AT> system for any purpose - can hardly be fulfilled by things done outside.

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
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.

  >>I don't know, maybe we could talk about internal CDDs (completely made
  >>inside Debian) and third party CDDs..

  AT> Perhaps we should go for another "name change" and put the internal
  AT> in the name of the beast.  I have heard so much confusion and my guess
  AT> is that more than 50% of subscribers to this list did not noticed this
  AT> special feature (which also does not hurd, because finally we work on
  AT> the same goal to support our users).  But IMHO staying inside is
  AT> "the right way" (TM) and it's time to stress this point again (I did
  AT> not so for this year and DebConf is approaching so this should be
  AT> said again. ;-)

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.

  AT> Which would be great and as I said the tool itself sounds very cool
  AT> and we might be able to adopt things (or port it to a Debian internal
  AT> tool) but we just leave the goal we defined for a CDD.
  >>I don't see why  we leave that goal of  plain CDDs.
  AT>                              ^^^^
  AT> There are more than one goal and perhaps my sentence was not precise
  AT> enough: We leave the scope of the definition.

Yes, what  I meant is  that, technically speaking, you can effectively
use PDK to  build "internal" CDDs, without  going outside the scope of
the definition.

  >>The fact that  PDK
  >>allows more possibilities and third party CDDs,  doesn't mean that you
  >>can't make internal CDDs with it..

  AT> If it is more than a ISO-builder for a customized installation CD-ROM
  AT> that contains Debian packages with adopted configuration, but also
  AT> can handle Dabtags (it's nice that you supported this) build meta
  AT> packages, can care for user menus etc than it's fine.

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.

  >>Of course, as PDK reaches a production-ready stage, I'd like it to see
  >>it in Debian, and I can maintain it if need.

  AT> PDK inside Debian would be a precondition for me to agree that it is
  AT> able to build a CDD (according to the current definition).

For sure.



Reply to: