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

Re: Google Summer of Code 2006



On Thu, 20 Apr 2006, Darrin Thompson wrote:

           http://wiki.debian.org/?CustomDebian

Glad you posted that link. Please forgive my previous ignorance.

No problem at all.  It is no shame to belong to the estimated
50% that do not know it - it's our fault if we are to lazy to
advertise it more and I admit that the CDD effort might be kind
of an evolutionary pool.  Lets see what works most successfully.

Would a tool that can perform a superset be acceptable?

It is perfectly acceptable and probably very useful.  My only
point is that it helps if we use the same terms in a discussion
to understand each other.  The term "Custom Debian Distribution"
has proven to be to generic to unmistakably make clear what we
want to describe.  Acceptable is anything that helps our users,
but it is not acceptable to confuse our users by confusing them
with unclear terminology.

And more importantly, would you find it fun to work on it?

No, I have no fun on working on a superset of Debian.  I found
more work even inside Debian to enlarge my field of work.  I
would love if I would be able to do about 10% of the taks I
would regard as a perfect target for work.

I have unusually wide
technical control of the project (for a company engineer, you know?). So
if there are compromises needed to make the project useful for a wider
pool of users and developers, I'm all for it.

It's fine if others do the work I have no time for.  Even if
I would personally dislike it - do you think I would be able
to stop anybody doing it? So the question is needless.

I'd be tickled pink if I could host code that drives CDD projects in
PDK, and I'd completely understand if you chose to do your own thing.
(Hey, we did. We think our needs were unique, but that isn't so unique.)

To make one thing clear: I do not want to keep CDD inside Debian
to exclude others.  The idea is just the other way around: Enable
derivers of Debian to derive much more easily than they do it now.
For instance my basic idea of Debian-Med is to give a (not yet
existing) company that provides medical services based on Free
Software a tool that works out of the box for their needs.  In
practical world any computer is a subset of the whole Debian and
we want to simplify this subsetting for special groups of users and
I'm absolutely convinced that the easiest way to do is to do it
inside Debian.  Every other approach will end in a reinvention of
the wheel for every single user group / internationalisation group /
whatever group.

There is one possible conflict. I'm hoping to keep PDK in what I call
perpetual beta. As time goes on, the ongoing cost of maintaining an old
distro tends to increase. As time goes on PDK improves, lowering the
cost of maintaining your old stuff.

One reason to keep the tools to build CDDs inside Debian
is the fact that it has to work with up to date packages to
not collect RC bugs.  This ensures that maintainers are
forced to keep the stuff up to date.  Any chance to do
this without endless patching and keeping your patches
up to date?  If you can *act* inside you can work on a
common strategy at the basic source (not source code - but
the philosophical meaning) instead of just having to *react*
to a change you have no influence on.

Kind regards

         Andreas.

--
http://fam-tille.de



Reply to: