I would like to add two more sections to the design page template

[Jakub Hrozek]

see subject, I would like to add:
    - how to debug:
        - summarize what to look for if the feature does not work. It's
          fine to say something like 'follow generic sssd debugging
          procedure' but we should think about debug messages and the
          debugging process when we design a new feature. Remember, this
          will save us time later :-)
    - dependencies:
        - list changes that are required in other packages for this
          feature to work. This would mostly be interesting for
          downstreams who would know that they need to upgrade the
          dependecy as well.

Is everyone OK with that?

[Pavel Březina]

On 02/16/2016 10:55 AM, Jakub Hrozek wrote:
>  see subject, I would like to add:
>       - how to debug:
>           - summarize what to look for if the feature does not work. It's
>             fine to say something like 'follow generic sssd debugging
>             procedure' but we should think about debug messages and the
>             debugging process when we design a new feature. Remember, this
>             will save us time later :-)
>       - dependencies:
>           - list changes that are required in other packages for this
>             feature to work. This would mostly be interesting for
>             downstreams who would know that they need to upgrade the
>             dependecy as well.
>
>  Is everyone OK with that? 
Why not... but is should not be part of pre-implementation design 
discussion but a change after the feature is complete, since you can't 
possibly answer this before most of the times. Especially the debug part.

[Jakub Hrozek]

On Tue, Feb 16, 2016 at 10:58:35AM +0100, Pavel Březina wrote:
>  On 02/16/2016 10:55 AM, Jakub Hrozek wrote:
>  >see subject, I would like to add:
>  >     - how to debug:
>  >         - summarize what to look for if the feature does not work. It's
>  >           fine to say something like 'follow generic sssd debugging
>  >           procedure' but we should think about debug messages and the
>  >           debugging process when we design a new feature. Remember, this
>  >           will save us time later :-)
>  >     - dependencies:
>  >         - list changes that are required in other packages for this
>  >           feature to work. This would mostly be interesting for
>  >           downstreams who would know that they need to upgrade the
>  >           dependecy as well.
>  >
>  >Is everyone OK with that?
>  
>  Why not... but is should not be part of pre-implementation design discussion
>  but a change after the feature is complete, since you can't possibly answer
>  this before most of the times. Especially the debug part. 
The dependencies /should/ be known beforehand. I agree about the how to
debug, maybe instead of a new section, we can just add a note to the
'how to test' part of the template (which I normally change also after
working on the feature)

[Lukas Slebodnik]

On (16/02/16 11:03), Jakub Hrozek wrote:
> On Tue, Feb 16, 2016 at 10:58:35AM +0100, Pavel Březina wrote:
> > On 02/16/2016 10:55 AM, Jakub Hrozek wrote:
> > >see subject, I would like to add:
> > >     - how to debug:
> > >         - summarize what to look for if the feature does not work. It's
> > >           fine to say something like 'follow generic sssd debugging
> > >           procedure' but we should think about debug messages and the
> > >           debugging process when we design a new feature. Remember, this
> > >           will save us time later :-)
> > >     - dependencies:
> > >         - list changes that are required in other packages for this
> > >           feature to work. This would mostly be interesting for
> > >           downstreams who would know that they need to upgrade the
> > >           dependecy as well.
> > >
> > >Is everyone OK with that?
> > 
> > Why not... but is should not be part of pre-implementation design discussion
> > but a change after the feature is complete, since you can't possibly answer
> > this before most of the times. Especially the debug part.
>
> The dependencies /should/ be known beforehand. I agree about the how to
> debug, maybe instead of a new section, we can just add a note to the
> 'how to test' part of the template (which I normally change also after
> working on the feature) 
Things change in desing in some cases.
So we should sync desing with real implementation
after pushing final patches to upstream and part of this update can be
to extend "how to debug section".

LShow to debug section