[01:51] <handsome_feng> tsimonq2: Hi, sorry to trouble you, will you have time to upload ukui-panel today? It's a very important package for us.
[01:58] <tsimonq2> handsome_feng: I will.
[01:58] <tsimonq2> handsome_feng: It's the next thing on my TODO list :)
[01:59] <handsome_feng> tsimonq2: Thank you very much! Y(^_^)Y
[02:12] <tsimonq2> handsome_feng: uploaded :)
[04:45] <handsome_feng> tsimonq2: Thanks!
[15:26] <ch> hi
[15:27] <ch> xenial shipped with a bad version of pdns (in universe). i'd like to discuss options for improving that situation
[15:29] <rbasak> ch: are you aware of https://wiki.ubuntu.com/UbuntuBackports and https://wiki.ubuntu.com/StableReleaseUpdates?
[15:31] <ch> i did read these pages indeed
[15:31] <rbasak> OK.
[15:31] <ch> a backport doesn't make the bad version go away though
[15:31] <ch> (as far as i understand this)
[15:31] <rbasak> No, you'll need an SRU for that.
[15:31] <rbasak> (second link)
[15:31] <ch> and for an SRU, i'm not sure how big of a delta is going to be okay
[15:32] <rbasak> Ubuntu is generally quite willing to consider exceptions to things, but best to start with understanding the existing policies as an exception request will only happen if it can be explained why the policy is unsuitable.
[15:32] <rbasak> First: what's the actual problem. Can you expand on "bad"? Is there a bug on this problem?
[15:33] <ch> 1652392 and 1705766 explain a bit
[15:33] <rbasak> bug 1652392 bug 1705766
[15:34] <ch> xenial shipped with an alpha release which is really unsuitable to run on the public internet
[15:36] <rbasak> Did you see https://bugs.launchpad.net/ubuntu/+source/pdns/+bug/1652392/comments/2?
[15:36] <rbasak> (that was me)
[15:36] <ch> right
[15:37] <ch> well, i'll do that then, i guess
[15:38] <rbasak> Just check that all the changes meet the requirements please, to avoid wasted effort.
[15:38] <rbasak> If you find that something doesn't seem to meet the requirements, we can discuss it then.
[15:38] <rbasak> I appreciate your help on this, and want you to succeed at getting this landed.
[15:38] <rbasak> But we have to be careful to avoid regressing existing successful users.
[15:38] <rbasak> (who may not necessarily be hitting the problems you are due to varying use cases)
[15:40] <ch> so for that point, i'm the debian uploader, and somewhat closely related to upstream
[15:40] <ch> as such i don't -actually- run these packages
[15:40] <ch> i only get the complaints
[15:40] <rbasak> OK. I hope you understand my sentiment though?
[15:41] <rbasak> debian uploader> be sure to mention that; that gives you some immediate credibility, and saves us having to be concerned about contacting the Debian maintainer should that be appropriate :)
[15:41] <ch> i do understand it, but i still insist that the shipped version is super low quality
[15:42] <rbasak> I'm not denying that it might be of super low quality.
[15:42] <rbasak> Nevertheless, if there are users happily using it, we care about not pulling out the rug from under their feet.
[15:42] <rbasak> If it is absolutely necessary, then we can consider doing that, but we don't take it lightly.
[15:42] <ch> judging from the people that come to the upstream irc channel or mailing lists, they are not happy ;-)
[15:43] <rbasak> Like you say, you only get to sample the unhappy users, and don't see the happy ones :)
[15:43] <ch> that is very true
[15:43] <ch> and i'd hate to leave people with a package installed that doesn't get updates or anything
[15:44] <rbasak> Define "updates". Security fixes and bugfixes are fine under the SRU policy.
[15:44] <rbasak> Feature updates and behaviour changes are not.
[15:44] <rbasak> In reality the two sets overlap sometimes, and we have to make a judgement call.
[15:46] <ch> Well, two things - 1) clearly, security updates, but then the version in xenial never saw any updates, even though there are a number of CVEs open. 2) For the version in xenial specifically, get a version of pdns into these users hands that's plainly broken for many important usecases or silently fails to serve correct data
[15:47] <rbasak> I don't think any of that contradicts anything I've said above.
[15:48] <rbasak> Updates do need to be volunteered. No volunteers = no updates.
[15:48] <ch> Yeah I do understand that. (Users apparently not so much...)
[15:49] <rbasak> Volunteered updates are usually expected to meet our policy requirements, but everything we've said sounds like it'll meet these requirements (but needs volunteers to find out)
[15:50] <ch> so, just inside debian:
[15:50] <ch> git diff --stat debian/4.0.0_alpha2-2..debian/4.0.0-1 -> 323 files changed, 11335 insertions(+), 8810 deletions(-)
[15:52] <rbasak> How many upstream commits does that correspond to?
[15:52] <rbasak> Is it just that some commit touched every other line?
[15:52] <rbasak> Also, Bionic will be out soon now.
[15:53] <rbasak> Is Bionic in a healthy shape/
[15:53] <rbasak> ?
[15:53] <ch> in upstreams git: git log auth-4.0.0-alpha2..auth-4.0.0 --oneline | grep -c 'Merge pull req' -> 378
[15:54] <ch> bionic looks good to me. how much time do i have to prod upstream into making a 4.1.1?
[15:54] <rbasak> Why had you uploaded an alpha release to unstable, BTW? Why not use experimental?
[15:55] <rbasak> https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule
[15:55] <rbasak> Feature freeze is March 1st.
[15:55] <rbasak> Automatic updates from Debian will stop on that date.
[15:56] <rbasak> You probably want to get an upload into Debian a few days before if you want to be sure of it getting autosynced.
[15:56] <ch> Upstream thought they were going to release soon and i wanted to get some testing (nobody uses pdns from experimental)
[15:56] <ch> Okay, thanks
[15:56] <rbasak> I'm not sure it's appropriate from a Debian perspective to put pre-release stuff into unstable.
[15:56] <rbasak> But I'm not sure Debian has a policy on that.
[15:57] <ch> Well, the Debian release wasn't going to happen for another year or so at that time
[15:57] <rbasak> Debian users use testing too.
[15:58] <rbasak> I always considered that as *packaging* testing, rather than a place for alpha upstream code.
[15:58] <rbasak> I could be wrong.
[15:58] <ch> Bit of both. And I also expected this to not take longer than a month or so
[16:00] <rbasak> "Some experimental software can still go into unstable, with a few warnings in the description, but that isn't recommended because packages from unstable are expected to propagate to testing and thus to stable."
[16:00]  * rbasak just looked that up to answer his own question.
[16:00] <ch> I'm not saying it was a great outcome...
[16:01] <rbasak> Sorry. I'm not aiming criticism at you. It's just that I've seen this happen before, so I was curious as to your reasons and Debian's policies, so I asked you and looked up the Debian docs. That's all.
[16:02] <rbasak> It's good that Bionic's in better shape. Thank you for that.
[16:02] <ch> No offense taken; it is a very valid critique
[16:03] <rbasak> And it sounds like we'll be quite happy to accept an update for Xenial, but it sounds like it'd be quite a bit of work to check that it won't regress any currently happy users :-/
[16:06] <ch> I can spend some time to prep an update and test that to some degree. Open question would be on what version that should be based - 4.0.0-2 from debian, or 4.0.3 from zesty or something newer
[16:07] <ch> the 4.0.0-2 is probably "better" but who knows which bugs are in there. zestys version probably has seen some users
[16:08] <rbasak> The only real requirement is that users upgrading up releases don't go down in version number.
[16:08] <rbasak> So it can't be higher than something in a subsequent release unless that subsequent release is also updated, which of course is more work.
[16:08] <rbasak> EOL'd releases can be ignored for the purposes of this requirement.
[16:09] <rbasak> Apart from that, like you say it's just a trade-off between likely bugs fixed and the amount of work to prepare the update.
[16:09] <rbasak> (and to review the update)
[16:09] <rbasak> We'll need to review the changes you're applying for compliance with Ubuntu's SRU policy
[16:10] <ch> Debian stretch shipped with 4.0.3, and I know of actual users of that. Having the same version would also have a tiny benefit for security updates...
[16:10] <rbasak> A broken down patchset, for example from upstream commits, would probably be the easiest for that.
[16:10] <rbasak> That makes sense.
[16:10] <rbasak> I think it's entirely appropriate for you to decide on where to fall on the trade-offs.
[16:12] <ch> Ok. Thanks for your time for now, and I'll see to a debdiff and some supporting info then.
[16:12] <rbasak> No problem, and thank you for your time in looking after this for Ubuntu
[16:13] <rbasak> ch: if I'm reviewing, I'd prefer to see a set of git commits rather than everything squashed into a debdiff please.
[16:14] <rbasak> ch: you can push that wherever you like. Ubuntu sponsors usually don't care as long as they can get ot it.
[16:14] <ch> rbasak, upstream commits or packaging commits?
[16:15] <ch> guessing the latter plus upstream split out somehow
[16:15] <rbasak> Yeah. Both basically.
[16:15] <rbasak> I want to review in small pieces, that's all.
[16:15] <ch> nod
[16:16] <rbasak> Such that each piece is tractable, and I'm confident that the final result is exactly the sum of the pieces.