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?
> > 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 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. They do
care for their product and I think that's why they've forked MooseFS in first
place. 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
Attachment:
signature.asc
Description: This is a digitally signed message part.