Re: [Freeipa-devel] Improving bug reporting

2016-05-05 Thread Lukas Slebodnik
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

-- 
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


Re: [Freeipa-devel] Improving bug reporting

2016-05-04 Thread Rob Crittenden

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.


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.


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.


rob

--
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


Re: [Freeipa-devel] Improving bug reporting

2016-05-04 Thread Lukas Slebodnik
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  writes:
>> > > 
>> > > > On (03/05/16 12:29), Robbie Harwood wrote:
>> > > > > David Kupka  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 

Re: [Freeipa-devel] Improving bug reporting

2016-05-04 Thread 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  writes:

> On (03/05/16 12:29), Robbie Harwood wrote:
> > David Kupka  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

--
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


Re: [Freeipa-devel] Improving bug reporting

2016-05-04 Thread Lukas Slebodnik
On (04/05/16 11:05), Alexander Bokovoy wrote:
>On Tue, 03 May 2016, Robbie Harwood wrote:
>> Lukas Slebodnik  writes:
>> 
>> > On (03/05/16 12:29), Robbie Harwood wrote:
>> > > David Kupka  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.

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.

ATM the easiest way is to test with fedora.

>There are people like Timo Aaltonen who work on the Debian/Ubuntu
>support but they cannot do everything on their own. JS code issue is
>unique to Debian so ideally someone would need to contribute fixes that
>are right from Debian point of view but nobody did it so far. You are
>welcome.
>
I contributed in past :-)
but into C related code.

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.

LS

-- 
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


Re: [Freeipa-devel] Improving bug reporting

2016-05-04 Thread Alexander Bokovoy

On Tue, 03 May 2016, Robbie Harwood wrote:

Lukas Slebodnik  writes:


On (03/05/16 12:29), Robbie Harwood wrote:

David Kupka  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.

There are people like Timo Aaltonen who work on the Debian/Ubuntu
support but they cannot do everything on their own. JS code issue is
unique to Debian so ideally someone would need to contribute fixes that
are right from Debian point of view but nobody did it so far. You are
welcome.

--
/ Alexander Bokovoy

--
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


Re: [Freeipa-devel] Improving bug reporting

2016-05-04 Thread Lukas Slebodnik
On (03/05/16 18:48), Robbie Harwood wrote:
>Lukas Slebodnik  writes:
>
>> On (03/05/16 12:29), Robbie Harwood wrote:
>>>David Kupka  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.)
>
4.1.4 is only in experimental.
and sid(ustable) has only 4.0.5

Neither of these versions has long term support from upstream point of view.
And try to look into patches
http://anonscm.debian.org/cgit/pkg-freeipa/freeipa.git/tree/debian/patches

>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.
>
If freeipa get to the state that there will not be any non-upstream
patches in distibutions then we will not consider Fedora as upstream.
It might easily happen that non-upstream patch caused a bug.

BTW sssd is already in such state. Therefore we needn't care
about distribution; we just need to know the version of sssd.

Fell free to send patches if you want to have debian as 1st class citizen for
freeipa-server.

LS

-- 
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


Re: [Freeipa-devel] Improving bug reporting

2016-05-03 Thread Robbie Harwood
Lukas Slebodnik  writes:

> On (03/05/16 12:29), Robbie Harwood wrote:
>>David Kupka  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.

Ultimately, it's not a huge issue.  Users who are able to build from
source very likely also know their package manager and how to translate
the invocations.  And if they're not building from source, then the bug
should go downstream first regardless.


signature.asc
Description: PGP signature
-- 
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

Re: [Freeipa-devel] Improving bug reporting

