On 1/17/20 11:11 AM, Swift Griggs wrote: > 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. :-) >
Yes - I should be more clear. While I'm fine with simply removing old 'crap' from the repo, I was referring to 'retiring' dtmail. For me that would mean it would stay in the code base, but there would be a README.RETIRED or some such file making it clear it's, well, retired. :) And we would just no longer build it. If the autotools branch gets finished we could even add a --with-dtmail option for those that actually want to build it. Someone in the far distant future could come in and un-retire it if they chose. >> 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. > That could work too, or the 'retired' method I mentioned above. I just want some sort of resolution rather than continuing to ignore the issue. We'd probably have to fix the mail action and maybe create a new dtopen_mail helper that uses thunderbird by default... But this is doable. An argument could be made that we should never ship code we don't actually build, but I'd be happy with either way. >> A disservice is shipping non-functional and or exploitable software >> that no one wants to fix. > > That's hard to argue with. > -jon > -S > > > _______________________________________________ > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel -- Jon Trulson "Entropy. It isn't what it used to be." -- Sheldon
_______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
