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

Graeme Gill, 2009-11-07 10:06:35 +1100 :

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

I work on FusionForge, with several bits of code that are not public,
and these bits just live on separate branches that I keep for myself
(and my clients).  When I develop a feature, either it's going to be
public and I commit it to the public trunk (which I then merge into the
private branch), or it's not and it only ever lives in the private
branch.  Distributed version control systems (Bazaar, in my case) make
that quite easy.

  As for the use cases, well, I guess there are two that could be of
interest:

- when you get a bug report and fix it, you can tell people to test the
  current trunk, you don't have to roll tarballs and do release stuff
  each time; this makes it easier to get feedback and testing;

- in the other direction, when we packagers/distributors patch things,
  it's easier for you to get an idea of what exactly we changed and
  possibly merge it into your tree; this helps reduce the difference
  between your original code and what gets shipped in packages.

[...]

> There has been some degree of hurt caused by differences between
> distribution versions and upstream already, notably with
> breakages. While I'm quite ready to accommodate changes to help people
> use the code, there are limits.

  This is entirely your decision to make, and I for one respect it.  I
believe switching to a DVCS model would help reducing, or at least
knowing about these differences, but it's only a suggestion.

[...]

> I specifically chose Jam to avoid Automake, make etc., so no, I'm not
> going to maintain an Automake build setup!

  Again, that's your call.  I've sort of inherited the existing
autotools setup, and I'm willing to maintain it since it really does
make my life as a packager easier (and, presumably, also for other
distributions).

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

  You'll think I'm a broken record :-) but having your libusb source
control repository public and pointing the "upstream" libusb team at it
would probably help them integrate your changes.

Roland.
-- 
Roland Mas

We reject: kings, presidents and voting.
We believe in: rough consensus and running code. -- IETF

Other related posts: