Bug#810822: ITP: MooseFS Debian repository contains a fork of MooseFS

[Dmitry Smirnov]

On Mon, 18 Jan 2016 06:53:05 AM Jakub Kruszona-Zawadzki wrote:
> On 15 Jan, 2016, at 15:04, Dmitry Smirnov  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?


> > 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.


> 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.


> 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.

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.

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.


> 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.


> 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. 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.


> 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.


> 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...


> 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?


> 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.


> 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.


> > 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 

Bug#810822: ITP: MooseFS Debian repository contains a fork of MooseFS

[Jakub Kruszona-Zawadzki]

On 18 Jan, 2016, at 8:25, Dmitry Smirnov  wrote:

> On Mon, 18 Jan 2016 06:53:05 AM Jakub Kruszona-Zawadzki wrote:
>> On 15 Jan, 2016, at 15:04, Dmitry Smirnov  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.
> 
> 

Bug#810822: ITP: MooseFS Debian repository contains a fork of MooseFS

[Jakub Kruszona-Zawadzki]

On 18 Jan, 2016, at 10:04, Dmitry Smirnov  wrote:

> On Mon, 18 Jan 2016 09:16:25 AM Jakub Kruszona-Zawadzki wrote:
>>> 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
>> :) )
> 
> Number of bugs is not a metric of quality.

Really?

> Remember that bugs are also items 
> on developers' TO DO list.
> I reported more LizardFS bugs than anyone else (up to 100) and I'm using 
> LizardFS because it survived vigorous testing.

Did you ever tried huge installations? 3PB, 100mln of files?

> Bugs are also different: some 
> are feature requests, some are not critical for data integrity etc.
> I'm not aware of release-critical bugs without fix but of course there might 
> be some.
> 
> 
>> Hence I'm in favour of LizardFS.

Your choice. I don't have problem with that, but please don't be against us.

>> 
>> I hope that it will change some day. Did you even try to test MooseFS 3.0?
>> Compare to LizardFS?
> 
> So far I've seen no compelling reasons to switch away from LizardFS - not 
> until MooseFS become more open. At the moment IMHO LizardFS is the only 
> choice (and GfarmFS is close second). Also I have no time to try MooseFS. 
> Maybe one day I'll try it but I'll have to justify the effort...

So you shouldn't say bad words about MooseFS. We test LizardFS (and others - 
like Ceph, Gluster etc.) on regular basis.

I understand that it is time-consuming, but I hope that you will find time in 
the future and give it a try.

> 
> 
>> If you need PRO licence to do some test then let me know - We will send it.
> 
> Thank you for your kind offer but no. :) I will only evaluate what's free and 
> suitable for Debian.

ok. :)

> 
> 
>> 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.
> 
> Interesting, thank you.
> 
> 
>> Maybe because huge part of our users are also Debian users and you may want
>> to make their life easier.
> 
> Makes sense.
> 
> 
>> 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).
> 
> I feel your pain. I feel ashamed of our Australian government. :(
> 
> Popularity polls are poor foundation for decision making. But as Winston 
> Churchill once said, "It has been said that democracy is the worst form of 
> government except all the others that have been tried."...

Exactly.

> 
> 
>> 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)?
> 
> Here you can find some generic links to documents describing packaging for 
> Debian:
> 
>http://mentors.debian.net/qa
> 
> Lintian checks (including pedantic and experimental ones) provide useful 
> hints for areas that can benefit from improvements.
> 
> Also you can refer to official LizardFS packaging which have numerous 
> improvements over "upstream" packaging: 
> 
>https://anonscm.debian.org/cgit/collab-maint/lizardfs.git
> 
> Feel free to ask questions in mentor's mail list. If you CC to me I'll try to 
> answer as well if time allows.

Thanks a lot. This is very helpful, we will check that. I remember porting to 
official freebsd ports - PITA, but what to do. There are rules and we 
(developers) should obey them.

> 
> 
>> 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.
> 
> I'm not agains you or MooseFS. Even though at the moment I'm in favour of 
> LizardFS I'm sure LizardFS would not be where it is now without solid 
> foundation of MooseFS.

Thanks for saying that, because at the beginning I had a feeling that you are 
against us.

We are still making this solid foundation (i hope :) ).

> 
> -- 
> All the best,
> Dmitry Smirnov.
> 
> ---
> 
> Odious ideas are not entitled to hide from criticism behind the human
> shield of their believers' feelings.
>-- Richard Stallman

-- 
Regards,
Jakub Kruszona-Zawadzki
- - - - - - - - - - - - - - - -
Segmentation fault (core dumped)
Phone: +48 602 212 039

Bug#810822: ITP: MooseFS Debian repository contains a fork of MooseFS

[Dmitry Smirnov]

On Mon, 18 Jan 2016 09:16:25 AM Jakub Kruszona-Zawadzki wrote:
> > 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
> :) )

Number of bugs is not a metric of quality. Remember that bugs are also items 
on developers' TO DO list.
I reported more LizardFS bugs than anyone else (up to 100) and I'm using 
LizardFS because it survived vigorous testing. Bugs are also different: some 
are feature requests, some are not critical for data integrity etc.
I'm not aware of release-critical bugs without fix but of course there might 
be some.


> 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?

So far I've seen no compelling reasons to switch away from LizardFS - not 
until MooseFS become more open. At the moment IMHO LizardFS is the only 
choice (and GfarmFS is close second). Also I have no time to try MooseFS. 
Maybe one day I'll try it but I'll have to justify the effort...


> If you need PRO licence to do some test then let me know - We will send it.

Thank you for your kind offer but no. :) I will only evaluate what's free and 
suitable for Debian.


> 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.

Interesting, thank you.


> Maybe because huge part of our users are also Debian users and you may want
> to make their life easier.

Makes sense.


> 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).

I feel your pain. I feel ashamed of our Australian government. :(

Popularity polls are poor foundation for decision making. But as Winston 
Churchill once said, "It has been said that democracy is the worst form of 
government except all the others that have been tried."...


> 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)?

Here you can find some generic links to documents describing packaging for 
Debian:

http://mentors.debian.net/qa

Lintian checks (including pedantic and experimental ones) provide useful 
hints for areas that can benefit from improvements.

Also you can refer to official LizardFS packaging which have numerous 
improvements over "upstream" packaging: 

https://anonscm.debian.org/cgit/collab-maint/lizardfs.git

Feel free to ask questions in mentor's mail list. If you CC to me I'll try to 
answer as well if time allows.


> 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.

I'm not agains you or MooseFS. Even though at the moment I'm in favour of 
LizardFS I'm sure LizardFS would not be where it is now without solid 
foundation of MooseFS.

-- 
All the best,
 Dmitry Smirnov.

---

Odious ideas are not entitled to hide from criticism behind the human
shield of their believers' feelings.
-- Richard Stallman


signature.asc
Description: This is a digitally signed message part.