[07:11] teward: https://lists.ubuntu.com/archives/ubuntu-devel/2019-January/040575.html didn't wrap so well. === Tm_K is now known as Tm_T [11:05] it's probably the case of "everyone is too busy with other things to help", since that also needs time.. which leads to being more busy since the same people tend to share multiple responsibilities they don't have time think about, but which are also too important to simply give out to someone else without careful planning [11:06] SRU team is really, really small and with nearly no dedicated time from any of the members, AFAIK. but SRUs are handled more since they're a must, backports is easier to ignore since it's rarely critical [11:07] anyway, hopefully there's progress with this one, backports process indeed has been quite broken [11:26] I don't think there's much overlap between the SRU and backports teams, is there? [11:27] But we've had a few (capable) new volunteers in recent years to join the backports team, so I think the process just needs sorting out. [11:27] I feel that with volunteers available the queue is inappropriately stuck because those currently in the team don't have time. We should free things up to allow the new volunteers to take over in that case. [11:41] The process drives the volunteers to not want to work on it. I say we fix that (as the mail is trying to do), and then it might be something that can actually be sustainable. Throwing more people at the current system isn't going to work. [11:41] (IMO) [11:44] Mirv: SRU members have no power over backports, so even if I wanted to review a package from the queue, I physically can't do that (at least last time I tried I couldn't) [11:55] Laney: I agree - I just mean that those who are volunteering now, and any existing team members who are available to be involved, can work on the process change. [11:56] * Laney nods [12:13] rbasak: I'm pretty sure I wouldn't want to be one of the reviewers, but if it were to be Debian style at all then I'd more than volunteer to keep a few packages updated (Debian style: New packages to backports are reviewed, uploaded by DDs/DMs/sponsors, then kept up to date and are the responsibility of whoever uploaded.) [12:41] rbasak: sil2100: you're correct, I just mentioned SRU is another team that has quite few members and the members have often had 10+ year membership [12:42] And noted the key difference. [15:11] JackFrost: wrapping is probably the side effect of me having to use a webclient to submit [15:11] unfortunately. [15:16] JackFrost: the tricky part is controlling that upload access without trampling toes. Part of the problem currently is who has upload access to backports - the proposal as-is would extend upload rights to those already with privileges, though any additional updates may need review from the Backports team to make sure nothing obscene is going on; that said, those with upload access for a package should already know enough to not break the [15:16] universe at large, so. [15:16] as Laney said, the system as-is is unsustainable, so redoing the process so it can be sustainable is the first step. [15:17] so with this proposal currently, and if approval was all around, then uploads access would be available for MOTU, PPU uploaders, and anyone else with that level of upload access to the repositories for {INSERT_PACKAGE_HERE} (sponsors included I believe) [15:19] Mirv: sil2100: correct me if I"m wrong but SRU members aren't just 'volunteers' right? [15:19] Most are Canonical employees. [15:19] From the Ubuntu project's perspective they are volunteers, just that Canonical is volunteering them. [15:19] right [15:20] rbasak: point being that to some extent they're being offered by Canonical (who employs and pays them) to do the SRU tasks [15:20] rather than the Backporters team which AFAICT is not a 'canonical driven' process [15:21] Right. I don't know about the early days but in all my time it's never been a thing that Canonical is interested in driving. It's permitted through Ubuntu's processes without Canonical having an interest. [15:21] *nods* [15:21] I think (but can't speak for Canonical) that the view generally is that it's too painful a process (not just the backports process but the deb packaging process) and it'd be better to enable upstreams to ship snaps. [15:22] Mirv: ^ the above discussion there being that while SRU team is small that's Canonical driven, so there's monetary backing. The current Backports process, even if it weren't broken, is all volunteers. [15:22] rbasak: I don't disagree, but I think that we can't completely get rid of Backports entirely. [15:22] namely because not everything is sanely snappable. [15:23] and in the case of things like, oh, Lubuntu, who absolutely refuses to ship snaps or snapd for any reason whatsoever, they don't want to touch snaps. [15:23] (you know who to yell at for that one, and if you don't i've already done that part repeatedly so... that's a dead horse discussion there) [15:25] as for Backports, there is some precedent for still providing them, in certain cases currently some packages *are* being backported with dev backing. I don't like that "anyone" can request a backport, but we can't let that process die currently where things that can be backported SHOULD be backported but are in and of themselves not snappable as of yet. [15:25] (there are cases) [15:25] (though I don't have all of them) [15:25] not to mention, those opposed to snaps will prefer backports (and whenever you start scanning the list of Ask Ubuntu questions as I do you start seeing people getting confused or mad at snaps for various reasons) [15:26] my two cents on that part. [15:26] (sorry if i'm not being coherent as much today, I'm still waking up - 3 cups of coffee and counting) [15:26] teward: I see no reason that the backports repository can't continue as it is. And process changes about how to land into that pocket don't seem like they'd be problematic either. [15:27] rbasak: indeed, that was my thought as well, and I think in part Laney's thoughts as well because having one or two people being the only ones with upload access is... well, to say the least a stressor where we can offload most of that upload power to those who already have access. [15:28] ... bleh, I broke an SSL cert on a production machine, back in a bit... *goes to fix the machine in the workplace* === grumble is now known as AMENDMENT_EFFFFF === AMENDMENT_EFFFFF is now known as grumble