On 15 Jan, 2016, at 15:04, Dmitry Smirnov <only...@debian.org> wrote:
> On Thu, 14 Jan 2016 07:01:52 AM Jakub Kruszona-Zawadzki wrote: >> We just want to add MooseFS to official Debian repositories. >> [..] >> For me both packages should be available in Debian repositories, > > Except for promoting MooseFS I do not see any benefits from introducing > MooseFS to Debian but there are numerous cons. Absolutely the same I can say about LizardFS. > > >> The only problem is that they didn't change name of >> binaries (which in my personal opinion is kind of stupid - moosefs = >> mfsmaster,mfschunkserver,mfsmount etc, LizardFS should be >> lfsmaster,lfschunkservder,lfsmount etc.). > > As far as I'm aware that was deliberate choice in order to allow seamless > upgrades from MooseFS. I think renaming is planned but it is a low priority > thing. Ok. Two years ago maybe it might sense, but now it is only confusing. You can't switch from MooseFS 2.0+ to LizardFS (and vice versa) because forks are not compatible any more, so why not to change binary names? > > >> They [LizardFS] actively develop their product, but much slower than >> original (my personal opinion, but we check their product regularly). > > Well thankfully it is not a race... Since MooseFS do not have public bug > tracker or VCS I supose you might be in unique position to compare speed of > development. However independent observer will hardly be able to reach the > same conclusion. You are right, but it doesn't matter. The think is that we have totally different goals. In MooseFS we want to have very sturdy, reliable product. This is why I don't want to publish unfinished code and this is why we don't want to have public code repository. I'm considering making public code mirror on GitHub or similar place, but with committed only published sources, not every change I made. Yes, we do not have public bug tracker. Now we use just sourceforge list. Nevertheless this is good idea to have public bug tracker. We will do it ASAP. I can understand necessity of having such. I've just recently found a bug in fuse and didn't know where to post it. The same might be with MooseFS. Do you know why people choose MooseFS? We have a lot of similar products. We have GlusterFS, Ceph, BeeGFS, XtreemeFS etc. All our clients claim that they have chosen MooseFS because of stability and reliability, not number of features. This is File System we are talking about, not some christmas toy. This is why I only accepted code from community that didn't have issues (at least obvious). LizardFS is full of such small issues. I know many scenarios in LizardFS which lead to data loss/corruption. Sometimes it is not good idea to accept everything to your code. We are very open to our community and we do everything to make our users happy (yes users - users who use GPL version and who don't pay us). For me all GPL users are as much important as PRO users. This is funny, but especially people from Debian should understand that in computer systems stability is more important than features. > > >> This is a fork, >> so they develop this product in different way and of course it also means >> that in some rare cases they product is even better than MooseFS. So I >> absolutely agree that for sure there are some people who will find >> LizardFS better than MooseFS and therefore both projects should be >> available in the package repositories. > > I disagree. For Debian there will be undesirable overhead from having two > similar software products. It would also cause needless confusion for our > users. When choosing between the two I give preference to LizardFS due to > greater potential and development transparency. At this time introducing > MooseFS to Debian is unnecessary but situation may change in the future. The think is that we have a lot of users (probably more than LizardFS - of course it's unprovable) and all of them should have right to choose. This is called democracy. MooseFS is available in almost all other OS'es in standard ports/packages. > > >> We know everything about LizardFS. Whole company is run by the guy who was >> fired from our company (he was not a developer, but our it administrator, >> so he knew MooseFS very well). He "stole" two developers from our company >> (they never were involved in moosefs developing, but they also knew this >> product). The whole story is not very nice, but leave it. This is their >> right to make fork of actively developed project. As you wrote - they have >> their own investor and therefore their own goal. I do not care about it. > > Thank you for interesting insights about projects history. There is more. And it's pity that you even help them. > > -- > Best wishes, > Dmitry Smirnov. > > --- > > It is a mistake to try to look too far ahead. The chain of destiny can only > be grasped one link at a time. > -- Winston Churchill -- Regards, Jakub Kruszona-Zawadzki - - - - - - - - - - - - - - - - Segmentation fault (core dumped) Phone: +48 602 212 039
