* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > Stephen Frost wrote: > > > > > > > What would be really nice would be code coverage information for the > > > > back-branches also, as that would allow us to figure out what we're > > > > missing coverage for. I realize that we don't like adding new things to > > > > back-branches as those changes could impact packagers, but that might > > > > not impact them since that only runs when you run 'make coverage'. > > > > > > Hmm? 9.1 already has "make coverage", so there's nothing to backpatch. > > > Do you mean to backpatch that infrastructure even further back than > > > that? > > > > I wasn't sure how far back it went, but if it's only to 9.1, then yes, > > farther than that. Specifically, to as far back as we wish to provide > > support for pg_dump, assuming it's reasonable to do so. > > I said 9.1 because that's the oldest we support, but it was added in > 8.4. > > Do you really want to go back to applying patches back to 7.0? That's > brave.
Hrm. My thought had actually been "back to whatever we decide we want pg_dump to support." The discussion about that seems to be trending towards 8.0 rather than 7.0, but you bring up an interesting point about if we actually want to back-patch things that far. I guess my thinking is that if we decide that 8.0 is the answer then we should at least be open to back-patching things that allow us to test that we are actually still supporting 8.0 and maybe that even means having a buildfarm member or two which checks back that far. > > > Or perhaps you are saying that coverage.pg.org should report results for > > > each branch separately? We could do that ... > > > > This would certainly be nice to have, but the first is more important. > > coverage.pg.org is nice to tell people "hey, here's where you can look > > to find what we aren't covering", but when you're actually hacking on > > code, you really want a much faster turn-around > > True. We could actually update things in coverage.postgresql.org much > faster, actually. Right now it's twice a day, but if we enlarge the > machine I'm sure we can do better (yes, we can do that pretty easily). > Also, to make it faster, we could install ccache 3.10 in that machine, > although that would be against our regular pginfra policy. > > At some point I thought about providing reports for each day, so that we > can see how it has improved over time, but that may be too much :-) > > > and you'd like that pre-commit too. > > Yeah, that's a good point. This is the real issue, imv, with coverage.pg.org. I still like having it, and having stats kept over time which allow us to see how we're doing over time when it comes to our code coverage would be nice, but the coverage.pg.org site isn't as useful for active development. Thanks! Stephen
signature.asc
Description: Digital signature
