Post by Peter StugeWould suggest to start by adding those in two separate commits before
anything else in K.
Except, these are commits that maintainers explicitly expressed that
they didn't want in mainline, and I could add xusb as a prereq there too.
Daniel was adamant at one stage that he didn't want the MSVC project
files (but I'll assume we're over that now), and you don't seem to want
toggable logging or xusb.
Of course you're going to tell me that having the above or not shouldn't
impact the K patches for mainline, but there's other stuff that I might
be relying upon, like new enum, and considering that mainline seems to
be very adamant about trying to remove stuff that I do, I'm not gonna
take any risks.
In short, I do see mainline as a mess of shifty sand right now, as far
as Windows is concerned, which creates extra work for me that I wouldn't
have to do if integration issues were sorted out as they came along.
Besides, it's not like we're going to try to delay 1.0.9 to integrate K,
since K is still in early stages and incomplete (or are you suddenly
going to do RERO for K?). My view is that 1.0.9 should have Windows as
it is now, 1.0.10 should be the release that sorts MSVC/project files,
def generation, new enum, and do the overall catchup with my branch, and
1.0.11 should be the release looking into integrating K. And this is
from a RERO man. Anything else is just asking to multiply problems and
keep on not being able to produce libusb releases.
Post by Peter StugeNeed only do that work once,
Provided I can rely on you guys not deciding, once again, to want to
remove stuff on a whim. Until there's a release, I consider that
anything I propose is up in the air, so I'm not gonna take that risk. As
things being kept in balance for more than a year have taught me, it's
just not worth the trouble gambling on dependencies that still aren't
part of an official release.
Post by Peter StugePost by Pete BatardBut sure, I should waste my time duplicating files over and over,
No, but making the commits once and for all,
Well, the problem is the once and for all. You don't really want
toggable logging, or HID, or xusb, do you? So I'd be relying on "once
and for never" commits for my K branch. Might as well branch off my
forked repo then.
But seriously, just give us a stable mainline base where contention
points have been sorted, and then we'll discuss how contributors should
best branch from it. I've seriously had it with trying to base my work
on stuff that is going to be up in the air for months. If you want to
give advice about how mainline is the stable base to use for new
developments, then get your act together and actually stabilize mainline
through releases.
Post by Peter StugePost by Pete Batardam I supposed to release another bunch of binaries for the K branch
No, or at least I don't think that would be useful.
I do. I think people want libusb0/k.sys support ASAP, as you yourself
expressed that WinUSB and HID had too many limitations, and you also
expressed the idea that most Windows people would rely on binary
releases. So I'm just following your line of reasoning here.
Post by Peter StugeThe purpose of
the K branch (any branch really) is to make it as easy as possible
to add the code into libusb.git.
Nope. The #1 purpose of any branch I create is feedback (through RERO),
else I'd just keep it private until I'm satisfied that it should be good
enough for integration. And since experience has shown me that topic
branches, such as hotplug, don't fare well in term of feedback (and I
don't see how branching off mainline or -pbatard would change anything
there), the sooner the K branch is dropped and integrated into -pbatard
the sooner we'll get effective testing, and, as a result, the better the
quality of K code.
Adding the code in libusb.git is secondary to getting good feedback so
that we have something of quality to integrate into mainline, when the
time comes. It's really not that hard to create a few patches for
integration from whatever branch.
Post by Peter StugeDiverging further from libusb.git increases the required duplicated
effort.
Don't worry, I'll be the one doing that effort. And I find that overall,
doing it this way reduces the duplicated effort I need to produce, by
maintaining myriads of branches.
I've become very effective in crafting patches for mainline out of my
big fat -pbatard branch. It's only if libusb can't bridge the gap with
Windows for another year that it's going to become really troublesome.
Until then, it's just more effective this way.
Post by Peter StugePost by Pete BatardNeither mainline or -stuge are ready for K.
WinUSB is in there, so I wouldn't expect the K commit to be very
different from how they would look on top of -pbatard master?
When I started, it was hard to tell whether K would depend on/modify
new-enum. It appears that it doesn't, but I assumed that it would. As
such, I'd have to produce a new-enum patch against mainline before I
could even consider going into K. Yeah, I'll have to produce a new-enum
patch for mainline eventually, but I'd rather do that when I have the my
own integration branch up, which depends on your configure.ac. All in
all, branching off mainline doesn't make sense. It's simply too far
behind, with too many unresolved contention points, to be a serious
contender as a branch point for anything Windows.
Post by Peter StugePost by Pete BatardHow's that reworked configure.ac in -stuge coming along by the way?
It's mostly removed, but still needs some more looking at. Am having
fun with patches for Darwin from Freenect right now.
OK. Just remember that it's a major bottleneck for me, so the sooner you
get a finalized configure.ac, the better.