[Libusbx-devel] Keeping the 1.0.9rc3 tag

[Pete Batard]

On 2012.03.28 13:35, Michael Plante wrote:
> Ok, so you plan to
> allocate a ton of offsets.  You say 65.  Maybe that's enough.

Because you seriously think that we want to handle more than 20 
semi-official branches at anyone time?

> I.e., people who have modified it know where they got it from.

Yes, usually, and the two cases of interest to us with regards to people 
who have modified the library is:
1.

> That's what I said.  You can't put the hash in the version number.  So what?
> Put it elsewhere.

Hi, I'm using TortoiseGit and MSVC. Please come back when you can 
explain how I'm going to do that.

Also, It's not an either/or. We can go with the solution I advocate, 
and, if you really feel like it, we can add an extra field for the hash 
in the versioning we'll report in libusb_get_version() once you or 
somebody else provide a solution that can do so.

> With manual coordination of offsets between developers, as you just
> described above, it can work.

Again, the only developers we need to concern ourselves with are the 
ones that are affiliated with us. Even if successful, there won't be 
that many. Everybody else will be assigned the same offset, because 
versioning of their *custom* library is not something that we need to 
solve, since there is no sure way we can produce something that will 
keep everybody and their custom usage happy (especially if they don't 
use git as their VCS).

Please don't try to make us address issues that aren't relevant to us.

> It's still an unnecessary pain

For you.

> and people
> have to actually RECOGNIZE that it branched, which is not always obvious.

Exactly. No matter how careful, there's no sure way of recognizing or 
making people recognize that something branched. So we go with freezout, 
hope that people will TELL us if they forked in the scope that is 
relevant to us (people coming to this list with an issue) or if not, 
either reproduce the issue from the version they report in master (or a 
semi-official branch we will recognize if the version has an offset) or 
if not, go back and ask them if they aren't using a branch by any chance.

But at least, we can almost always get someone to report a version that 
is relevant to us (unless they went out of their way to fake a version), 
and in the case of a DLL, they don't even have to run a program, they 
can just right click on the DLL.

> Additionally, if anyone disagrees about who gets what offset (say they go
> offline to develop for a few days)

Same unconvincing argument as "65 will not be enough". "If sourceforge 
goes down, what will we do?", "If the earth explodes tomorrow, who will 
continue libusbx development?". Or are we going to start to disagree 
over how a number gets assigned? It's the same as with sample names: one 
person proposes it (or does it) and everybody follows. People can rename 
the samples if they disagree (or try to see if others feel they should 
be changed), but they're not going to go very far if they go for 
something without concerting, unless they are alone at the helm.

In a democracy, whoever is not there to vote loses their voice.

> all those commits have to be amended or it fails.

More unconvincing plea.

> Why not let it get handled automatically?

Because you're still nowhere near of proposing even the shadow of a 
solution that can actually leverage the git hash and work, and because 
hashes are for computers, distances (or rather coordinates converted as 
a distance) are for people. As a maintainer, I hope that I at least get 
some choice over what I IDENTIFY will make my job easier (figuring out 
how commits relate in the branches I need to worry about), rather than 
go with something that makes it harder, just so someone may (because I'd 
like to see a proposal) get their versioning sorted in a branch that, as 
a maintainer, I should never have to care about.

If people branch and want to reuse our versioning, we give them a 
specific offset. If they apply it, then the problem of fidning out 
whether someone carried out modifications in their library when they 
come to us is solved just as well as it would with a hash, because all 
we need to know is that they have forked. We do not need to know 
anything more, especially we're not going to go troubleshoot someone's 
custom git tree if they provide us with the location of their commit. 
I'd like to help people, but I also know that there is such thing as 
limiting the scope of what you want to take one to make a project 
successful, which means stating the harsh reality that if you have 
forked, and we can't reproduce the issue in mainline, you are on your own.

Now, if people branch and don't reuse our versioning (because they use a 
different VCS, or because they chose to, or because they didn't pay 
attention to what we stated in the pre-commit hook) then we have a 
problem. But this is a problem no solution can solve. The only thing we 
can do is try to add some additional safety, such as, in the case 
someone uses git, we can try to somehow try to add a git commit ID, 
which if we can, I wouldn't mind doing, but which looks very difficult 
to do as we can't use a pre-commit hook and we have all the 
git-oblivious platforms to consider

> Risk vs cost.

EXACTLY what I am considering and that you don't, since you're coming 
without the cost of your solution, as you have nothing more than an 
ethereal "wouldn't it be nice" one.

> Your percentages are unconvincing.

You may not be convinced, but at least I have a proposal. If you want 
something utterly unconvincing, how about a non material proposal.

Let me give you in on a little maintainer's secret. Between a proposal, 
and wind, the proposal always wins. It's not enough to shoot down a 
proposal if you don't have a concrete alternative to provide, that 
everybody can judge the merits of. You have about 2 weeks to come up 
with one. I'll be waiting.

Regards,

/Pete