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