Re: Google Summer of Code 2006

[Free Ekanayaka <free@miu-ft.org>]

|--==> Andreas Tille writes:

  AT> On Thu, 20 Apr 2006, Free Ekanayaka wrote:
  >>Well, I  think that the force of  PDK is that is  a rather general and
  >>flexible  tool,   which  can   be    used  both   to generate    fully
  >>Debian-contained CDDs,

  AT> No doubt about this - I've read the description, but CDD has more goals
  AT> than just creating CDs.

Definitely, PDK could be just a  tool for those goals,  and I think it
fits.

If you  we  limit our scope  to full-Debian  CDDs, which  contain only
official Debian   packages and are released  when  Debian is released,
probably PDK is overkill, as its main advantage  IMO is to effectively
address     the problem  of  having   different  release schedules and
development phases than Debian.

However if you take into the scope even CDD developed by third parties
(and it's  becoming  more and  more   common), for supporting  special
groups of customers, then you definitely  need a tool  like PDK, as in
real-like you'll definitely need your own packages and releases.

As PDK can handle both scenarios,  I think it  is worth to consider it
as a possible standard too for CDD creation  and maintainance. I think
the arguments in its favour is that is already  rather mature and well
designed, and it's fully free software too, so  if we can change it if
needed (as I'm currently doing).

>>which are released when Debian is released, and
  >>"independent" derivatives too,  where   external means that   1) there
  >>might be additional packages which are  not included in Debian

  AT> ... so we would leave the CDD area (which is mainly my point).  We have
  AT> no control over the quality of this stuff.

Mmh,  of course Debian will guarantee  only  the quality of plain CDDs
(or  internal  projects)  where all  packages  come  from Debian,  and
releases are  synced  with Debian releases. Third   parties developing
CDDs with external packages and different release schedules, will have
to take care of them.

As I said PDK, can fit both cases.

  >>2) they
  >>have a different release schedule than Debian. So it's a matter of how
  >>you use it..

  AT> ... and how you define the noun "Custom Debian Distribution". (Yes,
  AT> I know the noun is and was missleading and I hate that I agreed to the
  AT> name change from "Debian _internal_ projects".)

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

  AT> So nothing against PDK but it will probably not work
  AT> for CDD development.  For instance I do not see a way to make use of
  AT> Debtags in PDK which I would really like to see in CDD tools.
  >>
  >>Actually there are plans to add support  for it (I suggested it myself
  >>[0]:), and it would be relatively easy.

  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. The fact that  PDK
allows more possibilities and third party CDDs,  doesn't mean that you
can't make internal CDDs with it..

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.

Cheers,

Free