Hi Silvan,
Put it this way, even when you go down the RPM/YUM road it is not exactly like you have a sunny day every day...
Could you get a bit more precis about that? As we update ports relatively regularly. And tickets should not stay forever as long as we can reproduce them. I just looked (briefly) at tickets and didn't see any open ones from you. Nor any request.
Oh now now, you and I have exchanged some pretty heated words in the past on this subject, so I won't go there again. My move from self-managed DLL to RPM/YUM was a nightmare, in some cases caused by unforeseen issues (such as previous Python install), so in an already existing OS/2 deployment, some of which are results of years of updates and ugprades at best, it's not 'pretty'.
I have no doubt that the team is trying, but at best, you guys are pretty tight on resources and the reality is that what we have today is simply not enough. All this creates stress and when the 'stars' aren't aligned just right to debug the problem quickly it makes the existing issues into even bigger problems.
You still want examples? OK...take the PSI IM client appliation, I'll use an example of what I would classify as in one case crappy and on the other hand a pretty good response:
1) PSI v0.16-dev-20150213 - crashes when entering IM message (
http://trac.netlabs.org/qtapps/ticket/120)
Ticket opened Apr-8th, 1st response May-21st, potential fix identified May-24th...unfortunately given the time it took for anyone to work the ticket I had actually stopped usign the app since it was unusable.
2) PSI v.016-2018-07-16 produces a THEME error (
http://trac.netlabs.org/qtapps/ticket/123)
Ticket opened Jul-19th, 1st response Jul-23rd, potential fix/workaround confirmed Jul-26th...wow, fantastic and seriously speedy resolution!
Here is an example of an unresolved ticket altogether:
1) Lucide 1.40 GA - crashes with large PDF files (
http://trac.netlabs.org/lucide/ticket/355)
Ticket opened Apr-6th, 1st response Apr-9th, potential workaround only identified on Apr-17th and confirmed that the ticket will not be worked on due to lack of resources...and so it sits out there today despite the fact that it is probably the only native PDF viewer we have. So I go back to my GSView until I can one day (hopefully) run Lucide again.
...
If there is one thing that I wish would get addressed it is the seemingly steep slope to building a DEV environment...
With rpm in place a DEV env is relatively easy. We could tell/write all steps. Even on netlabs are already some written (small) articles about that. And of course if one puts $$$ in it we will help even faster. Using a rpm DEV env doesn't mean you need to build rpm enabled ports. It just helps you to install the DEV env.
...
You see, a statement like "...With rpm in place a DEV env is relatively easy..." is what may be part of the problem. The truth of the matter is that this is simply not true. I went down that path (please take a look at my threads in the Programming forum), could hardly get the native OS/2 stuff up and running, relied mostly on my previously installed VAC++ and EMX stuff instead. Only after many tedious hours and some forum feedback from the few who have actually ventured down this path, was I able to at least do basic GCC compiles. I am still stuck on a simple task of building a multi-threaded app (pthread) and certainly nowhere near being able to actually attempt a platform migration, let alone trying to help out in supporting various tickets.
So yes, you are absolutely right on the money regarding the documentation aspect. There simply seem to be too many pieces of this puzzle floating around, people like myself who tried to crack that nut, and anyone else who comes after them has seemingly no choice but to re-do all of that which hopefully results in a working install. On top of this, what may have worked some time ago no longer works today, the environment changes, part of that being due to the necessity driven course changes as we get nearer and neared to the Linux way of doing DEV. Sure, it makes sense, it's the only way for us to continue to have a viable way of sourcing new software, but my God, for someone knew to this 'game' it's like trying to shoot the arrow through that apple on someone's head while I'm on the back of the wagon that's rolling over some pretty bumpy roads...just ain't gonna happen!!!
I am going to venture a guess and say that this too often proves to be an insurmountable obstacle to growing the grass-roots DEV team.