Hi Scott, I have uploaded the 3.7.0-5 version into DELAYED/5 queue. Feel free to cancel/reschedule or just let me know, if you find some issues in this version.
Best regards, Anton 2013/5/22 Scott Howard <show...@debian.org>: > On Fri, May 17, 2013 at 1:47 AM, Anton Gladky <gladky.an...@gmail.com> wrote: >> Hi, >> >> I have done this upload, sorry if I broke something or offended somebody. > > I'm the one that should apologize, I saw that you did contact me on > April 26, but I failed to respond. > >> >> Ok, if you want, I will create libalglib3.7.0. But I do not know, whether it >> is necessary for >> the package, having just qtiplot in build-rdeps and with popcon 33. But you >> are the >> main maintainer, you should decide. > > qtiplot's popcon is 1091, libalglib-2.6.0 popcon was several hundred, > libalglib3's popcon is 33. > In the past we had a problem where people did uploads to alglib that > broke alglib because they don't follow reasonable versioning. In fact, > alglib used to have a blurb on their website about how they don't > believe in build systems and everyone should hardcode their code into > projects. > > >> Why, actually, the version 2.6.0 has been uploaded into Debian on "06 Mar >> 2011", >> if it was half a year obsolete and unsupported by upstream? The version >> 3.3.0 was >> already available [1]. > > the only depending package in Debian required version 2.6.0, newer > versions broke that package, so we kept it until someone needed a > newer version (which is now, apparently). > >>> Does another package need it? >> >> >> Yes, not (yet) uploaded into Debian. > > this is a good reason to work it out. > >> >>> >>> 2) Why did a team upload switch from autotools to cmake? >> >> >> 3-versions are completely different from 2-vesions. It was rewritten from >> scratch. >> And yes, personal preferences. Why did you ask about that after uploading >> the >> package? > > Personal preference is ok, it is just something you avoid doing on NMU > and team uploads without checking with the maintainers first (which > you tried to do, but I missed the email) > I'm OK with cmake, could we set the "release" ldflag instead of > "version" as to not set the SONAME? I know how to do this in autotools > but not with cmake. This would be similar to how libalglib-2.6.0 did > it. > >> >>> >>> 3) Why did 1 and 2 happen without consulting with the current uploaders of >>> alglib or the depending package? >>> >> That is not true and I am surprised, that you decided to discuss it here: >> 1) I sent you and your co-maintainer an email with patches on alglib on >> April 26th. >> 2) May 5th the package has been uploaded into experimental. >> 3) May 15th, the package has been uploaded into unstable. >> >> The first communication with you was on May 16th. >> >> So I think, the second part of the bug is not RC. >> Again, sorry, if I broke something. I will try to be careful next time and >> ready for co-maintaining. > > Yes, I'm sorry I missed your email on the 26th. If I didn't turn you > off already, you're more than welcome to become an uploader/maintainer > of this package. > > I appreciate your work, sorry about the miscommunication. > > Regarding the RC part - we should consider how to future proof the > versioning. I prefer the "release" flag for alglib since they don't > use sane versioning [1]. We could set the SONAME to 3.7.0, like you > suggested, as well. In my opinion both are acceptable. If you'd like > to add yourself as an uploader and can choose which way you prefer. > > [1] http://www.sourceware.org/autobook/autobook/autobook_91.html > > Regards, > Scott -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
