[scribus-dev] unit test
JLuc
jluc at no-log.org
Thu Jul 11 08:47:57 UTC 2013
'O Chelen,
Wellcome to you agile coding fingers !
If i understand your aim well, having unit tests is a way to review new code faster
so as to make merge easier.
The aim to make new code easier to merge is a really good one.
However, the lack of answer and support from core devs is not very encouraging,
and IMO the proposed unit test action is not a right strategy to reach the goal.
I shall detail this view in the following answer.
Do we agree that the limiting factor in merging new quality code are of 2 sorts :
1- core-dev code reviewing and merging time
2- new contributor's quality code availability
Unit test wont improve the 1st point.
As for the 2nd point, please consider thatI have been available these last 2 years
for testing proposed code, and i've been done it generaly with not much delay.
I think i do a testing job that is different but globaly as efficient
as good unit tests can be.
Beside it is a job that could be done by other : i'm sure a call on the list
would enable to find more compilers and code testers.
But after creating bug reports about contributors branch, it takes a quite long
time before the bugs are corrected (not days but weeks, months or years)
by the contributor.
So here again it seems the limiting factor is not the test :
limiting factor is the coding or code-debuging of the feature itself.
As a conclusion, i think your valuable and proved abilities to code
would be much better employed in working on the scribus core code itself.
As Craig pointed it : "there's other stuff that will help get 1.5.0 released faster
that needs doing".
As for what other stuff needs doing, this can be discussed.
IMO, the best involvment for your time would be in making all scribus 1.4 features
work flawlessly in 1.6. (BTW This could begin with scribus 1.2 features)
Providing efficient core-features would bring a really enjoyable experience
to the user.
Sincerly
JLuc
More information about the scribus-dev
mailing list