On Tue, Apr 8, 2014 at 8:40 PM, Jurjen Bokma <email address hidden> wrote:
> Ok, I cloned the GitHub repository, forked, making changes.
> As for unit tests, it looks to me like an entire lens is the unit of
> testing, so I would edit lenses/tests/test_krb5.aug to include some
> previously unparsed in- and output. Is that what you want me to do?
>
>
It's quite common indeed to use the entire lens as the unit of testing.
Just add a new test case after the last one in
`lenses/tests/test_krb5.aug`. Make sure it fails before you patch, and then
add the patch.
> Also, it's not unlikely that I'll need more changes to this particular
> lens in the near future (weeks to months). Am I right assuming that
> - it's better to send multiple PRs than to accumulate, and
>
Indeed, unless they strongly depend on each other, in which case it might
make it hard to manage if there's a need to modify them before merging.
> - patches that can pass for a bugfix will get into Trusty even after it is
> released, whereas ones that seriously change the parse tree won't make it
> into Trusty even if I were to open the PR tomorrow?
>
Yes, that's right. Patches that are not backwards-compatible are less
likely be accepted as bugfix.
On Tue, Apr 8, 2014 at 8:40 PM, Jurjen Bokma <email address hidden> wrote:
> Ok, I cloned the GitHub repository, forked, making changes. tests/test_ krb5.aug to include some tests/test_ krb5.aug` . Make sure it fails before you patch, and then
> As for unit tests, it looks to me like an entire lens is the unit of
> testing, so I would edit lenses/
> previously unparsed in- and output. Is that what you want me to do?
>
>
It's quite common indeed to use the entire lens as the unit of testing.
Just add a new test case after the last one in
`lenses/
add the patch.
> Also, it's not unlikely that I'll need more changes to this particular
> lens in the near future (weeks to months). Am I right assuming that
> - it's better to send multiple PRs than to accumulate, and
>
Indeed, unless they strongly depend on each other, in which case it might
make it hard to manage if there's a need to modify them before merging.
> - patches that can pass for a bugfix will get into Trusty even after it is
> released, whereas ones that seriously change the parse tree won't make it
> into Trusty even if I were to open the PR tomorrow?
>
Yes, that's right. Patches that are not backwards- compatible are less
likely be accepted as bugfix.