[argyllcms] Re: ArgyllCMS V1.1.0 RC1 is now available
- From: Richard Hughes <hughsient@xxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Mon, 9 Nov 2009 10:19:29 +0000
2009/11/6 Graeme Gill <graeme@xxxxxxxxxxxxx>:
> Automake isn't cross platform :- it isn't available on MSWindows
> without installing a whole UNIX like environment, and I prefer
> using Jam in any case since it's simpler to use. Perhaps some
> other projects should switch to Jam too :-)
Sure, but automake is the #1 build system that works on Linux, *BSD,
and Solaris, which I'm guessing is the vast majority of your userbase
right now.
>>> * A heavily hacked up local version of libusb is present
>
> That's what it takes to make the project work reliably with all
> the different instruments out there. While it would be great to
> fix libusb so that the current version was suitable for
> use with Argyll, I thought a release this November would
> be better than next February...
Well, I think fixing the problems in upstream libusb would probably
help other projects out who are hitting the same bugs. Patching this
locally does not contribute to the wider ecosystem, and makes it hard
for you when libusb gets fixes and you have to manually apply them at
each branch point.
>>> * No public CVS, SVN or git tree is available
>
> My code base contains some proprietary code that makes it
> difficult to make public. I'm not sure if there is some
> arrangement that could accommodate what you're after, if
> the use cases could be explained.
Right, use cases:
* I want to get access to the latest argyllcms code, that-is the beta
tarball you announced with the fixes you've ack'd and applied since
then
* I want to see why a piece of code was changed in a commit you made a
few months ago
* I want to maintain a local branch on argyllcms with some more udev
patches, and then propose them as a patchset
Many other projects I work for have proprietary private branches.
For reference, I used to work for a UK defence contractor which
contributed code back into the open source community, and yet
maintained private versions which had IP or private licence
agreements. If a super-locked-down defence contractor can achieve
this, then I'm sure it's pretty easy for you too.
>>> * The licence has just changed, and the project has multiple licences
>
> That's the nature of assembling a project from a number of components.
Right, that's not a problem for me per-se, I was just bringing it to
your attention and trying to avoid yet further licence proliferation.
> I'm not sure quite why that is. If you took the approach of
> first building Jam and then using it to build Argyll, it might
> be simpler (aren't you building Jam for the Free Type project anyway ?).
No, jam isn't required to build any other component on my system. Jam
has some pretty big bugs with multiarch and building on odd
architectures.
Quoting from the jam-users mailing list "[jambase is] notorious for
bugs and the infrequency with which fixes are integrated" -- this
isn't the stable project that a build system needs to be.
But sure, it's your call as you are the maintainer. What I'm asking is
for you to include the configure.ac and Makefile.am file _alongside_
the existing jam buildsystem. We'll maintain it, if it breaks, we'll
fix it. You don't even have to include it in the release notes as a
supported feature.
> There has been some degree of hurt caused by differences between
> distribution versions and upstream already, notably with breakages.
Sure. The less input you get from distributions, the less likely they
are to package your code and ship it in their repos. People will
instead code for libraries they can find in RHEL, SLES and that sort
of thing, which for now just includes littlecms and not a lot else. By
making this hard to build, you're not making it easy for distributions
to ship your code. By making it hard to contribute, you're making it
hard for distributions to feed back patches to you.
> accommodate changes to help people use the code, there are limits.
> My aims are not necessarily the same as everyone who would like
> to make use of Argyll (it's not a community project, and specifically
> it's not a Linux community project - it runs on a wider set of platforms
> than that. Making the code available under the AGPL is a compromise -
> I'm trying to make it available as open source while retaining most
> useful commercial opportunities for myself, hence my choice of the most
> restrictive available open source license).
Sure, and I can understand that. What I'm trying to make clear is that
without opening up ArgyllCMS development it will remain a niche set of
tools for the 0.01% of people that understand what a CM actually is.
Without integrating with front end applications and with other system
and session frameworks, ArgyllCMS is just a cool set of commandline
programs that nobody knows really quite how to use.
> I specifically chose Jam to avoid Automake, make etc., so no,
> I'm not going to maintain an Automake build setup!
Nobody is asking you to. Just include the files in the tarball (or zip
file) so we can build it without all of the linux distributions having
to essentially hack in a new build system.
> It would be good to get over the libusb thing - it's just a user level
> library, not a kernel driver or anything terribly important.
Bttz. See my reply above. Using that logic you could copy over large
chunks of libc and make changes there, which we both should agree is a
bad idea. It is certainly harder pushing proper fixes upstream to
libusb, but it's something you just have to do as a responsible
maintainer.
> The normal
> pressures of development (ie. do I want to maintain a fork of such
> a library) will probably sort out the duplication in due course (either
> I'll get around to helping fix libusb so I can use it unaltered, or I'll
> re-implement USB support within Argyll without using libusb.)
I think it would be a shame to re-invent a userspace USB stack in this
case, and it worries me that you think that's an option. Building a
thriving and stable project is meant to be re-using components as much
as possible, and benefiting from working together on a shared goal.
Now, I'm aware I've done a fair bit of ranting, and I don't want to
come over as as jackass as I do appreciate the work you're doing. I'm
just getting passionate as ArgyllCMS is a project I believe can be a
much larger part of the solution, otherwise ArgyllCMS is going to be
replaced with frameworks that are much easier to build, contribute and
use.
Richard.
Other related posts:
