> 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.

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

Reply via email to