[Libusbx-devel] Keeping the 1.0.9rc3 tag

[Pete Batard]

On 2012.03.26 13:36, Michael Plante wrote:
> I guess what I mean is that "master" can have HEADs over time that are not
> direct ancestors of one another.

Yes, and I addressed that point. The only HEAD that matters is the one 
from mainline.

> Both are still "mainline" because they
> were both the tip of "master" on the "mainline" repo at one point in time.

But both aren't going to see releases *by us*. If they do, they will 
have different offsets.

>>> Please define "maintainer".
>
> You, and anyone else who can push to the official repo.

Currently 3 people, and not exactly expected to increase. These are the 
people who have admin access to git.

I'm kinda hoping we will coordinate releases between ourselves, and not 
for instance have Hans decides he wants to release a semi-official 
1.0.15 from one of his branches and me releasing a different 1.0.15 from 
my branch (or from mainline), without coordinating an offset to ensure 
that, should that be the case, the nano is different.

I still don't see what your problem is with that.

>>> Ah, yes, there's "right" and "wrong" and, of course, you are the judge.
>>> Beats having to provide verifiable evidence of an allegedly better
>>> solution, doesn't it?
>
> When you move the evidence farther down, it sure looks that way, doesn't it?
> Clever.

I'm still waiting for concrete implementation details of your "better" 
approach so that I and anybody else can judge. Where are they?

>>>> You are repeating yourself for nothing.
>>>> You can't even tell if a log file came from a forked version.
>>>
>>> Why would I want to?
>
> So you can tell if you want to support it or not.

But I can't do that if someone uses SVN or, if they use git, if they 
modified something they picked from mainline without committing, or if 
they forgot to apply versioning or whatever very foreseeable reasons 
might exist for the versioning we would like them to apply to help us 
differentiate forks not having been applied.

You want us to go out of our way just so that, in case someone uses git, 
and diligently applies our versioning recommendations, we will get a 
different nano. Well, if they do that, and since they WILL HAVE to apply 
our recommendations, as we can't automate anything for them (but feel 
free to provide a proposal that does), our recommendation will be that 
they modify the pre-commit to add a nano. I can even reserve a specific 
offset that all forked branches that are outside of our control should use.

There, just as good as whatever solution you think is better to help us 
differentiate between unaffiliated forks and mainline.

>>> We can not solve this problem
>>> unless the fork uses git and people diligently apply our pre-commit
>>> hook.
>
> I don't think pre-commit will work, since the hash is not yet known.

Indeed a pre-commit cannot work for a hash. But it works very well for a 
distance, so that's something we may want to factor in.

> It
> might have to be part of the build script (which would have to fail
> gracefully if git's not there), or perhaps it could be post-commit and go in
> an ignored file (though ignored files are risky).

And what about MSVC people who don't run a build script? Oh, right, 
we'll "just" have to add a pre-build script there (you want to do that 
in all of VS2010, MSVC6 and WDK, since it actually multiplies the work 
by 3?), and ensure that it is in sync with the logic we'll use with 
autotools. And what about people who are going to use their own build 
scripts? How much extra complexity do you want to add to "make believe" 
we can exert some for of control over something for which, by 
definition, we have no control on and, moreover, for which it is foolish 
to think we can or should exert some.

Compare that with a pre-commit hook that works regardless, and that 
freezes the version as soon as someone deviates, so that we can pretty 
much always (unless people ignore the warnings in our pre-hook commit 
when they actively add it) identify the node that deviation originated.

> People who aren't using
> git are presumably also people who know where they got it from

How convenient. "*I* have decided that people (non git users) who are an 
annoyance to my solution don't matter".

Should I also decide that, since it's an annoyance, your opinion doesn't 
matter as well?

> so that's
> not really in line with that part of your original reason that I was trying
> to help with.

Indeed, you seem to have forgotten to factor in few things in whatever 
approach you see as more suitable.

> I didn't say "fork".  Please read the words.  I am assuming they just
> grabbed a tarball and closed their browser and don't remember where it came
> from.  Most such tarballs probably will come from git, and likely from one
> of us (not all, but most, which means solving the problem MOST Of the time).

Ah, now we're getting to solving the problem "MOST of the time". Quite a 
depreciation from being able to "*KNOW*" when it came from a fork (And 
I'm going to continue using fork, because a tarball that's not official 
is a fork)

