[Freeipa-devel] Improving bug reporting

Lukas Slebodnik lslebodn at redhat.com
Thu May 5 07:56:29 UTC 2016


On (04/05/16 13:22), Rob Crittenden wrote:
>Lukas Slebodnik wrote:
>> On (04/05/16 12:56), Alexander Bokovoy wrote:
>> I'm sorry but it was a TL;DR mail without any useful information
>> to the topic.
>> 
>> The topic is "Improving bug reporting". I do not care much
>> how downstreams handle bug reports.
>> 
>> I like David proposal with template. But I do not like
>> proposal for debian; because there isn't an upstream version.
>> therefore I proposed to add recommendation to test with upstream version
>> of FreeIPA (fedora)
>> 
>> We should be very kind to users of other distributions but it happen
>> to me that my direct reports to upstream were closed because
>> fedora had patched version of packages. I did't like this way
>> but I understant why it was closed in upstream.
>> 
>> I did not propose to directly close tickets reported for non-upstream versions.
>> I proposed to add an recommendation to the template to test with upstream
>> version.
>> 
>> BTW We also suggest such way also in sssd. We have some users who had problems
>> with sssd due to buggy version of sssd in downstram (el7.1). We fixed many bugs
>> in upstream but they were not fixed in downstream. Therefore we started
>> to build upstream versions of sssd to older distributions[1].
>> We *SAVED* a lot of time due to this recommendation. This is a best practice
>> which we use also for reports from ubuntu 14.04. There is buggy version of
>> sssd-1.11.5.1 and it does not worth to spend a time with investigation unless
>> bug is confirmed with latest upstream version. Fortunately, Timo has latest
>> upstream version of sssd in ppa. If there wasn't a ppa I would prepare
>> it myself.
>
>I don't think sssd is something to measure against in this case. IPA has so
>many more moving parts it has taken quite a lot longer to get near the same
>point as sssd. Debian support has almost literally been a one-man operation.
>
This is yet another reason to test with upstream version of FreeIPA
(or with version which is more tested) before reporing a bug.

There are projects which test on more platforms(debian, centos, fedora)
in upstream (cockpit, sssd ...). It would be good if FreeIP get to this state
but we are not there yet. Therefore if we want to have a reasonable
bug report we shoudl recommend to test with better supported version.

sssd was just an example how it is helpful to test with
latest upstream version before reporting a bug.
The same applies to any project.

>IPA as a server didn't work in any real way until Timo got 4.3.1 built
>because without replication it's an interesting but non-production exercise.
>So IMHO any existing server builds on old platforms are not supportable. The
>same is probably true for the client packages which had all sorts of gotchas.
>
>Timo has done an terrific job getting his patches upstream, quite a few of
>which have been specifically to make IPA more distro agnostic.
>
>So honestly, I think a new line should be drawn using 4.3.1 as the starting
>point and provide just best-effort support for older releases. So workarounds
>only and probably no patches unless you can show it also affects the latest,
>and if Timo wants to backport then that's up to him.
>
FreeIPA 4.3 branch is not branch with long term support from upstrem point of
view. I would wait for 4.4.

>As for the template, part of the problem with the trac tickets is it is often
>developers filing bugs against things they see and I know I've filed a ton of
>awful, no details bugs thinking I'd get to it "real soon" and then not. A
>template might help at least remind what is necessary, but that is just as
>easily ignorable as the almost identical template in bugzilla.
>
>So I'd say it's up to the first round of triage to push back on poorly filed
>tickets. Maybe give Petr a ban hammer to close any incomplete tickets when
>they come in. I think devs would get the idea pretty quickly. He could be
>gentler with user-reported issues.
>
+1

LS




More information about the Freeipa-devel mailing list