Dnia 2014-02-26, o godz. 17:59:41 Antonio Diaz Diaz <[email protected]> napisał(a):
> Michał Górny wrote: > > It also makes it easier to contribute and reference the code > > (especially if it comes with a public viewer like gitweb). > > Only if you have the needed software installed and know how to use it. > Else it makes more difficult to contribute. I have experienced it myself. I wouldn't call contribution to lzip pretty friendly at the moment. First of all, you look for source code repository. Because it's a FLOSS project, so you expect that the development is open to public, and there's a repository where most recent changes are stored. You lose some time scanning the webpage, the savannah page and finally you get lost. Then, if you actually believe there's actually no source code repository, you have to find the newest version of source code. And you *hope* that the author hasn't made significant changes to the code in the mean time, so the patches you prepare will be good. If they aren't, you need to update them by hand. Proper version control makes this much easier. Of course, you have to know the tool. But being unable to use at least the few most common version control systems makes you practically unable to properly contribute to most of the modern FLOSS projects. Shortly saying, it is an important skill and VCS is an important improvement in FLOSS world. > > I was more wondering about the number of contributors. Unless I am > > missing something, you seem to be the only person that has ever > > contributed to lzip, and this makes me worry about the bus factor. > > Laszlo Ersek contributed the whole first version of plzip. And all the > (de)compression code of pdlzip is from Igor Pavlov. I don't understand why you mention Igor Pavlov here since he clearly is not a contributor to pdlzip. A contributor is a person who willingly and consciously contributes to the project, and in this you were the person using his project's code, not him consciously contributing to your project. > In fact the bus factor is more of a problem for xz than for lzip or > bzip2, because they both are much simpler than xz and therefore it is > easier for a new maintainer to understand them fully. I'm afraid you are missing an important point here. xz is incredibly more popular, and has seen more development and re-implementations than lzip has. This means that more people have actually looked into the source code and will be ready to quickly start working on it once that becomes necessary. Not to mention that many more people will find the development necessary. lzip, on the other hand, is pretty much a dead end in its current form. Considering that it uses the same algorithm as xz, it has pretty much the same limitations and can't ever have any significant advantages over it. Without these, it has no way of convincing people to switch to a less popular format and in fact gain any real popularity. I'm sorry to say that but I'm afraid that if you discontinued your work on lzip, the format would pretty quickly become extinct. The lzip program and related tools will either become abandoned and forgotten, or change direction and start supporting the more popular xz format. Then, it could actually become competitive in the xz compressor area as a better implementation of the LZMA2 algorithm. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
_______________________________________________ Lzip-bug mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lzip-bug