2016-05-03 Thread Lukas Slebodnik
On (03/05/16 12:29), Robbie Harwood wrote:
>David Kupka  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 
>> certmonger
>> }}}
>> On client:
>> {{{
>> $ rpm -q freeipa-client krb5-workstation certmonger
>> }}}
>
>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.  So, in the interest of completeness, I believe the corresponding
>invocations are:
>
>> $ dpkg-query -W freeipa-server pki-base 389-ds-base bind9 samba \
>> krb5-kdc krb5-admin-server krb5-kpropd
>
>Note the split on the krb5 packaging; depending on what piece(s) you're
>checking for in the RPM krb5-server, this list is probably reducible.
>
>> $ dpkg-query -W freeipa-client krb5-user certmonger
>
>To give an example of what output of these looks like, here's a run of
>the server command on a machine that's missing some packages:
>
>> rharwood@thriss:~$ dpkg-query -W freeipa-server pki-base 389-ds-base \
>> bind9 samba krb5-kdc krb5-admin-server krb5-kpropd
>> bind9
>> krb5-admin-server   1.13.2+dfsg-5
>> krb5-kdc1.13.2+dfsg-5
>> samba   2:4.3.8+dfsg-1
>> dpkg-query: no packages found matching freeipa-server
>> dpkg-query: no packages found matching pki-base
>> dpkg-query: no packages found matching 389-ds-base
>> dpkg-query: no packages found matching krb5-kpropd
>> rharwood@thriss:~$ 
>
>i.e., it has bind9, krb5-admin-server, krb5-kdc, and samba, but is
>missing the rest of the requested packages.
>

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).

LS

-- 
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


Re: [Freeipa-devel] Improving bug reporting

2016-05-03 Thread Petr Vobornik
On 05/03/2016 01:45 PM, David Kupka wrote:
> Hello everyone!
> 
> I often miss proper reproducer and other important info in trac tickets.
> Asking for the missing info or guessing and trying is as ineffective as
> it sounds and costs us a lot of time and effort. I believe we can
> improve that.
> 
> We have guidelines for reporting a bug [1] but it obviously isn't
> enough. I propose to prefill track ticket's description with following
> (or similar) template and be strict on refusing (i.e. closing as
> invalid) tickets that are incomplete.
> 
> Any thoughts, suggestions, agreement or disagreement?
> 
> [1] http://www.freeipa.org/page/Troubleshooting#Reporting_bugs
> 
> --8<- trac-ticket-template-proposal --->8--
> Related SW versions:
> On server:
> {{{
> $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server
> certmonger
> }}}
> On client:
> {{{
> $ rpm -q freeipa-client krb5-workstation certmonger
> }}}
> 
> Reproducible:
> How often the issue occurs or what special condition is required to be met.
> 
> Examples:
> Always / Happened X times of Y tries / Only at noon 29th February when
> it's also Thursday / Only on Raspberry Pi
> 
> Steps to reproduce:
> Precise description of all related steps you have done. List of commands
> to run is the best form.
> 
> Example:
> {{{
> # ipa-server-install -a Secret123 -p Secret123 -r EXAMPLE.TEST -U
> # echo Secret123 | kinit admin
> }}}
> 
> 
> Actual result:
> Description of behavior you have observed (error, unexpected warning, ...).
> 
> Example:
> {{{
> kinit: Client 'ad...@example.test' not found in Kerberos database while
> getting initial credentials
> }}}
> 
> Expected result:
> Description of behavior you have expected.
> 
> Example:
> TGT for admin user is acquired.
> --8<--->8--
> 

+1

I would also consider section "Impact". Sometimes it is not clear if the
reported just saw a error message but it works otherwise or something
doesn't not work at all. Or that an issue blocks half of integration
test suite.

-- 
Petr Vobornik

-- 
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


Re: [Freeipa-devel] Improving bug reporting

2016-05-03 Thread Robbie Harwood
David Kupka  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 
> certmonger
> }}}
> On client:
> {{{
> $ rpm -q freeipa-client krb5-workstation certmonger
> }}}

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.  So, in the interest of completeness, I believe the corresponding
invocations are:

> $ dpkg-query -W freeipa-server pki-base 389-ds-base bind9 samba \
> krb5-kdc krb5-admin-server krb5-kpropd

Note the split on the krb5 packaging; depending on what piece(s) you're
checking for in the RPM krb5-server, this list is probably reducible.

> $ dpkg-query -W freeipa-client krb5-user certmonger

To give an example of what output of these looks like, here's a run of
the server command on a machine that's missing some packages:

> rharwood@thriss:~$ dpkg-query -W freeipa-server pki-base 389-ds-base \
> bind9 samba krb5-kdc krb5-admin-server krb5-kpropd
> bind9
> krb5-admin-server   1.13.2+dfsg-5
> krb5-kdc1.13.2+dfsg-5
> samba   2:4.3.8+dfsg-1
> dpkg-query: no packages found matching freeipa-server
> dpkg-query: no packages found matching pki-base
> dpkg-query: no packages found matching 389-ds-base
> dpkg-query: no packages found matching krb5-kpropd
> rharwood@thriss:~$ 

