Re: StableReleaseUpdates page (Was: Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates)
The wiki page in the paragraph regarding SRU testing might indeed not be entirely realistic, but it is the *recommended* way of going forward. With my SRU hat on, I personally would never reject someone's SRU verification just because the person performing it was the uploader. Sure, bonus points if the verification is done by the reporter or some unrelated person, but most of the time the uploader is the best we can get - as you already mentioned. I wouldn't rephrase the sentence though, as ideally we would want it to be done by someone else. But as I always understood it, it is not a strict requirement. What matters to me is that someone took the time to take the actual -proposed package, installed it and ran through the test case. If I see that's the case via the bug verification comment (and have no doubts whether the verification was actually performed) and the reporter doesn't seem to be 'involved', it's all good. Sometimes I do request verification to be done by the person that has reported the bug, but only if I see recent activity of that person on the bug. Doesn't happen very frequently though. Cheers, On Mon, 19 Aug 2019 at 22:06, Julian Andres Klode wrote: > > On Mon, Aug 19, 2019 at 09:34:07AM -0700, Bryan Quigley wrote: > > Nope, that's not the standard, expected procedure. It is always better to > > have someone else verify a fix, it's sometimes not feasible though. > > > > "While not ideal it is also possible for the uploader of the fix to perform > > the verification of the package in *-proposed" > > - https://wiki.ubuntu.com/StableReleaseUpdates#Verification > > > > OK, first of all - he SRUed that package in May. > > And re the The wiki page: It might say that, but it's _not_ realistic: > > - I've uploaded quite a few SRUs by now, and maybe a handful have been > (partially) > verified by someone else. Partially because these people only test their > favorite release (and then forget to do some tagging changes, or mention > version numbers), so you still have to do it anyway. > > In practice, people report bugs, and when you push a fix they are gone. > > Waiting days, weeks, or even months so that maybe hopefully someone else > might review it does not work. > > Other random things the wiki page says and people do wrong all the time: > > - Basically everyone sets their tasks to "In Progress" when working > on it, despite "In Progress" being reserved for "fix uploaded to queue". > > - People set "Fix committed" when/before an upload, despite it being > reserved for "fix in -proposed" > > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: StableReleaseUpdates page (Was: Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates)
On Mon, Aug 19, 2019 at 09:26:15PM +0100, Robie Basak wrote: > On Mon, Aug 19, 2019 at 10:05:15PM +0200, Julian Andres Klode wrote: > > - I've uploaded quite a few SRUs by now, and maybe a handful have been > > (partially) > > verified by someone else. Partially because these people only test their > > favorite release (and then forget to do some tagging changes, or mention > > version numbers), so you still have to do it anyway. > > > > In practice, people report bugs, and when you push a fix they are gone. > > If in doubt about testing commitment I usually try to ask reporters to > commit to doing appropriate testing (making it clear what we need) > before I drive an SRU "for" some particular set of users. > > I also don't feel guilty about letting an SRU slide because it isn't > getting verified. The way I see it: if no users care enough to test the > fix, then evidently nobody really needs the fix, so why should we risk > regressing unaffected users? > > This obviously doesn't apply to obviously serious bugs, special cases, > and so forth. > I mean, I don't really SRU other stuff I guess. Whether or not the bug reporter is still around is basically irrelevant as we independently agreed that the bug needs fixing. That's different from sponsoring an SRU, where I fully expect the sponsoree to step up to verify the fix if needed (which might often be the reporter). > > - Basically everyone sets their tasks to "In Progress" when working > > on it, despite "In Progress" being reserved for "fix uploaded to queue". > > The docs don't reserve that status, so I always considered "In Progress" > to be acceptable for both cases. Well, let's just say the wiki page tells you to change it to "In Progress" - if it was that already, it's not a change. That's how I read it. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: StableReleaseUpdates page (Was: Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates)
On Mon, Aug 19, 2019 at 10:05:15PM +0200, Julian Andres Klode wrote: > - I've uploaded quite a few SRUs by now, and maybe a handful have been > (partially) > verified by someone else. Partially because these people only test their > favorite release (and then forget to do some tagging changes, or mention > version numbers), so you still have to do it anyway. > > In practice, people report bugs, and when you push a fix they are gone. If in doubt about testing commitment I usually try to ask reporters to commit to doing appropriate testing (making it clear what we need) before I drive an SRU "for" some particular set of users. I also don't feel guilty about letting an SRU slide because it isn't getting verified. The way I see it: if no users care enough to test the fix, then evidently nobody really needs the fix, so why should we risk regressing unaffected users? This obviously doesn't apply to obviously serious bugs, special cases, and so forth. I wonder what others think? > - Basically everyone sets their tasks to "In Progress" when working > on it, despite "In Progress" being reserved for "fix uploaded to queue". The docs don't reserve that status, so I always considered "In Progress" to be acceptable for both cases. > - People set "Fix committed" when/before an upload, despite it being > reserved for "fix in -proposed" Again, the docs don't reserve that status just for that, although in this case I would agree it's wrong but for a different reason - before SRU review, we cannot know that the proposed fix, or any fix, really will land in the archive. The SRU team might reject the SRU itself for policy reasons, for example. I see this as equivalent to marking "Fix Committed" when a MP is proposed, before it is reviewed - which we don't do. Robie signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates
Nope, that's not the standard, expected procedure. It is always better to have someone else verify a fix, it's sometimes not feasible though. "While not ideal it is also possible for the uploader of the fix to perform the verification of the package in *-proposed" - https://wiki.ubuntu.com/StableReleaseUpdates#Verification On Mon, Aug 19, 2019 at 4:31 AM Julian Andres Klode < julian.kl...@canonical.com> wrote: > On Fri, Aug 16, 2019 at 01:07:18PM +0200, Andreas Ronnquist wrote: > > Forwarding to Ubuntu-devel, and posting as a reminder to the SciTE > > mailinglist. > > > > It would still be nice to have this in 18.04, but I cannot review my > > own work. > > Why not? Verifying your own SRU is the standard, expected procedure. > > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
StableReleaseUpdates page (Was: Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates)
On Mon, Aug 19, 2019 at 09:34:07AM -0700, Bryan Quigley wrote: > Nope, that's not the standard, expected procedure. It is always better to > have someone else verify a fix, it's sometimes not feasible though. > > "While not ideal it is also possible for the uploader of the fix to perform > the verification of the package in *-proposed" > - https://wiki.ubuntu.com/StableReleaseUpdates#Verification > OK, first of all - he SRUed that package in May. And re the The wiki page: It might say that, but it's _not_ realistic: - I've uploaded quite a few SRUs by now, and maybe a handful have been (partially) verified by someone else. Partially because these people only test their favorite release (and then forget to do some tagging changes, or mention version numbers), so you still have to do it anyway. In practice, people report bugs, and when you push a fix they are gone. Waiting days, weeks, or even months so that maybe hopefully someone else might review it does not work. Other random things the wiki page says and people do wrong all the time: - Basically everyone sets their tasks to "In Progress" when working on it, despite "In Progress" being reserved for "fix uploaded to queue". - People set "Fix committed" when/before an upload, despite it being reserved for "fix in -proposed" -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates
On Fri, Aug 16, 2019 at 01:07:18PM +0200, Andreas Ronnquist wrote: > Forwarding to Ubuntu-devel, and posting as a reminder to the SciTE > mailinglist. > > It would still be nice to have this in 18.04, but I cannot review my > own work. Why not? Verifying your own SRU is the standard, expected procedure. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