> Anyway, if it's "impossible" (it's usually, in fact, possible), why was it a
> primary goal of yours?

Where the hell did I state that?

Here is, again, my original statement with regards to versioning:

"should solve both the problems of being able to know *exactly* which 
commit the library came from, even if built from git, if generated 
against mainline (if not, then it's a fork, and since anything can 
happen in a fork, of course we don't care about version conflicts 
there), as well as being able to know whether someone is using libusb or 
libusbx."

The 2 problems I want versioning to solve is libusbx vs libusb and 
commit from mainline. I explicitly state that I didn't care about 
version conflicts from forks, for all the reasons previously exposed. 
How then is that a primary goal of mine?

>>> No we can't, unless you want to make the version reported by the DLL
>>> differ from the actual version of libusbx (and I think you should be
>>> aware that we probably wouldn't mind if someone can just right click on
>>> their DLL without running anything, and report what they see). We have
>>> only 16 bits for the nano due to Microsoft's versioning constraints. So
>>> it's either a 4 hex hash or a 0-65535 integer.
>
> So you can't put it in the version number.  And?

Not at all. I can put a distance there no problem at all, even planning 
for offsets. We're not going to have more than 65536 commits for each 
major.minor.micro, and if we ever go over boundaries we set, as long as 
we have switched micro, we can "reset" the distance, so we could 
probably work within a a [0-999] window for the nano, and still be fine. 
Hashes on the other hand, are more problematic, as there's a 1 in 65536 
chance you will get a collision if you only use the first 4 digits, to 
be able to let users find the version from the DLL properties.

>>> Please cease to think that I gave this problem 5 minutes thought and
>>> went with whatever I liked or that I thought could easily be reused.
>
> I think that you are unaware of anything other than a linear history, and
> have therefore missed why the distance thing is insufficiently general.

On the contrary, I think you are inventing excuses to pretend the 
distance cannot work with non linear history, when I have provided ample 
evidence it can. A tree just requires a system of x,y coordinates, and 
we could easily provide such a system with (y*1000+x), with each fork 
being a new y. Unless you count on libusbx maintaining 65 semi-official 
branches at once, non-linear is really a non-issue. And I'm pretty sure 
we'd be fine even if we went with (y*10000+x), which is way more than 
we'd need not to have to reset the nano. At the very least, a 10000 
range is what I want for mainline, just in case.

> Your increment won't work there either, so that's not valid for or against.
> And no, it won't work against "mainline", in general, which was my original
> point.

Then do a better job at proving it, rather than saying "it won't work".

>>> Given that there is no versioning scheme that can help us
>>> identify for sure whether libusbx came from a fork or from mainline,
>>> especially if git is not used on the fork, you still seem adamant to
>>> want to force us to care about forks for some weird reason.

> Michael Plante wrote:
>>> It can tell us for sure that it came from a fork,
>>> but can't tell us for sure that it came from mainline.
>
> Sorry, I'd better correct that.  There are also situations where it can't
> tell us the former.  My point still stands.

I see you dropped the "for sure" which is wise. There isn't a solution 
that can tell us whether something came from a fork or not. There are 
way too many scenarios where a fork will generate a version conflict 
with mainline.

> That is still helpful, because most of the time
> that it does tell us it came from mainline, it will be true.

Ever heard about "false sense of security".
Because this is EXACTLY what you are advocating.

You want us to go with a solution that will tell us "most of the time" 
if something came from a fork. Except, we will never be 100% sure it is.

Wanna take a bet? As a maintainer, I sure won't, ergo, even if we had a 
99% chance of figuring out whether a specific libusbx version came from 
a fork or not, I still want to make sure I'm not gonna miss the 1%. 
Ergo, if I can't reproduce the issue with the version fed, I'm going to 
ask whether this was from mainline or from a fork, so whether we go with 
your allegedly "better" solution or not, it won't change one thing with 
regards to trying to identify whether a fork is at hand or not.

> Your increment
> method will do none of the above.

I provided ample details of what I have in mind, as well as how it can 
solve the problems that are solvable. You have only been dangling the 
prospect of an allegedly "better" solution, with which I pointed many 
flaws, and with no concrete implementation details whatsoever.

Please come back when you have a proposal that everybody can compare. 
Hopefully, it will also help you identify some of the problems that you 
don't appear to have considered yet.

Regards,

/Pete