Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates

Andreas Ronnquist-2
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.

Thanks in advance.

---------------------------------------
Start av vidarebefordrat meddelande:

Datum:Wed, 8 May 2019 00:57:18 +0200
Från:Andreas Ronnquist <[hidden email]>
Till: SciTE-interest <[hidden email]>
Ämne: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04
proposed updates


Hi!

If there's any Ubuntu users here:

I have provided an updated SciTE 4.0.0 in Ubuntu 18.04 proposed updates
to fix dynamic library loading [1] - in upstream sourceforge bugtracker
at [2]. If you are using the current Ubuntu 18.04 (LTS) and use
Ubuntu-packaged SciTE - please if you can, test out my fix so that it
can get into the Ubuntu release proper.

The bug isn't present in later versions of SciTE, but the version
of SciTE in Ubuntu 18.04 is one still affected.

Please see [3] for a link to instructions to enable proposed updates
and test the updated SciTE package with version 4.0.0-1ubuntu0.1 that
contains the fix, and report your testing to the launchpad bug report
[1], which will help to get it faster into Ubuntu 18.04.  

1: https://bugs.launchpad.net/ubuntu/+source/scite/+bug/1804865
2: https://sourceforge.net/p/scintilla/bugs/2058/
3:
https://bugs.launchpad.net/ubuntu/+source/scite/+bug/1804865/comments/9

-- Andreas Rönnquist
[hidden email]
[hidden email]

[Please don't CC me, if I mail to a mailinglist, I am subscribed to it.]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates

Julian Andres Klode
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
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates

Andreas Ronnquist-2
On Mon, 19 Aug 2019 13:31:06 +0200,
Julian Andres Klode<[hidden email]> 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.
>
>

Oh, I didn't realise that. Well then, I'll review my own changes.

-- Andreas Rönnquist
[hidden email]
[hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates

Bryan Quigley-2
In reply to this post by Julian Andres Klode
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"



On Mon, Aug 19, 2019 at 4:31 AM Julian Andres Klode <[hidden email]> 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
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

StableReleaseUpdates page (Was: Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates)

Julian Andres Klode
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
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: StableReleaseUpdates page (Was: Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates)

Robie Basak-4
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

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: StableReleaseUpdates page (Was: Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates)

Julian Andres Klode
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

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: StableReleaseUpdates page (Was: Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates)

Lukasz Zemczak
In reply to this post by Julian Andres Klode
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
<[hidden email]> 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
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel



--
Łukasz 'sil2100' Zemczak
 Foundations Team
 [hidden email]
 www.canonical.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel