| |
| |
On 10/21/21 11:15 AM, Rob McDonald
wrote:
On Wednesday, October 20,
2021 at 2:46:25 AM UTC-7 Ian MacArthur wrote:
On Saturday, 16 October
2021 at 09:34:41 UTC+1 rempasch wrote:
I'm just wondering if
there is a specific plan for what needs to been done in
order to hit the release or if it will be done when the
developers decide that what has been implemented is
enough. Any ideas?
Not as such - we don't have sufficient capacity to make
that plan.
I think it is very much in the realm of "when it's
done, it's done" I'm afraid.
I've lurked around the fringes of FLTK development long
enough to understand the realities of the process. Apologies
if my observations offend anyone. I am most grateful to the
developers for all their work producing FLTK.
Yes, most of what you say is true; some items I thought I'd
comment about:
FLTK does not have a central driving authority mandating
features or setting schedules.
Actually Albrecht is our software manager.
For just over a decade it used to be Mike Sweet, who got busy
working at Apple
on CUPS and had to disconnect from FLTK back in 2013 or so where
I took over the
website management, and around that time Albrecht became the
manager.
There is no established standard of what it takes for a
new release.
There is a release process:
https://www.fltk.org/cmp.php#RELEASE
In the old CMP,
the requirement was to absolutely solve all High and Critical bugs
before release. All moderate/low/RFEs that can't be solved by
release would be bumped
to the next release for resolution.
Now that we've switched to github, I think we have yet to iron
out the criteria for releases,
perhaps keeping the old CRITICAL/HIGH/MED/LOW/RFE labels and
classifying all open issues
accordingly, pre-release.
I believe Albrecht has some ideas on this, not sure if they've
been documented as yet,
but we definitely need to document the new release process for
github issues before
we can even begin the release steps.
I think mostly attention has been on solving key 1.4 issues and
stabilizing.
We also haven't had a minor release bump in a very long time
(1.1 -> 1.3 was the last one I think,
which was a long time ago) , and there's a lot in development
right now, esp to keep up with Apple's
recent changes that Manolo's been busy with, and with the switch
to cmake, so we've kept extending
1.4 release to wait for things to settle.
In Linus's tradition, "release early, release often", FLTK has
taken the opposite approach.
In truth releasing often takes a lot of effort, and while Linux
has a lot of devs, we do not,
and we've all been spread thin I think by recent events, and the
switch to git/github.
The STR System provides some level of
bug tracking and TODO list management that comes into play
when a release nears. Between releases, it mostly acts as an
accumulator.
And we've since moved to github issues for managing bugs.
The STR's are there as a history, and to finish still-open
issues/bugs/RFEs.
There's currently 112 STRs against 1.3 (0 critical, 0 high,
25 moderate, 26 low, 61 RFE's)
There's currently 189 STRs against 1.4 (0 critical, 17 high,
22 moderate, 29 low, 121 RFE's)
In github there's 60 open issues, I don't think we have a rating
system for those, so much as
subject tags ("cmake", "bug", "documenation", etc) which have to
be applied manually by devs
currently. And usually once labels are assigned, the issue usually
starts moving quickly to being
solved and closed.
Eventually, one of the developers gets motivated to produce
a release, starts making noise, gets a few other developers on
board.
Heh, that'd usually be Matt, who has since become busy with his
family business and so not as much available.
It's true one of us needs to take up the task stick and start
wielding it. It was easier I think too when there were
more devs.
Someone triages the STR's into a release list and a few
devs work to whittle down the list. Some concentrated effort
follows and a release is eventually produced.
Typically the open bugs get accumulated then get assigned to
devs to focus on
solving them.
Unassigned issues are forced to be assigned to 'someone', or get
bumped to the
next release.
Since there is no rigorous standard for
what it takes to justify a new release, I would
encourage the FLTK developers to pursue smaller and more
frequent releases.
They don't have to be a huge deal if we don't make them a huge
deal.
Oh, but they are a big deal.. keeping the docs synced with the
changes is
pretty big, and this time there's been many.
Changing svn -> git, configure -> cmake, combined with the
broach changes
under the hood from Apple, Linux (X11 -> Wayland), and
Windows, it's been
a bit tough to keep up.
We need to clean up all those README files; consolidate and
remove,
probably rewrite many of them.
In that spirit, I would encourage the team to consider
moving to time-based releases -- say once per year, or perhaps
every six months.
That'd be good for the maintenance releases, no question.
We're in a tough position having to freeze 1.3 (which keeps
getting unfrozen, lol) to
prevent fork issues, focusing on 1.4, but due to the above
mentioned issues, it's
been tough to get 1.4.0 out in what we'd prefer to be a reliable
state. But we should
probably push on it harder.
Of course, these are the words of a spectator who is not in
a position to dictate anything.
They're good ideas, just been hard to manifest due to "too much
to do/spread too thin"
I think.
I'm sure Albrecht will weigh in too. He's been busy I know on
lots of bugs/issues.
I've been using 1.4 myself in production, keeping up with the
current state of development
to carefully pick and choose the commits that make sense, and
internally freeze, applying
only fixes to my internal production release, and releasing
static binaries, so as not to require
shared .so's from linux distros to run binaries.
I advise other developers of active FLTK apps to do the same.
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/23e1fc20-e787-8b06-3b4c-7c25499be2c1%40seriss.com.
[ Direct Link to Message ] | |
|
| |
