It seems like I have hit a nerve and for that I apologize. Let me say
that I was not criticizing the work that anyone has done or is doing to
keep this project going. My main problem is that there are only two or
three people actively working on doing so and that puts a huge burden on
each of them. Rather than ask those few people to do more, we need more
people to do something/anything to help. I wish I knew how to make that
happen but I don't.
Now to address the specific items raised in response to my post.
1) No one is suggesting that we wait another nine years to do a
release! Perhaps we need to examine our "release model" - how often we
do one and why - in light of our limited number of volunteers. With a
larger group of active developers, it is possible to do "major"
releases, i.e. lots of enhancements and bug fixes. If the active group
is very small, perhaps more frequent but limited incremental releases
would work better. We should discuss this.
2) The answer to the question of how many bug reports are serious is -
nobody knows! That is because no one has the responsibility to "manage"
the release. Doing things by committee is fine for some things but
others require a more structured approach and I feel that "managing" a
release is one of them. That person would make sure that the
"paperwork" was done, the documentation was updated, etc. In other
words, tying up all the loose ends of getting a quality product out the
door. This should not be just another task that an already overburdened
developer get saddled with.
3) If we want our (RexxLA) reputation to be like Microsoft's as far as
quality of our products, then fine, ship "buggy" software. Being a long
time user (Windows) doesn't mean I endorse their approach. Just look at
the mess they now have with Windows 10/11. A bit of longer term
planning might have avoided that. For me, the quality should always take
priority but again, we are "overdue" for a release because of limited
resources and overall lack of project management so we find ourselves
"scrambling" instead of developing and executing a plan that would get a
high quality, not perfect, product out the door.
4) Asking me to do more is a bit offensive. No one knows what my
situation is and whether or not I have the ability to contribute any
more than I have already. Everyone must make their own determination on
what level of participation they are willing to undertake. And why is
it always the same people that are "expected" to step up when something
needs to be done? How about some new people getting involved? BTW, I
did close some of the "leftover" items as part of the latest cleanup a
few months ago. And, because I am tired of beating that dead horse, I
will go through my list of those items and simply close all of the
remaining ones. Should there be unfinished work items, someone else can
open new bug reports/RFEs and address them in a future release.
Thanks for reading this far and, perhaps we can continue this discussion
next week in Vienna over a beer!
Gil
On 4/25/2025 5:24 AM, Rony G. Flatscher wrote:
On 24.04.2025 21:29, Gilbert Barmwater wrote:
I don't believe we have enough time to make this happen, however
"nice" it would be. A quick check of SF bugs shows 141 "open"
tickets! Now, assuming some of those could be "skipped", it still
will take a LOT of time to review them and decide what "really"
should be fixed before we release a 5.1.0 GA. FWIW
PS There are STILL "leftover" bugs and RFEs from 5.0.0 that
apparently no one wants to spend time on. (We did make some progress
on that list but more remains to be done.) To continue to "carry"
those items into another GA release would be extremely unprofessional
IMO.
About 30 years ago I was stunned when learning that Microsoft would
release Word with more than 10,000 known bugs (in their bug database)!
Of course Word was and has been a professional product. Microsoft (and
other companies that release professional software with known bugs) do
so when no known show-stopper bugs are open, but only minor ones (no
matter how many it seems).
Ad bugs and RFEs from 5.0.0: frankly, I do not see them as
show-stoppers, also despite being overworked I tried to tackle those
items where I thought my knowledge would be helpful (alleviating
others from getting acquainted).
However, I lacked to see you giving a helping hand here, so I assume
that these open items were not really important to you. Definitely
they are not show stoppers.
As this is a project of volunteers everyone is invited and free to
lend a helping hand, no matter how small or big the hand ist. Just
pointing out, putting a spin and than wait and see is not enough for
resolving those items. So please, Gil, if you can, lend us your
helping hand as your expertise is big, needless to say and as you
would be able to tackle most of those open bugs!
[Of course, it would be great if we would arrive at a release with no
open bugs at the time of release. This would be possible by addressing
those bugs after the release and creating micro releases. I really
would urge you to also lend your hand to get them ironed out. FWIW in
"my" BSF4ooRexx850 project there are no open, known bugs. If bugs get
reported I try to address them as quickly as possible, knowing that
the expertise needed e.g. in JNI would not be something many Rexx
developers may have such that a fix would take a long time. The
situation with ooRexx is very different, we have quite a few
knowledgeable developers who can tackle and resolve the open bugs and
RFEs.]
So looking around the software world, releasing a product with open
bugs that are not show-stoppers *is* professional, like it or not! :)
Therefore, after the release we should try to tackle the open bugs and
create micro releases, exploiting that number in our version number
(cf. .RexxInfo~release).
[Also, I would be *very* interested to analyze Executor with regards
of its experimental features added to ooRexx and try to get most of
them, if not all, into ooRexx, notably the nifty Unicode support!]
Please realize also, that the quite comprehensive unit tests pass for
5.1.0 making it of release quality, i.e. a professional release that
improves older ooRexx release versions! As there are no show-stopper
bugs, IMHO there is no reason not to release the current version,
making the International Rexx symposium the event to communicate and
report on it! Not releasing it hinders the ooRexx community to take
advantage of the new features coming with ooRexx, e.g. the new
TraceObject class enhancing tracing considerably!
---rony
On 4/24/2025 1:13 PM, Rony G. Flatscher wrote:
Suggesting to prepare a general availability version for ooRexx
5.1.0 with the aim to release it next week such that we have a new
release for this year's International Rexx symposium in Vienna. Any
thaughts, comments?
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
Gil Barmwater
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
