On Thu, 16 Oct 2014 15:15:28 Michael Tokarev wrote:
> Your package does not build because of something. At least maybe
> some investigation is in order, instead of just ignoring the situation.
Agreed, ideally investigation would be desirable. However in reality this
backport is a best effort. Arguably this (incomplete) backport is better than
nothing at all. Besides is wasn't even my idea -- first Ceph backport was
uploaded by Thomas Goirand and I was merely updating it ever since.
> > I respect your high quality standards but I'm not sure if I can keep up...
>
> Ofcourse I was complaining in context of qemu backport.
Until now I had no idea that Ceph backport is affecting other package(s) and
that it is not just an isolated case of a standalone package. Why didn't you
raised your concerns earlier?
> And there,
> I do care about "non-major" (it is not my word, it is your)
> architectures, -- for example, many users use qemu on mips to
> run x86 code, and many of them request the backport of new features.
I see...
> I can't say to them "I don't care because there's some dependency
> wchich is not mine and you're not upstream". That'd be wrong, and
> there's nothing about "high standards" in there.
That's not that I do not care because I do not care. This is all about best
effort. With my current situation I can only admit that following
uninstallable Ceph Build-Depends on some architectures is not my priority.
Sorry.
> Either you do care about the backport, and, at least, do the right thing
> and mark cleanly that it will (or should) be available on that and that
> arch -- so that others who use it know to enable it only on these
> arches. Or get the missing arches going somehow, by backporting
> the missing deendencies (as I had to do too), or pinging other
> maintainers or whatnot.
To me care exists only in context of capabilities. I care as much as I can (I
call it "best effort"). Not good enough? Too bad I couldn't do better... :(
> What I'm saying is that the current behavour isn't really the best one
> to use, -- it really is "fire and forget", or "don't care". There's
> nothing about high standards really.
Standards, expectations whatever. I can't meet your expectations that's the
idea. At least now you've explained why caring about those architectures is
important. I'll see what I can do with next upload...
Let me explain a little bit about current situation with Ceph. Ceph is by far
the most demanding package I've ever worked with. When I picked it up from
pretty much unmaintained state early this year I thought it would take about 3
months to stabilise it. It took three times that much time and even 9 months
since I started working with Ceph I'm still not satisfied with it. Since
beginning of this year I was mostly consumed by Ceph and I managed to do only
little other work. I invested quite an amount of funds to infrastructure
allowing me to run 5-node (~28 TB) Ceph cluster at home. It took extraordinary
amount of time to chase every problem that I've experienced with upstream.
I filed number of pull requests and reported over 40 bugs (even if 25% of them
were rubbish you can get a rough impression of how many problems used to be
out there). Building Ceph is not quick and every upload is about 700 MiB.
I lost count of how many times I tried or cherry picked yet another patch, re-
built, re-deployed and re-tested Ceph before uploading packages. Now when Ceph
is more-or-less stabilised I'm badly behind my plans and in order to survive
financially I can afford spending only little time for Ceph. I'm sorry for
neglecting some architectures in backports, but so far I was doing my best and
I can only apologise if that wasn't enough. There is always more to do isn't
it?
--
Cheers,
Dmitry Smirnov.
---
Much of humankind's intellectual and emotional struggle has been not
for truth, but against truth. The advance of science has been
sporadically fought against for thousands of years.
-- C. W. Dalton, "The Right Brain and Religion"
Attachment:
signature.asc
Description: This is a digitally signed message part.