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/
Attachment:
signature.asc
Description: This is a digitally signed message part