[Piuparts-devel] Bug#698526: Bug#698526: Sort known issues by reverse dependency count

[Dave Steele]

On Thu, Feb 21, 2013 at 5:02 AM, Andreas Beckmann <anbe at debian.org> wrote:
>
> +            if self.inc_re.search( logbody, re.MULTILINE ):
> +                for line in logbody.splitlines():
> +                    if self.inc_re.search( line ):
> +                        if self.exc_re == None \
> +                               or not self.exc_re.search(line):
> +                            return( True )
>
> That looks inefficient. Why do we have to grep twice to identify
> matching lines even if we have no exclusion pattern?
>

More than 99% of the tests will return "no failure". If the MULTILINE
search is 1% faster than the loop, this is a net win.

> Is it for 'foo.*bar' matching on
>   'The food shop\n....\nSetting up libbar (08-15) ...'
> ? Hmm, no, DOTALL is off by default.
>

The MULTILINE search is pure optimization - it can be remove with no
change to the results. DOTALL is off to match grep.

> Anyway, once you have a match, it shouldn't be too difficult to find the
> position and identify the matching line without needing to rematch on
> each line individually.
> Maybe even extend the pattern internally to
>
>     ^.*($PATTERN)
>
> to match at BeginOfLine, then add a search for '$' starting from the BoL
> to find the corresponding EoL ... and apply the exclusion pattern on the
> range found that way.
>
>

Maybe, but to get bang for the buck, focus on the 99%.Your idea to
'look for any problem' in the other thread looks like the right path
to try.

There simply aren't enough failure cases (even in 62 sections :-) ) to
worry too much about the rest.

>
> PS: for reviewing a series of patches I don't really care about the
> author's development history but prefer "rebased, rewritten and
> reordered history" to produce an easily readable patch series with small
> and self contained patches. (Hint: please fold 'Template HTML format
> fix' into the commit it fixes.)

There is a point to that commit. I wrote the python replacement to
produce identical output to the shell script, before adding fixes and
features (actually there are caveats, listed in the commit). You can
check out that version to verify. Fixing the HTML format and merging
the templates earlier interferes with that capability.

Of course rewriting is off limits once
> something has been merged into mainline. But I see no gain in merging a
> lot of "fixup" commits into mainline if the development branch could
> have been rewritten before the merge.
>

I wrote of another fixup branch, containing fixes to errors in the
well_known branch I had previously announced. I'm not sure if I should
have gone ahead and rolled the fixes into the announced branch or not.