Le 23/04/2018 à 23:09, Mark Blackman a écrit :
On 23 Apr 2018, at 19:17, Christophe Jaillet <christophe.jail...@wanadoo.fr>
wrote:
Le 23/04/2018 à 16:00, Jim Jagielski a écrit :
It seems that, IMO, if there was not so much concern about "regressions" in
releases, this whole revisit-versioning debate would not have come up. This implies, to
me at least, that the root cause (as I've said before) appears to be one related to QA
and testing more than anything. Unless we address this, then nothing else really matters.
We have a test framework. The questions are:
1. Are we using it?
2. Are we using it sufficiently well?
3. If not, what can we do to improve that?
4. Can we supplement/replace it w/ other frameworks?
It does seem to me that each time we patch something, there should be a test
added or extended which covers that bug. We have gotten lax in that. Same for
features. And the more substantial the change (ie, the more core code it
touches, or the more it refactors something), the more we should envision what
tests can be in place which ensure nothing breaks.
In other words: nothing backported unless it also involves some changes to the
Perl test framework or some pretty convincing reasons why it's not required.
Hi,
+1000 on my side for more tests.
But, IMHO, the perl framework is complex to understand for most of us.
Do you believe the Perl element is contributing to the complexity? I’d say Perl
is perfect for this case in general, although I would have to look at it first
to confirm.
For my personal case, Yes, I consider that the Perl syntax itself is
complex and/or tricky. That is certainly because I've never worked that
much with it.
I think that this can limit the number of people who can increase our
test coverage.
I certainly believe adequate testing is a bigger and more important problem to
solve than versioning policies, although some versioning policies might make it
simpler to allow enough time for decent testing to happen. I personally have a
stronger incentive to help with testing, than I do with versioning policies.
- Mark