You are probably right.
My problem is just that I am far away from being a Perl wizard.
Perl is so vast that I still feel like a beginner. Even after years and a 5-digit sloc count, I constantly discover and learn new things.
For example, I am just beginning with Perl OOP.
Thus I do not feel sure whether I am competent enough already to become a cpan package maintainer.
But you and haukex convinced me to at least try it. I promise I'll do my best.
| [reply] |
I suggest you start small: pick one simple bug, fix it, and test, and then move on to the next. Testing really is important in this kind of situation, since you want to make sure you didn't break anything elsewhere in the code. Unfortunately, Curses::UI doesn't really have an extensive automated test suite (and AFAIK automated testing of Curses apps is nontrivial anyway), but does have fairly extensive example code, that's better than nothing. I'd strongly recommend you always add some kind of test - even if it's only a manual one - for whatever bug you are fixing. Often this will happen naturally anyway, since you'll need to reproduce the bug in the first place; the trick is to integrate that into the distribution - into the automated tests if possible, but at the very least in a file like maybe examples/rt12345.pl (including a short description of the buggy and fixed behavior as POD in that file).
Good luck, and thank you for taking this on! :-) And always feel free to ask here if you have questions.
| [reply]
[d/l] |
Thank you for the detailed instructions. I have thought about that a lot.
Most of the bugs are of very trivial nature. For example, if an object offers the possibility to set colors, and in the according function you see that instead of the variable a constant is being set, then it's quite obvious. Making a test stub for every one of those trivial cases seems excessive to me. I have not the time for that.
The background of the whole thing is that I needed an user interface for easy interactive configuration of a side project, which I need for my main project.
And I was naive and didn't look at the maintenance status of Curses::UI before I decided to use it.
So I was locked in, sort of, when I noticed more and more bugs after I built the applications' UI dialogs and started to test the application. Thus the fixing of Curses::UI is a side project of a side project into which I cannot afford to invest much time.
To keep my release schedule, I decided to just shove the Curses::UI modules that I use together to a big pile and include that in my script. It's ugly, but nobody will care.
Probably the best thing I can afford to do is to put those modules onto Github. Who likes to, can test them using my open source project.
As I had to add several get/set property functions/methods that are common in GUIs, in particular to modify existing objects after creation, it's no pure bugfix anyway.
Nevertheless, I'll contact the author. If he thinks the fixes are good, he can grant me co-maintainership to put them in himself. Otherwise I will just make an bug report hinting interested users to my github package, as I for time reasons cannot meet the requirement of writing 50 stubs with POD documentation.
Anyway, I learnt one important thing from that. Next time I choose a cpan package, I will carefully examine its quality before I take it into consideration.
For example, I lost quite a lot of time trying to use the CGI packages, only to find out they are inefficient and technologically outdated.
But nonetheless so many people use it anyway. People who ask for better alternatives are being told: use package CGI, basta!
So I had to write my own CGI routines to get good response times, be able to support secure cookies, etc, etc, etc
| [reply] |
| [reply] |
