El Fri, Sep 24, 2004 at 09:35:40AM -0400, Benj. Mako Hill va escriure:
> Greetings!
Hello!
> This morning, I wrote short piece on Ubuntu, CDDs, and the potential
> for collaboration and some of the potential hurdles I thought this
> presented. I posted this on my blog and that those of you that read
> planet.debian.org may have already seen it. I've attached that little
> article to this email. Feel free to follow up here.
I'm going to answer you here as you request, seems more appropriate than
through blogs :)
> Ubuntu and Custom Debian Distributions
[...]
> The idea behind a Custom Debian Distribution is, to borrow Enrico Zini's
> terminology, to be global and local at the same time: to create an OS and
> set of applications that is targeted to a specific group of people and to
> contribute and collaborate within a larger community in a way that lets
> people without interest in that niche group benefit and for you to benefit
> from the work of people without interest in that niche. This is basically
> what Bdale Garbee talked about when he was talking about flavors in [1]his
> 2003 DPL platform. I suspect people are hanging on to their
> one-flavor-fits-all model because they haven't seen a compelling
> implementation of an alternative. I think that its the job of those of us
> that are sold on the idea to give them one (Thanks to everyone that has
> and continues to work on this in the CDD community).
Well, in fact the one-flavor-fits-all is a good thing and is one of the
things that makes Debian good for Customization, but I see it as with
clothes, you can buy something that is OK for you but generally there's
something to arrange to make it fit you. I believe that we need both things,
a good general purpose framework (Debian), and the ability to customize it
for special uses (tools and support for CDDs).
> Now as a few people know, I'm complicit in this whole [2]Ubuntu
> Conspiracy. When Mark Shuttleworth first approached me about the project,
> the first thing I thought about was Custom Debian Distributions. I wasn't,
> and am still, not exactly sure how those things relate exactly.
I also thought about this when I learnt about Ubuntu, manly because it had a
lot of DDs working for them and it looked like they were proposing to do
things the Debian way, at least much more than other prior Debian Derived
Distributions I've seen.
> From a technical perspective, it's manageable. Ignoring project
> affiliation and institutional relationships, we might say that CDDs are
> about creating and maintaining a derived version of Debian over time and
> in way that offers all changes back to the pool of Debian (Debian won't
> take all). Forking in the traditional sense is one thing -- and it's
> relatively easy; going out of your way to share and collaborate within the
> Debian community is one way to define a CDD.
My idea is that we don't need to *derive*, what we have to do is make Debian
able to adapt to our Customization needs. The main problem with forking is
that it is easy initially, but once you deviate from the main project
(Debian in this case) it gets harder and harder to keep in sync.
> So it's simple if we, for the moment, think of Debian as a single
> monolithic blob -- forget subprojects and CDDs. We can break the goals of
> a any Debian derivation down into three basic types of customization:
>
> * Package selection: Which software in Debian does the deriver want to
> include?
> * Package configuration: What configuration changes does a deriver want
> to include (anything you can do with debconf/cfengine)?
> * Package replacement (for lack of a better term): What packages does a
> derivative want to ship that has diverged from the package in Debian
> in terms of code (bug fixes, features, whatever)?
For me the first two are present in all CDDs, but I would split the third
one in two types of customizations:
- Package **data** replacement: for a lot of CDDs what is needed is the
addition or replacement of data included in a package for different
purposes (branding, menu modifications, localization, etc.)
- Package **updates**: Debian release system is too slow for a lot of CDD
needs, so usually the problem is that the versions included in stable are
too old or have non security related bugs that are not going to be fixed
(for stable, of course).
> The problem (for my simplified model for explaining Debian derivatives --
> I don't think it's a problem in general) is that some people are working
> within this framework in ways that are visibly connected to the Debian
> community and some people are not and don't want to be. Basically, Debian
> is whole lot more complex than just a ball of code.
Well, in my opinion both groups could work with the same tools and
collaborate with Debian, but the Debian Developer community has to be
convinced that it is worth, for example by making their packages more
customizable.
> In Jeff Licquia's blog, he mentioned that Ubuntu is a fork. In a way he's
> correct and in a way he's not. I think part of the problem is that
> "Debian" refers to a long list of things. Just to start we've got:
>
> * Debian: the group of volunteers;
> * Debian: the "project" with a Constitution, leader, and decision making
> structure;
> * Debian: the ball of code (But which ball of code? Stuff on Alioth?
> Stuff in contrib? Stuff in the Debian-NP archive?);
> * Debian: the infrastructure that runs the code together;
> * Debian: the shared goals and the action of sharing (you share within
> the Debian community -- you are part of Debian);
>
> This creates problems and uncertainty that we in the CDD community has
> been grappling with for a long time: Is Debian-Nonprofit Debian? Can any
> CDD really be Debian?
Does it matter? IMHO, if the Customization we need can be done using Debian
as a base and all the resources (people, organization, etc.) are taken from
it, a CDD is just a set of packages is the archive.
> Of course, coming from the Debian community, the CDD community began with
> the answer ("yes") and then went about trying to create and argue a
> justification. We've even defined the technology based on what would or
> would not allow us to honestly call ourselves "Debian" and have attempted
> to grasp onto definitions of "Debian" that make that possible. Debian-NP
> and every CDD is still trying to figure out what it means to be Debian and
> Debian-NP at the same time -- how does one strike that balance?
>
> Ubuntu starts out with an answer as well. Ubuntu is not Debian and I
> suspect this is what Jeff was referring to. Ubuntu wants to do things that
> Debian can't, won't, or just isn't all that good at and thare is great
> room for synthesis here.
And that's a good thing, because if ideas and code developed inside Ubuntu
are good, probably they will be included in Debian as well, and maybe Ubuntu
will be able to try things that are difficult to do inside Debian because
it's size and heterogeneous group of developers.
> My concern is that the political side of things -- the "who is Debian and
> who is not" -- risks driving a wedge between the technologies being used
> by those customizing Debian from the inside and from the outside. People
> don't work together because they are "not part of the same project" when
> they have every technical and strategic reason to collaborate.
>
> Basically, I think we should let Debian stand for something political: an
> organization. When it comes to code, I think we should forget about this
> and find creative ways to work together.
Sure, and this post is one step on the right direction, what we need now is
coordination and documentation from all interested players; Andreas has done
a great work on this issue, but it seems that there is a lot of work being
done on CDDs that is undocumented or unknown to a lot of us.
> I want to see Ubuntu, Progeny and the other Debian derivers work closely
> with the Debian derivers within Debian. I want this work to lead to
> systems of common infrastructure that makes applying the the different
> types of customization something resembling a standard. That's only going
> to happen if we all try. That doesn't mean there will be One True Way --
> there won't. It does means that everyone is going to have to be flexible.
> I think ultimately, it will be worth it.
Yes, that's what I'm proposing since February in different forums, the good
thing is that there is a lot of movement in the right direction lately, at
least as I see it.
Later I'll post a short summary about what are the current CDD issues as I
see them and the solutions I know that are currently in use or planned.
The issues are all included on the CDD talk I gave in Manresa, you can see
them starting here:
http://people.debian.org/~sto/Manresa2004/html/text13.html
or here:
http://people.debian.org/~sto/Manresa2004/html/img13.html
What I would like is to complete this list and agree on the common issues
and solutions to add or update the CDD paper and coordinate the development
of the different groups / distributors, if at all possible.
Greetings,
Sergio.
--
Sergio Talens-Oliag <sto@debian.org> <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69
Attachment:
signature.asc
Description: Digital signature