Bug#810822: ITP: MooseFS Debian repository contains a fork of MooseFS
On 18 Jan, 2016, at 8:25, Dmitry Smirnov <onlyjob@debian.org> wrote:
> On Mon, 18 Jan 2016 06:53:05 AM Jakub Kruszona-Zawadzki wrote:
>> On 15 Jan, 2016, at 15:04, Dmitry Smirnov <onlyjob@debian.org> wrote:
>>> 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.
>
> Can you be more specific please?
>
To have "only" LizardFS in your repository you promote LizardFS and I don't know why?
>
>>> 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?
>
> That's right but it is not a big problem since one would hardly use MooseFS
> and LizardFS binaries together. There might be some secondary benefits as
> compatible utility names could be used by user scripts (that would have to be
> adjusted for rename). I agree, perhaps these days it would be nice to finish
> renaming but this is a minor thing... Let's not discuss that here any
> further... There should be corresponding LizardFS bug for this.
Ok.
>
>
>> The think is that we have totally
>> different goals. In MooseFS we want to have very sturdy, reliable product.
>
> This is unfair to suggest that LizardFS do not strive to have reliable
> product.
>
Maybe they want, but they do not have it. Number of issues in they github is huge (of course since we do not have public bug track we can't compare :) )
But we will change that. There will be official source tree of GPL'ed MooseFS in GitHub.
>
>> 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.
>
> LizardFS put all contributions - even minor commits through Gerrit code
> review. Their commits are conservative - not too frequent but certainly
> careful.
No comment.
>
> There is no harm to your users if your VCS is publicly accessible.
> Testers and external developers might find it useful and regular users should
> use stable releases.
I agree. As I mentioned we will change that. There will be official MooseFS source code on GitHub.
>
> There might be another reason: MySQL do not expose their VCS because they do
> not want to publish their proprietary code. I suspect MooseFS might have
> similar concerns.
We will not publish our proprietary code (as for now), but it doesn't mean that we will not publish GPL'ed MooseFS. As I wrote. GPL'ed version is almost full MooseFS. I even plan to publish master failover in GPL'ed version (not full HA as we have it in PRO, but failover as in LizardFS). I have to convince our investor, but I hope that it will be doable. I'm very pro free software and I think that there should be no "pro" version of MooseFS (my personal opinion), but life is sometimes brutal and unfair.
>
>
>> 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.
>
> Indeed bug tracker will be very useful even if you only use it internally.
> I recommend to consider Redmine which is used by Ceph, Opennebula and many
> others.
Yes. We use Redmine internally, but I agree that having public bug tracking is the best, because all users will have access to that.
>
>
>> 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.
>
> While features are also important my own experience confirms that Ceph is
> rubbish and XtreemFS and others are not far away.
This time I agree with you in 100% :)
> MooseFS is superiour to all
> those storage systems but its governance made it impossible for me to choose
> it. Hence I'm in favour of LizardFS.
I hope that it will change some day. Did you even try to test MooseFS 3.0? Compare to LizardFS?
If you need PRO licence to do some test then let me know - We will send it.
>
>
>> 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.
>
> It would be truly great if you could support your claims. You seems to
> suppose that LizardFS bugs were introduced by careless community
> contributions but I do not recall even single case where LizardFS bug was not
> originated either from old MooseFS code or from LizardFS's own development.
> Certainly community is not to be blamed for bugs in LizardFS.
Some bugs in LizardFS originated from old MooseFS (I know because I fixed them), some are their own. It's normal. MooseFS also have bugs (I hope only small ones - but you never know :) ).
Simple example of LizardFS wrongdoings. First change they made was to accept chunks with bigger version than version set in master. Chunk version mismatch was in this case for a reason. This can lead to acceptance chunk with wrong data inside. They change it because there were problems with version synchronization (problem originated from original MooseFS). To fix that you should fix synchronization, not just accept everything.
Believe me this is only one simple example. I know what I fixed in MooseFS in those years since 1.6. They didn't fix almost any of these.
>
>
>> 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.
>
> That's very nice. Although contributing to MooseFS without VCS and bug
> tracker is not easy...
You are right. We will change that.
>
>
>> The think is that we have a lot of users (probably more than LizardFS - of
>> course it's unprovable)
>
> It is entirely possible that MooseFS still have more customers even despite
> loss of those who prefer LizardFS. But popularity is a poor criteria. How is
> it suppose to influence our decision?
>
Maybe because huge part of our users are also Debian users and you may want to make their life easier.
>
>> and all of them should have right to choose. This is called democracy.
>
> You seems to mistake freedom of choice for democracy. Democracy is not what
> we use to justify introducing of software to Debian. Also see Mencken's quote
> about democracy below.
:)
ok here I totally agree. I don't know if you are aware of this or not, but we have in Poland new government chosen in democratic poll, and they are just ... stupid (horribly stupid and radical).
So call it freedom not democracy. Your (Debian) users should have freedom to choose.
>
>
>> MooseFS is available in almost all other OS'es in standard ports/packages.
>
> MooseFS packaging is immature and do not meet Debian standards of quality.
I didn't know that. Can you help us to improve that (I understand that you do not have time and don't want to involve, but maybe there is some documentation, some hints - how to improve that)?
>
>
>>> Thank you for interesting insights about projects history.
>>
>> There is more. And it's pity that you even help them.
>
> I'm not sorry for helping LizardFS and I do not regret investing my time in
> LizardFS. (For the record I do regret time I wasted helping Ceph). I believe
> LizardFS is worthy of help as they seems to be doing the right thing.
This is your decision who you are helping. If you believe in them then help them, but at least try not to be against us. I'm still inventor of MooseFS and I hope that I still make a good job with MooseFS.
> They do
> care for their product and I think that's why they've forked MooseFS in first
> place.
Of course they care, but it doesn't mean that they make success in that.
As I know (and I know a lot about this, but not all of course) there were other reasons behind fork, but it is another story.
> It remains to be seen if they'll be able to do better job than MooseFS
> team but so far LizardFS team seems to be doing things properly with care for
> best practice etc.
>
> --
> All the best,
> Dmitry Smirnov.
>
> ---
>
> Democracy is a pathetic belief in the collective wisdom of individual
> ignorance.
> -- H. L. Mencken
--
Pozdrawiam,
Jakub Kruszona-Zawadzki
- - - - - - - - - - - - - - - -
Segmentation fault (core dumped)
Tel. +48 602 212 039
Reply to: