[Freeipa-devel] Improving bug reporting

[Alexander Bokovoy]

On Wed, 04 May 2016, Lukas Slebodnik wrote:
>On (04/05/16 11:05), Alexander Bokovoy wrote:
>>On Tue, 03 May 2016, Robbie Harwood wrote:
>>> Lukas Slebodnik <lslebodn at redhat.com> writes:
>>>
>>> > On (03/05/16 12:29), Robbie Harwood wrote:
>>> > > David Kupka <dkupka at redhat.com> writes:
>>> > >
>>> > > > --8<------------- trac-ticket-template-proposal ------------------->8--
>>> > > > Related SW versions:
>>> > > > On server:
>>> > > > {{{
>>> > > > $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server
>>> > >
>>> > > I think this is a good idea.  However, we are on Debian/family as
>>> > > well now, and I think we want to accept bugs that come from these
>>> > > users as well.
>>> >
>>> > FreeIPA is heavily patched on debian and has quite old version there
>>> > 4.0.5.
>>> >
>>> > The better would be recommend to reproduce with upstream version
>>> > (fedora/CentOS).
>>>
>>> (FreeIPA 4.1.4 is available on Debian, but your point still stands.)
>>>
>>> In summary: I don't like that upstream is conflated with fedora/CentOS.
>>> Of course I understand that this was done to ease development and not
>>> out of malice.  But longer term I would like Debian/Ubuntu FreeIPA to be
>>> less of an afterthought because I believe we can attract users to our
>>> product.  I believe this to be especially true with working
>>> freeipa-client on those distros, which we now have and I am very happy
>>> about.
>>I think you miss context here. There was huge amount of work done in
>>last couple months to get FreeIPA 4.3 running on Ubuntu and Debian. It
>>made to Ubuntu 16.04. It didn't make to Debian proper yet for a single
>>reason: FreeIPA tarball ships with a minified JS code for parts of the
>>web UI framework which is against some of Debian policies and therefore
>>FreeIPA is blocked from entering Debian.
>>
>I think you misses context here.
:) No, I'm not.

>The porpose of reporting bugs to upstream is to file bugs to upstream version.
>If the downstream version is patched with non-upstream patches
>then you need to find out wheter bug is in upstream or downstream
>caused by non-upstream patches. And it should be task of reporter
>to ensure that bug is in upstream.
It is business as usual -- people would file bug where they want, not
where you want them to file regardless how you propose them to deal with
it. So far, we have by far many more requests/bugs about Debian/Ubuntu
integration than Fedora on the mailing list exactly because
Debian/Ubuntu versions people tend to run with are known to contain
incomplete support. So for these it does not matter where they are
filed because downstreams aren't going to fix the bugs in, say, Ubuntu
12.04 or 14.04 apart from what Timo provides with existing PPAs.

Reporting proper information is good and I think our upstream page that
David proposed should have subsections per distro flavor (and links to
SSSD troubleshooting guides too) but don't put much hope in them, people
who were not able to find out existing PPAs or solutions on the list,
will not be searching for FreeIPA wiki page to know how to report bugs
either.

>As I mentioned in previous mail.
>If freeipa get to the state that debian has pure upstream version
>then we can recommend to report bugs + exact version with dpkg-query
>
>The purpose of David's mail was to simplify job for developers
>and developers life will not be easier if developer need to
>find out wheter bug is in upstream or it's caused by downstream patches.
It is easy: if it is a bug on Fedora/RHEL/CentOS -- it is bug for Fedora
and RHEL maintainers to review and decide to forward or fix, if needed.

If the bug on Debian/Ubuntu and reported there -- it is bug for
Debian/Ubuntu maintainers to decide to forward or fix, if needed.

If these two groups of people are overlapping with FreeIPA/SSSD
upstreams, there is no problem as they would know how to handle the
situation.

If bugs were filed FreeIPA/SSSD upstream and reported issues are at a
specific downstream, it would probably make sense to engage with the
downstream maintainers anyway -- I'd rather CC: someone and ask a
question than crack my head on whether this is an issue
upstream/downstream.

In other words, spread the work, if possible. :)

-- 
/ Alexander Bokovoy