[argyllcms] Re: ArgyllCMS V1.1.0 RC1 is now available

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Tue, 10 Nov 2009 01:41:47 +1100

Richard Hughes wrote:

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.

Just because it's #1, it doesn't make it the right thing to choose.
Sometimes we want to move on to better things.

Well, I think fixing the problems in upstream libusb would probably
help other projects out who are hitting the same bugs. Patching this

As I mentioned, upstream is not accepting fixes anymore for
pre V1 libusb, while V1 libusb is not cross platform, so
there is nowhere to go with this currently.

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 understand, I'm just not clear on how to achieve this.

* I want to maintain a local branch on argyllcms with some more udev
patches, and then propose them as a patchset

There are some issues with this too, in regard to
authorship.

Many other projects I work for have proprietary private branches.

I'm not sure if/how this can be made to work, since I'm not a SCC
expert, just a user of it. Currently the proprietary/GNU release
process is automatic, so I don't have to think about it too much.

There is another possible solution to this down the track
that I will keep in mind as things progress that would allow
what you want, but would have it's downsides.

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.

Right, but I'm guessing that they consisted of more than a single
person, and hence had the manpower to handle the details ?

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.

Perhaps if bug fixes were sent upstream, these problems could be
fixed ? :-)

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.

I'm not sure where you got that impression from. Jam is a very
stable application, and has been used extensively.
(It's worth thinking about how innovation happens in
various areas here.)

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.

Um, I'm not the maintainer, I'm the author. I can guarantee that
as soon as I include such files in the distribution, people
will expect them to work, and start complaining to me about
it if they don't, in spite of whatever disclaimers I put on it.

Sure. The less input you get from distributions, the less likely they
are to package your code and ship it in their repos.

Sorry, that doesn't distress me very much, since my aim is not
to be in as many distros as possible !

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

My conclusion was that lcms was picked up more than libusb/Argyll
due to the licensing (lcms being more attractive in not being GNU
licensed), the lack of integration of imdi into libusb,
and the lack of documentation of the libusb API.
But that's fine, if I'd given away imdi with a free use license,
I wouldn't be working on Argyll anymore, since I wouldn't
have an income from working on color.

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.

I'm not liking the sort of patches I seem to be getting out
of distributors much though, and I think that the sort of
software eco-system that distributions encourage have their
drawbacks (lack of 3rd party applications being a major one).
In general I'm happier if users get the real thing from me,
rather than something that may have been modified in ways that
are unsympathetic to having a working application.

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.

That's cool with me. It's not built to be an application for
everyone, it's meant to be a set of low level tools that I've developed,
and that I thought I would share.

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.

I don't thinks that's a reasonable analogy. libc is standardized and
relatively fixed, libusb 1 is far from stable and broadly supported
on different platforms at the moment.

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.

Sure, but our goals don't mesh at the moment, and Argyll would be little
different from hundreds (thousands ?) of other applications if it
included it's own internal to native usb library (which it does anyway
at a higher layer than libusb).

Graeme Gill.

Other related posts: