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 theyare 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.