On (04/05/16 12:56), Alexander Bokovoy wrote:
>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 <lsleb...@redhat.com> writes:
>> > > 
>> > > > On (03/05/16 12:29), Robbie Harwood wrote:
>> > > > > David Kupka <dku...@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. :)
>
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.

LS

[1] https://copr.fedorainfracloud.org/groups/g/sssd/coprs/

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to