i.e., it has bind9, krb5-admin-server, krb5-kdc, and samba, but is
missing the rest of the requested packages.

Thanks,
--Robbie


signature.asc
Description: PGP signature
-- 
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

Re: [Freeipa-devel] Improving bug reporting

2016-05-03 Thread Abhijeet Kasurde



On 05/03/2016 07:05 PM, Jakub Hrozek wrote:

On Tue, May 03, 2016 at 01:45:39PM +0200, David Kupka wrote:

Hello everyone!

I often miss proper reproducer and other important info in trac tickets.
Asking for the missing info or guessing and trying is as ineffective as it
sounds and costs us a lot of time and effort. I believe we can improve that.

We have guidelines for reporting a bug [1] but it obviously isn't enough. I
propose to prefill track ticket's description with following (or similar)
template and be strict on refusing (i.e. closing as invalid) tickets that
are incomplete.

Any thoughts, suggestions, agreement or disagreement?

I'll just throw the sssd page we have on the subject:
 https://fedorahosted.org/sssd/wiki/Reporting_sssd_bugs

I would at least add the note about security-sensitive bugs to the
freeipa page, we really don't want CVEs being reported to trac :-)

Is there any automated script which can do this for us, something like 
sosreport ?
If not then it would be good idea to invest time and efforts to have one 
script to gather all logs and reports.


Thanks,
Abhijeet Kasurde

--
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


Re: [Freeipa-devel] Improving bug reporting

2016-05-03 Thread Jakub Hrozek
On Tue, May 03, 2016 at 01:45:39PM +0200, David Kupka wrote:
> Hello everyone!
> 
> I often miss proper reproducer and other important info in trac tickets.
> Asking for the missing info or guessing and trying is as ineffective as it
> sounds and costs us a lot of time and effort. I believe we can improve that.
> 
> We have guidelines for reporting a bug [1] but it obviously isn't enough. I
> propose to prefill track ticket's description with following (or similar)
> template and be strict on refusing (i.e. closing as invalid) tickets that
> are incomplete.
> 
> Any thoughts, suggestions, agreement or disagreement?

I'll just throw the sssd page we have on the subject:
https://fedorahosted.org/sssd/wiki/Reporting_sssd_bugs

I would at least add the note about security-sensitive bugs to the
freeipa page, we really don't want CVEs being reported to trac :-)

-- 
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


Re: [Freeipa-devel] Improving bug reporting

2016-05-03 Thread Martin Basti



On 03.05.2016 13:45, David Kupka wrote:

Hello everyone!

I often miss proper reproducer and other important info in trac 
tickets. Asking for the missing info or guessing and trying is as 
ineffective as it sounds and costs us a lot of time and effort. I 
believe we can improve that.


We have guidelines for reporting a bug [1] but it obviously isn't 
enough. I propose to prefill track ticket's description with following 
(or similar) template and be strict on refusing (i.e. closing as 
invalid) tickets that are incomplete.


Any thoughts, suggestions, agreement or disagreement?

[1] http://www.freeipa.org/page/Troubleshooting#Reporting_bugs

--8<- trac-ticket-template-proposal --->8--
Related SW versions:
On server:
{{{
$ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server 
certmonger

}}}
On client:
{{{
$ rpm -q freeipa-client krb5-workstation certmonger
}}}

Reproducible:
How often the issue occurs or what special condition is required to be 
met.


Examples:
Always / Happened X times of Y tries / Only at noon 29th February when 
it's also Thursday / Only on Raspberry Pi


Steps to reproduce:
Precise description of all related steps you have done. List of 
commands to run is the best form.


Example:
{{{
# ipa-server-install -a Secret123 -p Secret123 -r EXAMPLE.TEST -U
# echo Secret123 | kinit admin
}}}


Actual result:
Description of behavior you have observed (error, unexpected warning, 
...).


Example:
{{{
kinit: Client 'ad...@example.test' not found in Kerberos database 
while getting initial credentials

}}}

Expected result:
Description of behavior you have expected.

Example:
TGT for admin user is acquired.
--8<--->8--


+1

I suggest to mention also attach logs, for inspiration we may look at 
bind-dyndb-ldap trac.


Martin^2

--
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