[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