4 new commits in master

[Pete Batard]

On 2012.04.14 22:04, Michael Plante wrote:
> Pete Batard wrote:
>>> I pointed to examples of forks that are divisive (and I could add more.
>>> Hudson vs Jenkins, JavaScript vs JScript, that had to be reconciled to
>>> great effort, though not exactly Open Source, etc.) as a proof that
>>> forks are divisive by nature and require people to take side. To that,
>>> you basically answered "No - not us". And you ask me to justify further?
>
> Yes, I do.  I am unfamiliar with those new cases you've added, although I
> have at least used kde and gnome.  I chose which one I liked, but I've never
> coded for either.  So the analogy falls completely flat for me.

It shouldn't. You picked one project and disregarded the other. This is 
exactly the point I was trying to prove. Unless you want to pretend 
that, while end-users ignore what the competing project does past their 
choice (they may peek from time to time, but for a healthy project, a 
switch is unlikely), the same should not apply for contributors and 
developers, who instead are supposed to strive working for 2 competing 
projects at once. Apart from a few exceptions, I'm not aware of this 
being the case. Usually, when a fork occurs, a nucleus of developers 
secede from the original project to pursue their own endeavours. These 
tend to not hang around the original project and also tend to not 
concern themselves with whatever occurs there, aside from a competitive 
outlook (which would be the similar to one from a FLOSS project 
competing with proprietary and having little contact with the 
proprietary developers).

They just do their own thing.

>>> I wouldn't call looking at what the competition does and
>>> borrowing/stealing their ideas "working with".
>
> I do.

Yes, you're free to distort words to express what you would like.

Working with implies 2 way exchange, at least in the definition I use, 
and which is the one I would expect most people to use too. And 2 way 
exchange between competing entities doesn't seem to be the norm, at 
least with the forked projects I know.

>>>>>> Unsubscribe or not doesn't matter.
>>>>
>>>> Then start a new thread, or at least post it somewhere else within the
> thread.  Don't reply to that point -- read in that context that was
> misleading.
>>>
>>> I don't get what you mean.
>
> It was very deep quoting and it is trimmed now.  It was there in its
> entirety for awhile.  You can go back and reread it or not.

Well it's the start a new thread I don't get. Start a new thread on what 
topic? Where? A thread in a post (whatever that is)? A new thread? And 
what's the context that was misleading? Or are you talking about 
starting a thread in libusb-devel since we were talking about being able 
to post there?

I was asking for clarification on what you mean, because I have no idea 
what you are talking about at this stage, and you're only referring to 
it as "it".

> My point is the comparison is silly because you are claiming that Hans
> Reiser cannot communicate with the Linux community, directly or indirectly.
> (I am unfamiliar with the rules he operates under, so I will take your word
> for it.)  Peter at least has the indirect option open.

Then you missed the point. The point was not about communication, but 
that one shouldn't brush aside a very damaging act that a person has 
committed if they happen to have redeeming points that you would like to 
take advantage of.

Maybe it was a bad example, since whatever people do outside of the 
technological world has little impact on a technological project. 
However, in our case, Peter has been acting very damagingly on a 
technological project, and yet you seem to be ready to brush that fact 
aside and continue working with him on the very same project. To me, it 
just doesn't make sense.

The only logical explanation I can come up with is that you do not see 
his maintainer activities (or lack thereof) as that damaging compared to 
his other contributions, which is what I was trying to illustrate. In 
the balance of what's right and what's wrong (as seen by a supposedly 
impartial person prompted with the task of passing judgement), murder 
(if established), is supposed weight a bit more than creating a file 
system, no matter how good that file system may be.

Likewise, in the balance of what's right and what's wrong for libusb, 
one should consider that the continuing killing a project and forcing it 
to fork off is a lot more damaging than whatever help Peter has or will 
ever be able to provide. Simple mathematics tell us that it has an 
impact on a lot more people, as there is a larger number of users of 
libusb (or potential users of libusb) impacted by his disastrous 
maintenance activities than whatever number of users or contributors he 
may ever provide help to.

If you don't see it that way, then I don't see why you're bothering with 
this fork at all, because I can only conclude that you consider that 
Peter being a bad maintainer is not of that great a concern for libusb 
*users*, or at least not as long as he is doing other good deeds there, 
and therefore that it's OK to try to continue working with him even has 
he has refused to acknowledge any of his disastrous actions. To reuse 
the bad Hans Reiser analogy, it'd be like strongly suspecting a murder 
case, but not alerting the authorities onto it (whereas it is your duty 
to do so), because you would prefer if further ReiserFS occured.

On that matter, I don't think neutrality flies, and I actually find it 
quite amazing that people who are supposed to care about libusb still do 
not see the very crucial need to take a side. Not picking a side means 
that users will pay the price of having to contend with a poorly 
maintained project, such as continuing to encounter bugs that have been 
fixed but never made it to a release, or very desirable features like 
hotplug, that are unlikely to ever be implemented.

Regards,

/Pete