On Wed, 2008-04-16 at 15:59 +0200, Ondrej Certik wrote:
Thanks for the reply. As I said, I am not questioning new SONAME bumps
going into NEW.
The question is, whether the DMs should be allowed to upload SONAME
bumps to NEW by themselves or not.
Umm, I would have to say no. Sorry.
SONAME bumps are just too disruptive IMHO.
I agree there should be a special
attention to SONAME bumps and that's what the NEW is for (or any other
queue as you said).
NEW is a step that can help with SONAME bumps but it is not sufficient
on its own. SONAME transitions MUST be coordinated amongst all the DD's
(and upstreams) involved. Such uploads can take months to arrange and
coordinate - your sponsor is best placed to deal with these issues.
More haste, less speed. DDs can make mistakes but DMs are not full DDs
and as such, the intervention of a DD is appropriate when the potential
upload could cause havoc in the rest of Debian (IMHO).
It's all about how much trust you give to DMs. Imho if they are
allowed to upload new revisions and even new upstream (if the name of
all the binaries and the number of them stays the same), they can
screw up a lot of things.
Not as many as a SONAME transition. Any library upload can mistakenly
result in a broken API/ABI but normally that only affects one part of
the library functionality.
A new SONAME is a completely NEW library - there is nothing that says
that libfoo1 has to have *anything* in common with libfoo2 at a binary
or source code level. It might do the same things on the surface but
during a SONAME change, the library upstream can change 100% of the API
and touch 100% of the source code. Every single header filename,
function prototype, typedef, macro, struct and variable. e.g. some
SONAME bumps have involved a complete renaming of the functions and
variables to a new namespace - FooFunc becoming foo_func etc. and with
structs going the opposite way from foo_data to FooData. Yes, the
principle of the library stays the same and it works in a similar manner
once the reverse dependencies are rebuilt but nothing else is the same.
After all, Debian is STILL carrying gtk1 - that should give you some
idea of the disruption caused by SONAME bumps. The consequences of a
single upload can take YEARS to resolve (and still involve the removal
of otherwise usable packages).
A new application can change 100% of the source code without problems -
many do change as much as 50% at each major release. Changing the
behaviour of a shared library has far wider implications. The two simply
cannot be compared.
I maintain (and co-maintain) a range of libraries, some upstream too - I
can honestly say that I would not consider any of those as suitable for
DM-Upload, even without changing a SONAME.
So giving them the right to also upload new
binary packages to NEW imho belongs to the same cathegory.
Not even close. IMHO, the very fact that you equate those two makes me
doubt that you properly understand shared libraries and SONAME bumps in
Debian.
An upload of a new application is nowhere near as complex as the upload
to start a library SONAME transition. Even uploading a new library never
seen in Debian before is easier than starting a SONAME transition for a
library that already exists. I'm sorry, merely by equating those two you
have lost all credibility in my eyes.
It's not just about trust, it is about coordination, planning and
ability. If you think that a SONAME transition is no more disruptive
than a new application then I have cause to worry about your ability to
maintain a library in Debian in the first place. It doesn't give me any
confidence in you or in DMs in general.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
