On Jun 04 13:21:16, martinw...@gmail.com wrote: > I am willing to step up as the new maintainer of SoX
First of all, thank you for offering to do the work. Personaly, I would wait a bit longer to see if the current mainteiners answer to https://marc.info/?l=sox-devel&m=171692594028490&w=2 but I can understand your impatience. > - make a new release of SoX, 14.4.3, > including fixes to all known bugs(*) > and spelling errors but no more Well, nothing stops you from posting fixes to those bugs, whether it's towards a new release here, or some other. (Yes, it is frustrating to see them go ignored here.) Fix the bugs first, then think about a release. > - after that, open the flood gates to new developments > and features towards a non-backwards-compatible release 15.0.0 This is opensource - the flood gates are open all the time. As for backwards (in)compatibility: in what sense? The API of libsox which apparently nobody uses? The syntax of the command line options? The set of supported formats? As for new features, I would much rather first get rid of a lot of the old "features", such as a homegrown strcasecmp() [exported in the API!], a homegrown getopt(3), a poor man's replacement of err(3) [around since 4.4BSD], etc. (Anyway, as long as we are talking the future: are there any specific new features you have in mind?) > If this cannot be done on sox.sf.net, That depends entirely on the current maintainers I guess. > I will make a hard fork, sox_ng, and > invite contributers to work on that instead. > I already have most of the pieces in place for this > and would just need to make it public. What do you mean? You already have most of the bugs fixed? Or do you mean you have forked the git repo? Everybody has. (No offence.) Show us the fixes. > On a personal note, I have only made one proper release of a open-source > project so far, at start of year, and it took me three months, so I can > understand the current maintainer(s) being shy of doing it. It is a lot of > boring work. That one took so long because I also had to learn autotools Fear not: https://github.com/janstary/sox/tree/build > and fix all user-visible bugs. I thought that's what you are offering here. > This one should be easier because "configure" is done, That's quite an assumption, if you mean the build system at https://github.com/janstary/sox/tree/build So far, I have received _two_ responses (off-list). That's hardly enough for something to be made a base of a new release. While here: please, everyone, keep testing the above; it is near completion (misses oss, ao an pulseaudio) and works fine on OpenBSD, FreeBSD, NetBSD, Debian and Solaris. > the roadmap for the first release is clear With due respect, I haven't even seen it. > and I can count on community help for the bugs. Eh, exactly the opposite: the communituy can count on the maintainer to help with the bugs. > That said, the fork would be on codebase.org which is > a much more modern platform than sourceforge I don't know codebase.org, but so is github, which everyone is using. I doubt people will be willing to switch platforms (to yet something else than GH; not that people want to stay on SF :-). Does codebase.org do mailing lists? SF does. > and it can coexist peacefully with sox proper > (installing sox_ng.h, libsox_ng.so, play_ng etc) so packagers, > if they decide to switch, can make symlinks from the old names > to the new and things should work as before. Eh, every packager will want to see a detailed "clear roadmap" to _that_. > Suggestions are welcome Show us what you have, obviously. > (*) There are 28 CVEs open against sox-14.4.2, > not the 18 that Debian has patches for. "All SoX bugs" means the 28 CVEs, all tickets on SF, and all the patches which downstream OS packagers are forced to use now. Jan _______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
