[argyllcms] Re: New Bug with Eye One Pro built against Ubuntu libusb
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Thu, 03 Jan 2008 13:40:36 +1100
Nicolas Mailhot wrote:
Sure you can. No one here thinks he can force you to do something you do
not want. My point was that free/libre software development is organised
around some conventions. If you follow those conventions other people
can work with you, if you don't you end up working alone with zero
support. And like any convention their value is not they're the best
possible solution but that you can rely on others to follow them.
As I've observed before, I think that my motivations are not necessarily
in concordance with the bulk of the "free software" world. I've not
set out here to create a popular, easy to use GUI application package (nor
is this ever likely, since there's no funding for me to pursue such
a goal), it's a collection of relatively low level tools that a more
restricted audience may find of some use and interest. Within that
scope I'm striving to make the tools as foolproof as I can.
This is partly in self defence from a support point of view,
and because I want my tools to be a pleasure to use.
That is the value in following the same rules as everyone else. No one
is going to write core Argyll code in your stead (ok some people may but
I can't promise it). Nevertheless a lot of peripheral work needs to be
done for core Argyll code to work properly on all systems (for
example, propagating the libusb or kernel changes Argyll relies on).
This work will only be done by others if you create the right conditions
for them to do it.
I'm happy to meet somewhere in the middle, and will continue
to make changes that work in the direction of making life easier
for those attempting to use Argyll.
Of course that's your choice. You may feel that changing your habits is
not worth it, that you get a better deal by following your own
conventions, doing all the integration work yourself on your own systems
with no third-party intervention. I respectfully disagree.
It's not really about "habits". My project is cross platform, and
the standard Linux tools aren't cross platform, and for good
software engineering reasons I want to minimize platform specific
code. In addition, innovation and progress aren't often made
by just doing what everyone else does. The standard UNIX/Linux
build tools have been observed to have many drawbacks, and I'd
rather push in the direction of making change to improve things,
than continue to struggle with them. Jam looked promising ten
years ago when I started this project, and I'm willing
to agree that it's not been widely embraced and look to
something else, but I'm not prepared to go backwards.
As for libusb, it's about making sure that the project works.
You may not see the analogy with the kernel "taint" flag,
but I certainly do. If I have to use the stock libusb and libusb-win32,
then my experience has been that I simply can't get certain instruments
working that should be able to work. If I have to wait for changes
to be fed through from upstream, progress would be crippled. With
open source I don't have to put up with these issues.
I don't think Argyll's current integration process is working (its code
didn't build and its binaries didn't run on my system before I massively
patched it).
I think that really reflects issues with platform uniformity,
even amongst just the Linux distributions. Of course I observe
no such issues on all the platforms I build on :-)
I'm currently attempting to get a test system up and
running to be able to test more widely, so this should
help smooth some of these issues out.
> And I can promise you a lot of people won't ever help with
Argyll problems before it's integrated in major distributions.
As I've said, I am not distressed at the idea of Argyll not being in
any distributions, it's been that way for a long time. An alternative
is for me to look towards better binary installation (say, ZeroInstall
or Autopackage).
> Few
people are interested in helping projects that don't bother getting
themselves packaged. The packaging bar is not high, thousands of
projects passed it a long time ago.
And a key issue I think is that you are speaking about "packaging for Linux",
not "packaging for Linux, MSWindows and OS X".
cheers,
Graeme Gill.
Other related posts:
