Debian Automatic Manager
Hello All!
I am new to debian development. I wanted to buy a debian release two months
ago. And I had to wait to Slink because it was foolish to buy Hamm when the
new release was about to go out.
So, I had a lot of time to think about debian management, and I want to share
with you some of my thoughts.
I have looked also in Debian Weekly News and found out that the Management of
debian is a subject that was discussed many times in the past.
Many of those ideas looks like my own, but I want to present my idea as
coherently as I can, and later discuss the relationship to other ideas.
The highlights of my proposal is :
1. Debian will be Managed by an Automatic tool (with enough flexibility
to correct everything manually)
2. There will be always a Stable version that is updating continuously
and it is free of any knows bugs
3. There will be always several versions with constant known level of
stability.
4. A package in the Stable version will advance more freely than today.
Now for the details (if there will be interest I will try to write a full
spec).
There will be a package pool that will contain all versions of all packages.
And there will be a tool which is a little like a version control tool (like
CVS).
For every package there will be one version that is part of Stable version.
Every version have to pass several stages until it is able to enter the Stable
version.
I will make a basic suggestion of these stages, we can decide to add or to
delete stages whenever we want.
Lets take the following stages : "new version",
"fix dependencies","frozen" and "stable".
For every package there will be one version for every stage labels.
So, every stage label is defining a release (i.e. the "stable" stage label
defines the Stable release, the "frozen" stage label defines the Frozen
release and so on). One version can have several stage labels.
Now we have to define the logic that causes a version to move between stages
(this logic can be complicated and it is the fine tuning of this logic that
will make this automatic system a good manager).
I will try to sketch some basic logic which will have to be refined.
typically a new version will get the label "new version" (and thus enter the
New Version release, where there are only new versions).
The New Version release is highly unstable.
I think that with automatic manager we have the chance to manage debian on
a package basis and not on a full release basis.
For that aim, what is important for every package is the group of packages
that the package depend on (which I will call Basic packages),
and the group of packages that depend on the package.
When the Maintainer is uploading a new version (to the "new version" stage)
s/he have to say if there are some Basic packages that have to be updated.
If there aren't such Basic packages then the version is advancing to the "fix
dependencies" stage. If there are such packages the version stays on "new
version" and a note is sent to the Maintainer of the packages that need
fixing.
When those packages are being fixed the Maintainers of those packages inform
The Automatic Manager) that the fix is related to the dependencies
problem, and when all the problematic Basic packages are fixed the version
can advance to the next stage (the advance is done simultaneously with the
Basic updated packages, That is all packages that are dependent advance at
once)
In the "fix dependencies" stage every package that depend on the current
package is informed that there is a new version. The maintainers of those
packages have to confirm that their package is compatible with the new
version or make a new version to fix some incompatibilities.
After all the dependent packages are OK the version advance to the "frozen"
stage. Here it will stay for sometime (every package can have its freezing
time) for testing by Debian developers. And after some fixed time that
the version doesn't have bugs attached to it the version is finally allowed to
enter the Stable release.
If a bug is detected with a version in the Stable release, the automatic
Manager immediately removes it from the Stable release and an old version
is taking its place in the Stable release.
we can add a stage called "minor bugs" for versions that have only minor bugs.
a note: the "fix dependencies" stage is meant to address the problems of
packages like gnome that are not very stable and a lot of packages
are depending on them.
This system have to support some types of queries. For example:
1. Get a list of all versions in a particular stage (this query will be used
by mirrors that want only the Stable version or by developers that want the
latest Frozen version)
2. Get a list of all packages that where updated since date xx-xx-xxxx in
a release X (where X is a stage label)
3. The user will supply a list of his current version (for every package
what is the version he has) and the system will produce a list of packages
that the user should update in order to reach some X release (where X is
a stage label)
4. The user will supply a list of his current system and ask what are the
upgrades/downgrades s/he have to do in order to upgrade package X.
The project leader can assign at his will a standard version names to the
Stable release every now and then.
For example the logic of the version names can be every six months a new
version or every time a major version of glibc is moving to the Stable
release.
Well, what do you think?
chen ofek
____________________________________________________________________
Get free e-mail and a permanent address at http://www.netaddress.com/?N=1
Reply to: