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

Re: Ubuntu and CDDs



On Tue, 28 Sep 2004, Benj. Mako Hill wrote:

What do you do when you have a fix or a low priority debconf that the
Debian maintainer says no to? What if they don't say no but they just
don't answer your emails? What if it's a very important package that
you can't NMU for what is, in the BTS, a minor or wishlist bug but
that is essential to your use? What you sometimes *must* do, from an
absolutist technical position, is forking and I don't think this needs
to automatically be a bad thing.
The problems you described should be exceptions from the normal and ...

I think the fundamental difference between CDDs and projects like
Ubuntu is a political one. Which one has its homepage on
www.debian.org? Which one is bound by the technical committee's last
final word?
... solvable by the technical committee.
We should not invent forks for things which are broken inside Debian
but fix the things which are broken.  At least this is my opinion about
the Debian way to go.

Canonical will guarantee 18 months of support, security and data loss
bugs for every stable release and will not charge for this. The
Yesterday I had a talk with a representative of Oracle.  He said something
about fife years of support for RedHat and SuSE.  May be 18 month is to
less if we want to target for the enterprise.

Yes, but sarge is being released *years* after everyone expected and
had been told. Debian's release behavior makes it unsupportable and
unsuitable in the eyes of many users, vendors, companies, and
governments.
I guess we as developers are thinking different than the major group
of users.  (See my other mail in this thread.)  The average user of
a computer wants a system which never changes its behaviour.  But those
people are normaly not active in mailing lists and thus this opinion
simply does not come to our "narrow minded" eyes.  Well, I also would
love a shorter release cycle but I do not see this as the main problem
we have to solve.  The problem is that we claim to support users but
we only care for those people who shout loudly in mailing lists for
the latest and greatest version.  But these people are a minority and
moreover - they have enough skills to fix this problem by either supporting
Debian instead of shouting or install the latest and greatest themselves.

My entire point was that all derived distributions and all CDDs are,
from a purist technical level, forks and we need to drop the stigma
around this.
As far as I know Debian-Junior and Debian-Med (which are the CDD I'm
involved closely) I see no single point which speaks for your forks
theorie.

The differences are political and organization. Once we
realize this, we can focus on the technology, the CDD framework in
this case with a larger group of people and we can decide where we can
and can't work together which.
I have no problems with this and surely the people who are really doing
a CDD decide what to do.  IMHO we were drawn back in a naming discussion
again and I really hate these.  I also will not repeat my constraints
about the name, but if we found the definition that a Custom Debian
Distribution is something inside Debian we should immediately stop
that discussion to not confuse our users (and me) and find a different
name for that what you proposed and change the cdd-doc to reflect this
*other* thing.

I don't care if there are 10,000 "forks" of Debian as long as they are
"forked" in such a way that they are working together. :)
Well, at least this is the main important point and I agree completely.

Kind regards

          Andreas.



Reply to: