On 19/12/16 22:47, Adrian Bunk wrote: > On Mon, Dec 19, 2016 at 10:15:33PM +0100, Daniel Pocock wrote: >> >> >> On 19/12/16 21:57, Adrian Bunk wrote: >>> On Thu, Dec 15, 2016 at 11:11:27AM +0100, Daniel Pocock wrote: >>>> >>>> Is there any easy way to contact everybody who made a bug report against >>>> a package and ask them to check if the latest upload fixes it? Or is >>>> there any script for maintainers to do this? >>> >>> I would expect the majority of your users observed the bug on an >>> (often production) system running jessie or older stable. >>> >>> It is not possible for such users to try random packages from unstable. >> >> Well, if it really deserves to graduate from unstable to the next stable >> release, somebody is going to have to test it sooner or later. >> Hopefully sooner. In my own environment I observed that NFS on jessie >> was less reliable than on wheezy. > > People running production systems with hundreds of thousands of users > are definitely not the ones who should test packages from unstable in > these environments. >
So who should test and how should they do it? Should Debian stop distributing packages like this if they don't get tested sufficiently? >>>> If somebody has opened 2 ore more bugs maybe they may prefer to only >>>> receive a single email summarizing all their bugs for that package. >>>> >>>> For example, nfs-utils has over 100 active bug reports and although I >>>> spent some time updating it I'm not keen to go through all the bugs one >>>> by one. >>>> ... >>> >>> Are you fully committed to spend time debugging every problem where >>> a user confirmed that it is still present? >> >> I don't think I ever promised that. > > If you are not willing to promise that, what is the point in asking > people to spend their time on reproducing? > Here is the message I sent: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793661#10 I didn't ask people to reproduce, I asked them to help review their bugs against the upstream changelog and "if you have time to test the new package, your help would be very welcome". If I asked "please confirm you can still reproduce the bug on the newest nfs-utils" then that would be a much stronger statement, but that is not what I asked. >> However, if users confirm problems >> that should really be release critical, then that gives the release team >> greater visibility about which packages are really ready going into the >> freeze. > > Talking about release critical bugs only distracts from the majority of > bugs that might be pretty fatal in some environments but are not release > critical. > If they are fatal for all NFS server environments (like the crashes with the jessie kernel) or they are fatal for a specific type of NFS configuration then they are release critical for this package. As already suggested, Debian would have to consider dropping any package in that situation if we knew about stability problems and nobody was volunteering to fix and volunteering to test it. >>> It might take a user hours (or even days) to verify whether a problem is >>> still present. >>> >>> It would be a very evil if a user would spend effort after such an >>> email, but the next he hears from the maintainer would be another >>> such request to try the then-latest version a year later. >> >> I hope the people who try things will engage with the community as a >> whole (including upstream) and not only rely on a single maintainer. > > Asking submitters to reproduce only makes sense if *you* intend to > further debug all problems confirmed to still be present in the latest > version. > > When *you* ask someone to spend effort to reproduce a problem, then that > person can expect that *you* will also spend some effort on that problem > afterwards. > > Never forget that due to your request to reproduce people might be > spending days on setting up an environment for testing whether the bug > you asked them to re-test is still present in the version you asked them > to test. > After the first round of feedback, I did another upload on the weekend. I believe each upload has provided an incremental improvement over the previous version in sid and in each case it has been shaped by the feedback through the BTS. Regards, Daniel
