On Thu, 16 Jan 2020, Jon Trulson wrote:
I am not interested in maintaining a museum piece.
That is pragmatic an sensible, but could it be deprecated into a "classic"
or "hierloom" directory within the source tree and only allowed to emerge
when it'd be fixed by a loving and living maintainer. I'm just thinking
there is some work that's been done that there might be extensible more
than starting over (especially with a MOTIF app).
I'd like CDE to actually work and be useful. dtmail is broken and has
been for some time.
I agree with you. However, do you think that someone who might want to
pick up that bit later would be helped by being able to start with the
dtmail codebase. I'm not being trite, I'm really asking your opinion. :-)
Either someone takes up the cause or we remove it. You can always fork
CDE if you want to maintain a museum...
You, Chase, and others on this list are the #1 folks with enough interest
to fix stuff (look how well you guys handled that CVE as opposed to Oracle
etc..). I doubt even if someone like me *wanted* to fork it, they'd have
nearly the time or the expertise to maintain it. IMHO, open source CDE is
right were it needs to be, but hey, forking is all just an exercise in who
has the most energy, I guess.
I guess to play my own devils advocate, if someone decides to extend &
maintain dtmail they could check it out from the VCS to whatever the last
release still included dtmail and then pipe up on the list here saying
"Heya, folks, could I be the new dtmail maintainer? Would you take my
patches?" Then one could answer "sure give me a clean set of patches and
we'll do it." No harm, no foul, and in the meantime it keeps the VCS
structure a bit smaller and cleaner.
A disservice is shipping non-functional and or exploitable software that
no one wants to fix.
That's hard to argue with.
-S
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
