About basic rules of package maintenance in Debian

[John Paul Adrian Glaubitz]

Dear fellow Mate packagers,

today something happened which is very unfortunate for the MATE
packaging in Debian and which makes me have doubts that some of
the people involved in the MATE packaging actually know what they
are doing and are aware of the responsibilities they have as someone
with full access to the Debian FTP servers.

When Stefano and I started working on packaging MATE for Debian, we
agreed on uploading only stable releases to Debian unstable which
is common practice for all other major desktops used in Debian
(KDE, GNOME, XFCE). The reason is that both Debian and any of
the desktop environments have long release cycles and it is very
difficult to coordinate the availability of the latest stable packages
of a desktop in Debian when we're about to freeze.

Since desktops consist of a large number of packages which take
some time to be packaged and migrated into testing, it is very
important to be have always a consistent and stable set of packages
in testing such that when the freeze happens in Debian, the set
of desktop packages is ready to be shipped in stable beside some
minor bugs. Once we're frozen, it is NOT possible to upload new
upstream versions.

MATE and many other desktop environments use odd version numbers
to indicate that the particular package is a development version
which is the case for 1.7.0 as well.

For some reason, Mike Gabriel has now uploaded development versions of
both mate-common and libmatekbd into unstable. There was no announcement
and no coordination whatsoever. He just bumped these packages
to a completely new upstream version, ignoring the fact that this
will break MATE for all people which are using 1.6.x from the
MATE Debian repositories and the fact that he is introducing a
development version of MATE into Debian unstable which is completely
undesired as explained before.

We are now facing the situation that we basically have beta versions
of MATE in Debian unstable which we need to get rid of. Since it
is not trivially easy to remove packages from the Debian archives,
we will have to manipulate version numbers in order to fix the
issue. For that matter, there are two possibilities.

One of them are epochs, the other ones are version numbers of the
scheme 1.7.1.really.1.6.1-1 which will overwrite the 1.7.x
versions.

We should discuss on how to resolve the issue and I would especially
like to hear from Mike why he acted the way he acted since I have
to say I am rather surprised to see such behavior from a Debian
Developer who should know how the archives are working. The last
time someone acted (repeatedly) in such an irresponsible way, he
was demoted from being a Debian Developer to the status of a Debian
Maintainer.

Regards,

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913