[Libusbx-devel] libusbx v1.0.9-rc5 is now available

Pete Batard pete at akeo.ie
Wed Apr 4 07:04:14 EDT 2012


On 2012.04.04 04:09, Michael Plante wrote:
> Do you plan to maintain a testing branch equivalent to libusb-pbatard/master
> that you can commit freely to without review?

Well, as I explained quite a few times before, -pbatard was only meant 
to be a *temporary* branch, which is part of the beef I've been having 
with libusb. My expectation was that it'd be up for a few *weeks* (I 
anticipated 2009.12-2010.03 tops), up to the time I had something 
polished enough to be integrated into libusb, even if not finished, and 
from then on I'd be able to push Windows addons, fixes and features off 
mainline, without the need for a development branch. This way 
everybody's on the same page, and we make sure that users don't have to 
jump through hoops.

In essence, what you'd expect from a RERO project.

Ever since then, my goal has been to see the gap bridged so that I can 
ditch the -pbatard branch at long last, whilst ensuring that 
libusb/Windows has the features that our users deserve (such as DLL 
interchangeability, HID, etc.). The idea really is that time spent 
*DUPLICATING* maintenance work, which is what you do when asking someone 
to maintain their own "topic-branch", is time wasted as it could be used 
to improve libusb instead. On a project the size of libusb, maintainers 
should appreciate that developer's time is valuable because very few 
people seem to effectively use theirs to produce patches (Don't know 
about you but I find our AUTHORS list, which lists every single git 
contributor, pitifully small for a mainstream project that is more than 
4 years old). Therefore, forcing people who want to contribute code to 
also take on a lengthy exercise in time waste that could be avoided is 
counter productive.

IMO, a personal development branch should be used up to the point where 
you can produce something that is presentable for integration, at which 
point it either gets accepted (which doesn't exclude some back and forth 
and additional development to improve on the proposal) and you can drop 
your personal devel branch to work off mainline, or it's rejected and 
the the whole thing, branch and all, is dropped altogether.

But the goal should always be to have the new feature integrated into 
mainline *EARLY* so that it gets high visibility, is scrutinized by the 
largest number of people, and gets tested as widely as possible. Of 
course, there exist some mitigation factors on very large projects, as 
the volume of expected daily input and how much maintainers can handle 
has to be factored in, but I don't think this will ever be a concern for 
libusb(x).

So, to sum up, and I can tell you these have been my thoughts ever since 
the day the branch was created: "The sooner I can ditch libusb-pbatard, 
the better". Right now my ditch target would be 1.0.12, as there 
shouldn't be that much left to bridge, but it's still a wild guesstimate.

> That was kind of a pain to track

Of course it was. Anything that's not mainline is a pain to track, and, 
unless it's tackling something that needs very careful consideration, a 
development branch should never exist for more than a few months.

Regards,

/Pete



More information about the libusbx mailing list