Re: [Openocd-development] Peter Stuge is now an OpenOCD maintainer

[Pete Batard]

On 2011.06.10 16:12, Peter Stuge wrote:
> Pete Batard wrote:
>> Peter's involvement as a maintainer has mostly been limited to
>> rebuilding his personal (i.e. non official) git branch every 3
>> months or so.
>
> If this is really how things look that is bad.

It is. Heck, I only have to quote you on being "confident that a release
before 2011 (was) achievable", or Segher dismissing people like myself
or Xiaofan as "naysayer" when we shared our pessimistic outlook about
that statement, to make you realize that, by all accounts, even the
libusb maintainer and "acting maintainer" should agree that the
situation is bad, since they have arguably overextended their expected
maximum release deadline by at least 6 months now...

It won't make our users, some how whom have probably been waiting for
years now for patches to be integrated in official, any good to find out
how great your personal git repo is. As you have stated many times in
the past, our focus should be with providing our users with libusb
packages that are attractive to them for their development. Fetching
source from an ever rebased personal git repo, to be able to apply
months (if not years) old _small_ fixes isn't.

> I like to rebase my libusb repo, which makes it difficult to see if
> the last change was a small commit message fix or ten hours of
> analysis and code rework. Suggestions to make work more visible are
> most welcome.

Then, as many people have stated, please do this work in mainline, in
bitesize operations, and please accept that applying corrective commits
in mainline is not the end of the world. In the schoolyard of OSS
projects, nobody is going to point the finger at us from not getting
everything right at once, especially when we know that we are way behind
schedule on a release.

It has also been suggested to you to try to break down the long awaited
next release into small critical patches first (some of which, may I
remind you, have been integrated into the mainline git for more than a
year), and then move to more consequent items, but you have been adamant
about trying to do everything at once.

When exactly are you going to realize that the approach you have been
trying to follow is excessively detrimental to libusb users? If you have
doubts about that statement, I suggest you re-read the numerous
complaints on the libusb mailing-list. Myself and others have been
trying to point that out to you for the best part of one year now, but
you still seem to be acting like everything is OK.
Sorry to break it down to you, but it definitely isn't, so please come
back to earth already, and do something that will actually benefit
libusb users.

> I've always communicated that my libusb repo is the proposed merge
> queue for libusb.git.

Yes, and that is not the problem. Having a merge queue with loads of
commits, that never gets merged, or a mainline git tree with enough
patches to warrant a release, that doesn't see one for months, is.

> I still offer to add libusb repos for anyone and everyone who wants
> one, since even before I was maintainer, sadly without many takers. :\

Yes, let's add more individual repos. Exactly what we need here... I've
had one, maybe 2 users for my 9 months old hotplug repo, despite the
fact that this is a feature everybody wants, so I can tell you: adding
more libusb repos does not help. What we need are timely releases of
libusb, with the patches that have been submitted and validated for months.

>> action needs to be taken by the maintainer...
>
> I've found that our views often differ fundamentally.

Unfortunately for you, I am only one of _many_ voicing concerns about
your approach to libusb maintenance. I'm afraid it has long ceased to be
a matter of conflicting views between two individuals... Have you asked
Segher, Michael, Orin, Graeme or others what they thought about your
release schedule lately?

> The perception of maintainer is curious.

Even more curious is the _lack_ of perception of a single maintainer,
when _many_ project users have been complaining about the lack of
releases...

> This reinforces my belief that the *what* is more important than the
> *how much*, ie. level of involvement.

I'll take a maintainer that has to be shown the ropes, but that is
effectively able to contribute time to a project, over a maintainer that
supposedly knows the ropes but can't, any time.

If Linus came over and said he'd agree to be a libusb maintainer
provided he can limit his contributions to 10 hours every 6 months,
while somebody else came and said that, while he isn't that experienced,
he is motivated enough and can devote the required amount of time to the
project, then knowing full well that we have enough good people in our
project to look over any maintainer's shoulders, I'd vote for the latter.

>> condemning the libusb project to a slow death...
>
>> Peter being able to afford the level of involvement that is
>> expected from a project maintainer has really been at the crux
>
> Maybe the expectations are also a factor.

Then PLEASE step down. If you can't be involved, then leave the position
to people who will. If you want to exert control, but can't be bothered
to spend the time required to exert the kind of control you want whilst
still satisfying users, your only option is to peacefully step down.

> If noone works on code then a project is inactive. At least you, I,
> Sean and Hans have worked on the libusb code over the last month, so
> I think libusb is still active, actually maybe more widely active
> than ever.

Someday you'll have to explain to us how a project that NEVER releases
is active. Contributors are coding for users at large, not for a select
group of people.

Regards,

/Pete

PS: Moving this thread to libusb-devel and CC'ing openocd-development,
since this discussion is not directly related to OpenOCD.

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Michael Schwingen]

Am 06/10/2011 07:00 PM, schrieb Pete Batard:
> It is. Heck, I only have to quote you on being "confident that a
> release before 2011 (was) achievable", or Segher dismissing people
> like myself or Xiaofan as "naysayer" when we shared our pessimistic
> outlook about that statement, to make you realize that, by all
> accounts, even the libusb maintainer and "acting maintainer" should
> agree that the situation is bad, since they have arguably overextended
> their expected maximum release deadline by at least 6 months now...
[...]

Could you please take this off openocd-devel?

The whole thread has long lost all relevance regarding OpenOCD development.

cu
Michael


------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Fri, Jun 10, 2011 at 11:12 PM, Peter Stuge <[hidden email]> wrote:

> Pete Batard wrote:
>> Peter's involvement as a maintainer has mostly been limited to
>> rebuilding his personal (i.e. non official) git branch every 3
>> months or so.
>
> If this is really how things look that is bad.
>
> I like to rebase my libusb repo, which makes it difficult to see if
> the last change was a small commit message fix or ten hours of
> analysis and code rework. Suggestions to make work more visible are
> most welcome.
>
> I've always communicated that my libusb repo is the proposed merge
> queue for libusb.git. Keeping it there was probably a mistake, it
> will become a testing branch in libusb.git instead, so it's more
> visible.
>
> I still offer to add libusb repos for anyone and everyone who wants
> one, since even before I was maintainer, sadly without many takers. :\
>
>
>> action needs to be taken by the maintainer...
>
> I've found that our views often differ fundamentally. I think this
> may be one more instance of that. The perception of maintainer is
> curious.
>
> I haven't contributed in great numbers to OpenOCD, yet I was still
> asked to be a maintainer.
>
> I explained that I don't have much time and that I will not likely
> be able to increase my level of contribution to OpenOCD, but Øyvind
> and Spencer were still interested.
>
> This reinforces my belief that the *what* is more important than the
> *how much*, ie. level of involvement.
>
> I am of course honored by Øyvind and Spencer having considered me,
> and I will continue to do what I have done so far; try to help when
> I can.

I have no issues of you being made a OpenOCD maintainer
and OpenOCD anyway has quite a few maintainers and will
not die if one of them is not actively participating.

The issue is that you are the only active libusb maintainer
now that Daniel Drake is kind of off the project. And your
way of handling the project has done great damage to the
progress of the project.

So please considering relinquishing your desire to tightly control
the libusb project since you do not have the time to do this.

>> condemning the libusb project to a slow death...
>
>> Peter being able to afford the level of involvement that is
>> expected from a project maintainer has really been at the crux
>
> Maybe the expectations are also a factor.
>
> If noone works on code then a project is inactive. At least you, I,
> Sean and Hans have worked on the libusb code over the last month, so
> I think libusb is still active, actually maybe more widely active
> than ever.
>
>
> To finally come back on topic :) I also don't think that OpenOCD is
> anywheree near dying. There's a lot of active development going on,
> and I'm excited to continue to be a part of it!
>
>
> Many thanks, and kind regards

All in all, please consider the previous proposal I made here for
libusb project. The other proposal is to fork the project which
quite some community members do not want to go to.

http://libusb.6.n5.nabble.com/libusb-project-what-is-the-way-forward-tp3401932p4304670.html
"First proposal: to have someone as release manager
(project manager) overseeing the 1.0.9 release, this
person can not be Peter. Or have someone taking
over from Peter as the lead admin of the project. My
proposal is have Peter as the Linux platform maintainer,
Pete as the Windows platform maintainer and Nathan
as the Mac OS X maintainer. And then Daniel (if he
has the time) and the new project manager to take
charge of the core and resolve the differences between
platform maintainers."



--
Xiaofan

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard]

On 2011.06.11 02:41, Xiaofan Chen wrote:
> The issue is that you are the only active libusb maintainer
> now that Daniel Drake is kind of off the project. And your
> way of handling the project has done great damage to the
> progress of the project.
>
> So please considering relinquishing your desire to tightly control
> the libusb project since you do not have the time to do this.

Let's make this a lot more simpler and direct for Peter.

Peter, do you agree that libusb would benefit for additional maintainers
(such as Segher), with the same kind of privileges as you have (such as
being able to issue releases), yes or no?

If not, especially after you re-stated the involvement you were able to
provide to libusb was quite constrained in time, why?



I'll also add these bonus questions for my own sake, though I don't have
much illusion about them.

Once again, how comes you find time for lesser matters in the coreboot
or OpenOCD mailing lists (such as lecturing newcomers [1]), matters that
other people could obviously step in to perform, yet continue to pretend
that your non involvement in libusb is a matter of constraint rather
than choice? Especially how comes very critical e-mails about the
current state of libusb, such as one where a frequent contributor
declares that the project you are in charge is "one the most
dishevelled" they have ever seen [2], don't even elicit the Customer
Relationship 101 reply: "I'm sorry you see it that way, but rest assured
that we're working on improving the situation"? Or is it that, even as
the sole active head of the project, you can only dismiss criticism of
your approach as the work of trolls?

Also, do you also have any comments on the fact that, when we went
around this mailing list to find out who here thought you were still
doing a proper job as a libusb maintainer, not a single person stepped
in to your defence [3]? Or should we perhaps conduct our own Jasmin
revolution for you to finally get the message?


Regards,

/Pete


[1] http://www.coreboot.org/pipermail/coreboot/2011-June/065326.html
[2] http://marc.info/?l=libusb-devel&m=130515534508511&w=2
[3] http://marc.info/?l=libusb-devel&m=130458996525727&w=2


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Pete Batard wrote:
> >> Peter's involvement as a maintainer has mostly been limited to
> >> rebuilding his personal (i.e. non official) git branch every 3
> >> months or so.
> >
> > If this is really how things look that is bad.
>
> It is. .. should agree that the situation is bad, since they have
> arguably overextended their expected maximum release deadline by
> at least 6 months now...

You misunderstood. It is bad if it looks as you describe, because the
reality is quite different from your description.


> applying corrective commits in mainline is not the end of the world.

There is no excuse to produce bad open source software.

Hasty commits that need to be corrected are bad. They create extra
work in the future and they lead to low code quality.

There is no excuse not to do better. This is why I also find review
so important; it can catch many of these things early.

Of course sometimes one can't know that something needs to be
corrected until the need arises, but many things can be caught by
analysis and discussion before implementation, and review after
initial implementation is done.

The workflow that you advocate is of course fine to use locally, but
before publishing code from that repo those related commits must be
combined (git rebase -i) so that only meaningful smart and finished
commits are added to the public repo.


> way behind schedule

There is no schedule. Release comes when it does. I also want it long
ago. The more people that work on it, the faster it comes.


> It has also been suggested to you to try to break down the long
> awaited next release into small critical patches first

It's not completely clear to me what you mean, but maybe you mean to
add only very few further fixes beyond what is already in libusb.git
and/or the merge queue.

I don't think it is meaningful to make a release without taking care
of most tickets, in particular those with patches. Someone needs to
process those patches. As far as I know I was, and I still am, the
only one working on processing patches in the open tickets. Hans
asked for concrete tasks to help out with so I sent him a list of
tickets I have yet to analyze.

It is of course nothing new that anyone who can help out can simply
go through all open tickets which have no fix in -stuge master yet.


> When exactly are you going to realize that the approach you have
> been trying to follow is excessively detrimental to libusb users?

When exactly are you going to realize that the project actually does
not have any obligations to users or others? Please see the license.

If the project is not yet useful for users then they can, should and
will hopefully check back at a later time, and then the code might
suit them better. Or they can talk to us, and help turn the code into
what they need. Whichever works best for them.


> you still seem to be acting like everything is OK.

I think the situation is far from ideal. I have repeatedly said that
I ideally just want to have to glance over patches before adding them
to libusb.git. This is however not the reality, because there isn't
much review going on. So in reality I analyze, review and rework many
patches that noone else seems to have looked at, then I discover new
bugs while doing so and fix those bugs too.


> adding more libusb repos does not help.

It's the only thing that *can* help, if all existing repos for
whatever reason can not be helpful at the moment.

A repo is the tool needed for someone to work on the code.

It's actually the *only* tool needed. And while it doesn't have to be
a repo I am involved in creating, I think (as I wrote on the openocd
list) it's a good idea to gather project activity in one place.


> What we need are timely releases of libusb

Releases are on the other hand not at all needed for anyone to work
on the project. Please keep track of want and need. I also want a
release. But we don't need a release to make a release. We need time
spent on the project to make a release, and exactly what to spend
time on has not changed.

The tasks that remain are to take care of as many tickets as is
sensible, and apply Hans' patchset. After that I want to make a rc1.


> Have you asked Segher, Michael, Orin, Graeme or others what they
> thought about your release schedule lately?

Please forget about schedule. There is no such thing.

Would I like rc1 to be out already? Sure! Has enough work been
contributed to get it done? Obviously not yet.

Probably because life is not only about open source projects, and
especially people who are competent to contribute significantly
tend to be very busy. I think this is true for you too.

libusb is also not the only way to do userspace USB programming, and
it never was. You reason as if libusb code is a hard requirement for
some, but actually libusb can never be more than a convenience. It is
made available under (IMO) simple license terms, where responsibility
(really) lies completely with the user. I find this fundamental in
open source. Do you disagree?

Of course I also want to try to provide users with first class
service, but reality is that there doesn't seem to be enough
resources available to do so, at least not yet. I don't know how
long you've followed libusb development before you started
contributing, but it has been like that (fairly few contributors) for
as long as I can remember. Of course that says nothing about the
future, and as I already wrote I think that libusb activity is
generally increasing.

Remember that the available resources have nothing to do with me or
any other maintainer. It is the measure of total time spent on the
project by all contributors combined, not a measure of time spent by
a maintainer.


> > This reinforces my belief that the *what* is more important than the
> > *how much*, ie. level of involvement.
>
> I'll take a maintainer that has to be shown the ropes, but that is
> effectively able to contribute time to a project, over a maintainer
> that supposedly knows the ropes but can't, any time.

That makes no sense. New contributors are "shown the ropes", not
maintainers.

You also seem to not know how much time I contribute to libusb. I
agree completely that the project activity is not visible enough. I
don't have a concrete idea for how to increase visibility, and I
welcome all suggestions. (Bumping a version number every month is no
solution.) As you may know, the coreboot project just started using
gerrit for managing code review, and gerrit does provide more
visibility for ongoing work. Something that is particularly useful
when using git is that gerrit can track a logical change even if the
commit id changes. I think it might be a good idea to use gerrit also
in libusb in the future. Comments on that idea are very welcome.


> If Linus came over and said he'd agree to be a libusb maintainer
> provided he can limit his contributions to 10 hours every 6 months,
> while somebody else came and said that, while he isn't that experienced,
> he is motivated enough and can devote the required amount of time to the
> project, then knowing full well that we have enough good people in our
> project to look over any maintainer's shoulders, I'd vote for the latter.

Nothing is hindering anyone from devoting time to the project. In
particular I am not holding anyone back. On the contrary I try to
encourage it and facilitate it. The fixation on maintainer is strange
to me. There is no point. I expect people to always do their best,
and contribute if they can. When those contributions fit with what
maintainers seek, new people become maintainers. That happened to me
twice now, after I simply try to help when I can, even if all I can
manage is to write a few emails with comments, or some small patches.
A maintainer is no different from another contributor except that the
maintainer has slightly more of a say.


> >> condemning the libusb project to a slow death...
> >
> >> Peter being able to afford the level of involvement that is
> >> expected from a project maintainer has really been at the crux
> >
> > Maybe the expectations are also a factor.
>
> Then PLEASE step down.

Expectations must be realistic. See above on maintainers. It's not
realistic to expect that a maintainer (me or anyone else) does the
work for you, just as it's not realistic to expect that from another
contributor.

As I've expressed several times I do actually offer to do that work,
since I think it's important to take care of all contributions, but I
do not give a guarantee about *when* I could do it, and I welcome
someone else to do it before I can get to it very much.


> If you can't be involved, then leave the position to people who
> will.

Anyone can and should contribute as if they were already maintainers.
If they need to be made maintainer before they start contributing then
they are not likely the right kind of contributor that should be made
a maintainer. Does that make sense to you?


> If you want to exert control,

I never said that I do, and I do not want that at all. What I *do*
want is for commits to be reviewed by someone qualified before they
are committed to libusb.git. I absolutely can not believe that I
would be the only one qualified to do review, that thought is just
absurd.


> satisfying users

See above on license.

And, if you see that the project does not satisfy users and have time
to spare, why not work toward that then?


> > If noone works on code then a project is inactive.
>
> Someday you'll have to explain to us how a project that NEVER
> releases is active.

Activity = anything happens.

Activity != releases happen.

You and Xiaofan seem to agree with me that OpenOCD is an active
project. As you know, OpenOCD has gone longer than libusb without
a release.


> PS: Moving this thread to libusb-devel and CC'ing openocd-development,
> since this discussion is not directly related to OpenOCD.

Thanks!


Xiaofan Chen wrote:
> your way of handling the project has done great damage to the
> progress of the project.

What is progress? The number of commits, regardless of code quality?
(I'm not even considering patch quality.)

Personally, I think progress is really only relevant when quality
increases. Maybe this concept is foreign for contemporary open source
programmers, but I don't think so.


> So please considering relinquishing your desire to tightly control
> the libusb project since you do not have the time to do this.

I have no desire to control the project. I have strong desire for
code review, but I have zero desire to do it myself beyond educating
myself and having fun. It is all about the code. It's simply
unacceptable for countless reasons to commit patches to any codebase
until they are well formatted, well explained and well understood.

As I have expressed many times: It is absolutely not neccessary that
*I* do these things that I want done before relese. Pete, Hans and
many of the contributors who have posted patches in Trac are perfect
examples of how to help out significantly; make commits for
integration that are easy to review and easy to access.


> to have someone as release manager (project manager) overseeing the
> 1.0.9 release

What would that person do concretely? And why would they need to be
appointed by me or anyone else before they would do it? Why wouldn't
they just do it, if they have time to contribute? Titles are very
important in some corporate cultures, but I expect more than that
from open source projects. I expect that everyone contributes what
they can as they can, even if that means only a little.

And I see that this is what happens! There are more contributors in
Trac and on the mailing list than maybe ever before. Some
contributions need further work, others are ready to go and are
applied as-is.

Yes, a release would be nice. No, I don't think we the libusb
community of contributors have been able to catch up with received
contributions just yet. (But almost!) Yes, I think it is important
not to skip too many tickets.


//Peter

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Pete Batard wrote:
> Peter, do you agree that libusb would benefit for additional maintainers
> (such as Segher), with the same kind of privileges as you have (such as
> being able to issue releases), yes or no?

Not really, no.


> If not, especially after you re-stated the involvement you were able to
> provide to libusb was quite constrained in time, why?

Because tagging a release is not what takes time. See previous email.


> how comes you find time for lesser matters

How I prioritize is quite frankly none of your business, since you
are not a customer of mine, but someone I work together with in a
setting where we both contribute what we can.


> Especially how comes very critical e-mails about the current state
> of libusb, such as one where a frequent contributor declares that
> the project you are in charge is "one the most dishevelled" they
> have ever seen [2], don't even elicit the Customer Relationship 101
> reply

Indeed; why is there no reply? Everyone else who is on the list is
also a contributor and could also have sent one.


> when we went around this mailing list to find out who here thought
> you were still doing a proper job as a libusb maintainer,

This was not likely the most constructive question you could have
asked. It feels good to bash on someone else when you're unhappy,
but keeping focus on the project and how to make it work would be
more useful.

I'll continue doing what I think is needed for rc1. Hopefully someone
will also jump in and help out. Once the release is actually done I
think it's a good idea to consider the project process together. It's
obvious that neither you nor I find the current process to work well.


//Peter

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard]

[For anybody else but Peter, I apologize for the wall of text. I'm still
hoping that some of the points I make below will actually reach him...]

On 2011.06.12 16:17, Peter Stuge wrote:
>>> If this is really how things look that is bad.
>>
>> It is. .. should agree that the situation is bad, since they have
>> arguably overextended their expected maximum release deadline by
>> at least 6 months now...
>
> You misunderstood. It is bad if it looks as you describe, because the
> reality is quite different from your description.

And who gets to decide on the reality? You?

Just in case you need a reminder, there are an awful lot of people on
this list who think you have lost touch with "reality" if you don't
understand that the absence of a release, as repeatedly asked by our
users, is very detrimental to the health of libusb. If you believe that
libusb is in maintenance mode and therefore can satisfy itself with very
sparse releases, I believe you are very much mistaken. New developments
have been requested and are waiting to be addressed.

And if you want to go that way, then I too will say, as I am entitled
to, "the reality is quite different from your description". So now what?
Are you the one to provide arbitration on a statement that you obviously
cannot be objective about?

>> applying corrective commits in mainline is not the end of the world.
>
> There is no excuse to produce bad open source software.

As I've repeatedly asked you in the past, care to point out where
exactly in the various git trees we have, exists this "bad" open source
software?

Which of the latest commits from mainline or elsewhere are "bad"?

Dangling ethereal ghosts with no substance doesn't help your case one
bit. Please point to actual examples.

> Hasty commits that need to be corrected are bad.

Once more, your subjective aversion to RERO makes you equate early with
"hasty", which is a debate we've been having over and over on this list.
Care to point out to commits (other than yours) that qualify as "hasty"?
The only hasty commit I remember seeing was the one you produced for HID
removal, which you shoved upon everybody without any form of prior
consultation (where was the discussion? Where was the review?).

I can't help of course but find it deeply ironic that what you are
stating below is in effect, in direct contradiction with prior examples
of your work...

> They create extra
> work in the future and they lead to low code quality.

Please, once again, give us explicit examples from previous libusb
commits. Or just shut up about the spectre of "low code quality" (which
apparently you are the only one enlightened enough to decide upon) that
you have been dangling around over and over already.

> There is no excuse not to do better. This is why I also find review
> so important; it can catch many of these things early.

I believe reviews do happen. When patches are submitted to the list,
they are being reviewed, proof being that we are usually getting
comments when people pick things that they think can be improved. When
patches are not being commented on for some time, then they have to be
assumed good. Now if you want an explicit "acked by", then please state
so, and the list will be happy to oblige. It looks to me like, from your
endeavours in other projects that have historically used different
processes, you have a gross misconception of how people on this list
proceed with patch reviews.

> Of course sometimes one can't know that something needs to be
> corrected until the need arises, but many things can be caught by
> analysis and discussion before implementation

For the record, we've had many discussions where we eventually agreed on
an approach (eg: logging callback), that led to nothing with regards to
a patch implementation BECAUSE there is just too much backlog to be
handled. This is also one of the reason we need a release: No matter
what you're gonna say about creating more branches for new developments,
unless existing stuff gets out of the way, it doesn't make sense for
anyone sensible to add more.

> and review after initial implementation is done.

How long should that review take then? And how many times should one
resubmit a patch for you to consider it reviewed? Again, please state if
you need explicit acks.

> The workflow that you advocate is of course fine to use locally

Says you. There are many examples of OSS projects, that use it to great
effect. If you think your approach is the only way, please take a look
at stgt [1], which is an example I pointed to in the past (I am
confident I can dig more if needed). I think it is comparable in size
with libusb at the moment, yet it has seen about 7 or 8 releases over
one year, and it definitely does not seem to be facing the same amount
of issues. If you want to see a maintainer doing proper work, you really
ought to have a look at [2], as I believe what occurs on stgt is exactly
what people expect from an OSS maintainer on a project our size (i.e.
responsiveness, flexibility, _AND_ RERO)

 > but
> before publishing code from that repo those related commits must be
> combined (git rebase -i) so that only meaningful smart and finished
> commits are added to the public repo.

"meaningful", "smart", "finished". Again, as decided only by you apparently.

>> way behind schedule
>
> There is no schedule.

Yes. Only maintainers who at one stage say they are confident for a
release before a specific deadline, and then 6 months after they missed
the deadline they were aiming at, use the "no schedule" excuse to
justify their failure.

> Release comes when it does.

Translation: "I know better than our users what our users need". I'll
get to that in my next mail.

> The more people that work on it, the faster it comes.

So how about officially adding new maintainers? Oh wait, you don't want
that. How on earth can you justify the argument above? Maintainers are
the people explicitly tasked to work on releases.

>> It has also been suggested to you to try to break down the long
>> awaited next release into small critical patches first
>
> It's not completely clear to me what you mean, but maybe you mean to
> add only very few further fixes beyond what is already in libusb.git
> and/or the merge queue.

Yes.

> I don't think it is meaningful to make a release without taking care
> of most tickets

If you went around, you'd be surprised with how many people here think
it is. But of course, you appear to know better than us, common
contributors.

> in particular those with patches. Someone needs to
> process those patches. As far as I know I was, and I still am, the
> only one working on processing patches in the open tickets.

Well yeah: because you are the maintainer. That's your job!
If you want more people to work on processing patches, then agree to add
more maintainers.

> It is of course nothing new that anyone who can help out can simply
> go through all open tickets which have no fix in -stuge master yet.

Or it is also nothing new that we don't have to do everything at once.
I'm afraid you seem the only one here who appears to think it is. This
is also quite different from the "not all tickets" argument you make at
the end of your mail.

>> When exactly are you going to realize that the approach you have
>> been trying to follow is excessively detrimental to libusb users?
>
> When exactly are you going to realize that the project actually does
> not have any obligations to users or others? Please see the license.

When exactly are you going to realize that saying "fuck you!" to our
users, as you have just done again, is the shortest way to ensure that
the project dies (for lack of users) and is not helping one bit?

You may not see it that way (and I think this is the one part with your
approach that is very damaging), but as a maintainer, your first moral
obligation IS to the users of the projects, not yourself or the code. If
you only have scorn for user requests, such as a release that integrates
the patches currently available, because you just happen to "know
better", then you are clearly missing the one quality that is required
from a proper maintainer. And I'm afraid We are seeing the results of
that right now.

> If the project is not yet useful for users then they can, should and
> will hopefully check back at a later time

Great way to endear libusb to people. "We could easily produce the
release you asked for, but we won't for one year or two. Hope you'll
still be interested in it for your development then..."

Seriously, do you ever stop to think about our users? Or do you only
consider them as a minor annoyance on the path of completing _your_
great vision. Development is first and foremost a collaborative process
between what users want and what developers can provide. Everything else
is secondary. Lose track of that at your own peril.

> Or they can talk to us, and help turn the code into
> what they need.

Oh they talked to us alright. They said they needed a release that
includes the patches currently in mainline, because they don't consider
using git (which branch?) suits their needs.

What they need is abundantly clear. Except it's not related to adding
more code, it's related to releasing the code that already exists and is
very much ready for release.

>> you still seem to be acting like everything is OK.
>
> I think the situation is far from ideal. I have repeatedly said that
> I ideally just want to have to glance over patches before adding them
> to libusb.git. This is however not the reality, because there isn't
> much review going on.

I believe there is (I know at least Michael, Segher and I, and probably
Orin, Alan and Tim, try do do our bit - we're just not sending the "ack"
which you seem to be expecting), and even if there wasn't, I think this
is what we expect the bulk of the maintainer work to be.

If you consider that a maintainer should just rubberstamp patches,
whereas I consider that a maintainer's work is to scrutinize what has
been submitted for integration, we very much need to clarify the role
before anything else, and allocate more explicit "maintainers" to ack
paches.

> So in reality I analyze, review and rework many
> patches that noone else seems to have looked at, then I discover new
> bugs while doing so and fix those bugs too.

As is exactly what I expect from a maintainer's job, nothing less.

>> adding more libusb repos does not help.
>
> It's the only thing that *can* help, if all existing repos for
> whatever reason can not be helpful at the moment.
>
> A repo is the tool needed for someone to work on the code.

Except when nobody wants to take on work on new code, primarily for
consideration with regards to our single maintainer (who would then have
to be involved in this additional activity), because of the existing
backlog that needs to be cleared.

Again, adding more repos will not help. I don't believe anybody here
wants to start new developments when we have enough existing ones that
needs to go out of the way.

> It's actually the *only* tool needed. And while it doesn't have to be
> a repo I am involved in creating, I think (as I wrote on the openocd
> list) it's a good idea to gather project activity in one place.

I think the project activity is already gathered well enough in one
place, when any patch is expected to go first to the mailing list.
There's not much to be gained there.

>> What we need are timely releases of libusb
>
> Releases are on the other hand not at all needed for anyone to work
> on the project.

Wrong. Again, people here do not want to contribute to new developments,
because existing one still hasn't been dealt with. Let's take Hans'
getspeed() patch for instance. Proposed in January, and pretty much
acked for ASAP integration by yourself... yet still not integrated.

Do you really believe that Hans, or others, will be willing to work on
new development when they see how long it takes for a single *simple*
patch to go through?

Therefore, releases are very much needed for people to work on a
project: they will not be motivated otherwise, which means they are not
going to stick around on the mailing list, which means less people for
reviewing patches and help you with your work, and lo and behold, the
situation we are experiencing right now. Also see RERO below.

I wouldn't have expected to have to point that one out for you, really.

> Please keep track of want and need. I also want a
> release. But we don't need a release to make a release. We need time
> spent on the project to make a release, and exactly what to spend
> time on has not changed.
>
> The tasks that remain are to take care of as many tickets as is
> sensible

i.e., as I see it, the maintainer's job, especially on project such as
this one where the absence of releases and software activity such as
discussion of new developments that leads to actual code and a patch
proposal, has driven developers and potential reviewers away.

This should be your job, not somebody else's.

If you want it to be somebody else's, then please make it clear on the
list so we can act on that.

>> Have you asked Segher, Michael, Orin, Graeme or others what they
>> thought about your release schedule lately?
>
> Please forget about schedule. There is no such thing.

Allow me to reformulate then (which is what I wanted to write in the
first place anyway): "Have you asked Segher, Michael, Orin, Graeme,
Ludovic, Sean, Hans or others what they thought about your work as a
libusb maintainer so far?"

> Would I like rc1 to be out already? Sure! Has enough work been
> contributed to get it done? Obviously not yet.

Yes, and if, as I believe, you are expecting us to do that work, when
everybody else expects that this task actually falls on the maintainer,
then we have a major issue. The key is communication.

When was the last mail where you asked for help, or patch reviews, or
anything else in your quality of maintainer for that matter? Other
projects seem to have go arounds for the tasks a maintainer wants to see
accomplished. Ours doesn't. I very much see causality here.

(And as an aside: Oh boy, you're also planning to go with an RC? More
delays when everybody is super tired of them already - exactly what we
need. The RC could be the mainline git tree you know, provided it was
updated on regular basis...)

> Probably because life is not only about open source projects, and
> especially people who are competent to contribute significantly
> tend to be very busy. I think this is true for you too.

Which is why having more than a single maintainer can help. But what is
the point you are trying to make here? People are busy, but that doesn't
meant that a handful of competent busy people cannot do the work of a
non-busy one.

> libusb is also not the only way to do userspace USB programming, and
> it never was. You reason as if libusb code is a hard requirement for
> some, but actually libusb can never be more than a convenience.

OK, so you don't see libusb as something developers should seriously be
relying on. Glad we clarified that out. Can we also have it prominently
appear on the wiki, to set the expectations straight?

> It is
> made available under (IMO) simple license terms, where responsibility
> (really) lies completely with the user. I find this fundamental in
> open source. Do you disagree?

As I explained above, I very much do. It is not because we are providing
something "as is" and with "no responsibility whatsoever" that we have
the right to treat users, who want to use our software, as an
inconvenience that we can simply brush off.

You have been involved with OSS long enough to understand that the
statement above is only intented to protect OSS developers from _legal_
liability, but that, at the heart of OSS, lies the desire from a
developer provide software that can compete on the same footing as
proprietary, which very much implies placing users of the software first
(even more so as proprietary tends to forget that). If you want to write
software just for yourself, and consider that ignoring users is OK when
it suits you, then I believe you are missing the most fundamental aspect
of why _other people_ than you chose to contribute to OSS development
such as libusb. The project's aim is not to make the software (or its
maintainer) look good. It's all about providing users with what they
need first and foremost, and that means without assuming that the
developer of the software knows better than the user what they really need.

> Of course I also want to try to provide users with first class
> service, but reality is that there doesn't seem to be enough
> resources available to do so, at least not yet. I don't know how
> long you've followed libusb development before you started
> contributing, but it has been like that (fairly few contributors) for
> as long as I can remember.

Yes, and I can tell you EXACTLY why it's been that way: not following RERO.

Best illustrated by the Linux kernel approach to development from the
get go. But feel free to scorn at that again.

There are excellent analysis of why RERO greatly contributed to make the
Linux kernel what it is today (If you're interested in the history of
Linux, I can't recommend Glyn Moody's "Rebel Code" enough [3], which
covers some of that), and it goes very much like this: When they see
their code officially released, contributors feel valued and eager to
contribute more code, which in turns contributes to the project being
more successful and attracting more contributions.

I firmly believe that the current libusb problems could be solved by
going RERO (Again it's not because I'm advocating RERO that I confuse it
with hasty and would use it more than necessary, no matter what Segher
or others appear to think). And I firmly believe that we have all seen
the results too well of what happens to a project that flat out rejects
RERO when it should very much embrace it. But sure, your experience with
coreboot and OpenOCD leads you to think that you know better than Linus
and many other very respected project admin or maintainers.

Oh, and for the record, I think both coreboot and especially OpenOCD
(which seems to be having some release problems - I believe I have seen
complaints about releases not happening here as well) would benefit for
more RERO (though they seem RERO enough as it is for me, when simple
patches, such as the one I submitted to coreboot's flashrom about one
week ago, get integrated into git mainline in a matter of _DAYS_. Not as
good as a release, but at least a contributor is satisfied that their
work will end up in the next, and willing to contribute some more).

> Of course that says nothing about the
> future, and as I already wrote I think that libusb activity is
> generally increasing.

I dispute that statement first hand. I have very much been forced to
decrease my libusb activity because of the lack of releases. I also
believe people like Hans and others who submitted patches are more
likely to decrease than increase their activity due to the lack of
releases as well.

> Remember that the available resources have nothing to do with me or
> any other maintainer. It is the measure of total time spent on the
> project by all contributors combined, not a measure of time spent by
> a maintainer.

The release is the sole charge of the maintainer.

>>> This reinforces my belief that the *what* is more important than the
>>> *how much*, ie. level of involvement.
>>
>> I'll take a maintainer that has to be shown the ropes, but that is
>> effectively able to contribute time to a project, over a maintainer
>> that supposedly knows the ropes but can't, any time.
>
> That makes no sense. New contributors are "shown the ropes", not
> maintainers.

Whoa, that says a lot. So maintainers receive the holy spirit of
"maintenance" at birth? Care to describe how that happens? Again, your
arrogance here is almost palpable, so I'm not going to comment on it
further.

> You also seem to not know how much time I contribute to libusb.

No I don't. I can only infer it from what you publicly chose to
disclose. Could we have less secrecy on your activities please?

> I
> agree completely that the project activity is not visible enough. I
> don't have a concrete idea for how to increase visibility, and I
> welcome all suggestions.

How about a description of how much time you spent on libusb during the
past 6 months, and what you did then, so that everybody can actually get
an idea? Sounds like a good start to me , as we could figure the areas
you haven't been able to focus on, that take time, and see how we can help.

> (Bumping a version number every month is no solution.)

It is. See the RERO analysis above. Works amazing very well for stgt and
other projects.

> As you may know, the coreboot project just started using
> gerrit for managing code review, and gerrit does provide more
> visibility for ongoing work. Something that is particularly useful
> when using git is that gerrit can track a logical change even if the
> commit id changes. I think it might be a good idea to use gerrit also
> in libusb in the future. Comments on that idea are very welcome.

Yeah, I was wondering how long it would take you to blindly apply what
occurs in another project, of a completely different level of activity,
to libusb, which I see as yet another reason why libusb is as
dysfunctional as it is right now, as the coreboot and OpenOCD templates
cannot apply blindly here (especially when there is only one active
maintainer for libsub). I personally see gerrit as one more hurdle
contributors need to go through, for the sole benefit of making the
maintainers life (who really are a class above the rest) easier, and
something which is likely to drive some contributions away (I doubt
people like Graeme would bother with gerrit, so we would effectively
lose valuable contributions).

>> If Linus came over and said he'd agree to be a libusb maintainer
>> provided he can limit his contributions to 10 hours every 6 months,
>> while somebody else came and said that, while he isn't that experienced,
>> he is motivated enough and can devote the required amount of time to the
>> project, then knowing full well that we have enough good people in our
>> project to look over any maintainer's shoulders, I'd vote for the latter.
>
> Nothing is hindering anyone from devoting time to the project.

Lack of releases is. No point devoting time on something that everybody
except one agrees could and needs to release at very short notice, but
doesn't. Makes no sense spending time on a dishevelled project where
regular folks have to spend a lot of time pinpointing out the
deficiencies of a maintainer who ignores them and thinks he knows better.

> In
> particular I am not holding anyone back. On the contrary I try to
> encourage it and facilitate it. The fixation on maintainer is strange
> to me. There is no point. I expect people to always do their best,
> and contribute if they can.

Again, people who contribute want to see their contribution in a release
(or at least mainline git). They are not going to contribute further if
that doesn't happen. Developer psychology 101. You are holding back
developments for libusb-win32 and libusbK integration, as, at this
stage, I cannot be certain you aren't going to cut another major chunk
of my code away, as you did without notice for HID (since apparently
some of the libusb code is "bad"), and whatever I start then will need
to be reworked.

Oh by the way, this is also why releases are important: they help let
developers have a solid base for their next development. That's what
people who understand RERO could also explain to you.

And as usual, you're gonna reply that one doesn't need a release to
create a new branch, and completely skim over the time wasted by the
developer by being unable to produce development in a sequential manner,
which is also something I mentioned at various stages in the past. A
developer can actually SAVE TIME by waiting for a release with his
previous development, because they know it's not gonna be backtracked on
a whim, before they start new development. Again, you should be smart
enough to have figured that one out as well.

Gotta wonder what Francesco Montorsi, who submitted the
libusb_strerror() patch because he wanted to use it in his application
and which got integrated into mainline, is thinking about its reversal 6
months ago. I'm sure he, and anybody who used mainline for lack of
releases, is super pleased of having had to to use a custom patch for
the last 6 months, waiting for a replacement. Great incentive for more
contributions there. Oh and nice work on reverting commits in mainline
that actually don't make a shred of sense for our real users. But yeah,
in 2029, it will make a lot of sense to have pissed off past users for 6
months or so in 2011... Another clear example, if there was need for
one, that you don't have users in mind (or that the ones you have in
mind are a figment of your imagination, since they are ever stuck in the
"future").

> When those contributions fit with what
> maintainers seek, new people become maintainers.  That happened to me
> twice now,

May I remind you that the libusb situation was a bit different than
that. It was Daniel recognizing, and rightfully so, that him not having
the time required for the project was becoming a serious issue, and
therefore pretty much having no choice but to appoint a second in command.

> after I simply try to help when I can, even if all I can
> manage is to write a few emails with comments, or some small patches.

Which Segher also did. Except now that Daniel is too busy to realize
what is happening with libusb, and with your unwillingness to vouch for
Segher as a co-maintainer, the process that occured for you is unlikely
to occur for Segher as it should.

Or, do you consider that Segher does not have what it takes to become a
co-maintainer in the same fashion as you did? How about following on in
the footsteps of the example that served you so well and foster its
application to someone else for a change?

> A maintainer is no different from another contributor except that the
> maintainer has slightly more of a say.

A maintainer can produce release and is expected to be very involved in
the review process (more so than anybody else - again, see stgt). But if
you see the job of a maintainer as no different than the one of a
contributor, then surely you wouldn't have much objection with being
relegated as one, and Segher taking your place, would you?

>>>> condemning the libusb project to a slow death...
>>>
>>>> Peter being able to afford the level of involvement that is
>>>> expected from a project maintainer has really been at the crux
>>>
>>> Maybe the expectations are also a factor.
>>
>> Then PLEASE step down.
>
> Expectations must be realistic. See above on maintainers. It's not
> realistic to expect that a maintainer (me or anyone else) does the
> work for you, just as it's not realistic to expect that from another
> contributor.

Where exactly did I or any other contributor not do the work that was
expected from us? Or are you referring to the various occurrence where
you advocated a position that was untenable and tried to force your
views no matter what?
"Expectations must be realistic" - a very true statement if there ever
was one. I will venture to say that, from what I have seen with regards
to "I just don't want CRLF in the repo" or "let's shove 3 time as much
work on the MS platforms as we have to do for MinGW for .def
generation", or "we'll just switch drivers on the fly on Windows", yours
have been proven unrealistic time and time again.

> As I've expressed several times I do actually offer to do that work,
> since I think it's important to take care of all contributions, but I
> do not give a guarantee about *when* I could do it, and I welcome
> someone else to do it before I can get to it very much.

Then this is a problem and we NEED more maintainers.

>> If you can't be involved, then leave the position to people who
>> will.
>
> Anyone can and should contribute as if they were already maintainers.
> If they need to be made maintainer before they start contributing then
> they are not likely the right kind of contributor that should be made
> a maintainer. Does that make sense to you?

Except we need arbitration at the top, and we are not getting any from a
single maintainer who appears to have lost focus with "reality" when he
blatantly ignores the demands of the people contributing to the project
he is in charge of. Or do you think Michael's 2029 (or was it 2019?)
quip was just a joke? Do you think Ludovic is producing libsub-1.0
releases is just for the fun? Do you think Sean's "dishevelled" was only
aimed at that annoying very vocal individual on the list (me)? Do you
think Xiaofan's input is not to be valued at all? Do you think that
Segher, who also advocated for release work that didn't take on
everything at once, is going to commend your activities as a maintainer?

Does THAT make sense to you? Or are you once again simply going to brush
criticism off, and not question your approach at all?

>> If you want to exert control,
>
> I never said that I do, and I do not want that at all.

Except this is exactly what you did, when for instance you overruled
everybody's opinion that HID removal could wait, and went for it alone,
or when you decided that the git mainline tree was not good enough for a
release, even after our users asked for one because of the fixes already
there. You are exerting a very tight and disputable control on libusb.

> What I *do*
> want is for commits to be reviewed by someone qualified before they
> are committed to libusb.git.

Same here. With Segher being made an official maintainer, we'd double
the possibility of that happening, as, if nothing else, his position
would be a very good incentive to do so. Oh, and from what I have seen,
he also already does that without being a maintainer, as per his
contributions to various discussions. So I think what you want is
actually happening, but either you don't see it or you pretend not to
see it. Once more, you appear to have lost touch with the "reality" of
what is occurring in libusb.

> I absolutely can not believe that I
> would be the only one qualified to do review, that thought is just
> absurd.

You're not. You just don't see it, potentially because you expect libusb
to behave exactly as OpenOCD and coreboot do.

>> satisfying users
>
> See above on license.

We've already clarified exactly what you mean there.

> And, if you see that the project does not satisfy users and have time
> to spare, why not work toward that then?

I do. And at least Michael did to since he commented on one of the
latest commits from -stuge. Please don't shift the blame on others, when
your lack of involvement is the main issue here.

If you want me to send ack's for each commit you have on your tree, as
well as a review of the ones you still want to add, I'll do just that,
but then I might as well become an acting maintainer, which is something
I though as well as expected somebody else, like Segher, would be much
more suited to do. I also have no illusion that you're not going trust
my reviews to fit your maintenance criteria, so I don't believe this
will actually reduce your work much, especially as we appear to have
very different view on what "good" is.

Currently, the only thing I think we need for release is the OSX version
of Hans patch, and I would like to see it submitted to the mailing list,
just like any other patch that is meant for integration. This is how we
can get any patch better reviewed IMO, as the largest number of eyeballs
is here, and the archived review work is more easily attainable than
with trac, git, or whatever. I think we also went over that, and the
consensus was that any patch aimed at integration would be submitted to
the list for review.

>>> If noone works on code then a project is inactive.
>>
>> Someday you'll have to explain to us how a project that NEVER
>> releases is active.
>
> Activity = anything happens.

Activity = contributors that are not being driven away by a maintainer's
lack of touch with "reality", such as the prospect of not seeing any of
their small patch integrated for MONTHS or even YEARS.

So yes, this is very much tied to release. Also see RERO.

> You and Xiaofan seem to agree with me that OpenOCD is an active
> project. As you know, OpenOCD has gone longer than libusb without
> a release.

Yes, and people like Freddie have been complaining about it IIRC. Also,
and this is the one thing you really should have overlooked here,
because it makes your example completely fall apart, the OpenOCD
mainline git tree sees update on VERY REGULAR BASIS, and critical fixes
seem to be applied quickly to mainline. People also do not have to look
to multiple git repos for what they need, in case they find the release
lacking. Wanna bet that a new development such as Hans getspeed would
not have taken more than 6 months to end into OpenOCD mainline?

How about you actually take some hints from OpenOCD and produce a libusb
mainline git repo that sees updates on REGULAR BASIS instead of once
every 6 months? Or does the OpenOCD example only apply where it suits you?

> Xiaofan Chen wrote:
>> your way of handling the project has done great damage to the
>> progress of the project.
>
> What is progress? The number of commits, regardless of code quality?
> (I'm not even considering patch quality.)
>
> Personally, I think progress is really only relevant when quality
> increases. Maybe this concept is foreign for contemporary open source
> programmers, but I don't think so.

Again, please provide example of bad quality in libusb. Stop dangling an
ethereal dead horse.

> I have no desire to control the project. I have strong desire for
> code review, but I have zero desire to do it myself beyond educating
> myself and having fun. It is all about the code. It's simply
> unacceptable for countless reasons to commit patches to any codebase
> until they are well formatted, well explained and well understood.

Once again, you equate RERO with poor quality. I'm sure if I go over
what you have into -stuge, I'll find that the quality of the patches you
applied isn't that different from how they were proposed in the months
(years?) prior. So really, no matter how much you would like what we
advocate to open the door to bad code, unless you present examples, your
argument here doesn't fly.

> As I have expressed many times: It is absolutely not neccessary that
> *I* do these things that I want done before relese. Pete, Hans and
> many of the contributors who have posted patches in Trac are perfect
> examples of how to help out significantly; make commits for
> integration that are easy to review and easy to access.

The current process is to post patches on the list for review. If you
want an explicit requirement for Trac for all new patches, please state
so, because it's hard for anyone on this list to understand what you want.

>> to have someone as release manager (project manager) overseeing the
>> 1.0.9 release
>
> What would that person do concretely?

At least, when there is demand for our users, they would try to finalize
what is currently in mainline, call for any critical patch we want to
have, and produce a release. That's how I see it.

> And why would they need to be
> appointed by me or anyone else before they would do it?

Because Ludovic tried to do just that, and you just ignored it.

> Why wouldn't they just do it, if they have time to contribute?

Ludovic did.

> Titles are very
> important in some corporate cultures, but I expect more than that
> from open source projects. I expect that everyone contributes what
> they can as they can, even if that means only a little.

Except, if you continue to disregard contributions or place demands on
them that are unreasonable, people are unlikely to be willing to
contribute more.

> And I see that this is what happens! There are more contributors in
> Trac and on the mailing list than maybe ever before.

Yet less releases than ever before and less commits applied to mainline
than ever before. Do you not see a discrepancy here?

> Some
> contributions need further work,

Which one? As a maintainer, it would be nice to give the list some
pointer. You have to provide directions, or step back to being a simple
contributor.

> others are ready to go and are applied as-is.

So why aren't they in mainline already, just like OpenOCD or coreboot
would do?

> Yes, a release would be nice. No, I don't think we the libusb
> community of contributors have been able to catch up with received
> contributions just yet.

I do.

> (But almost!) Yes, I think it is important not to skip too many tickets.

And what exactly is too many? How do you decide?

Regards,

/Pete

[1] http://git.kernel.org/?p=linux/kernel/git/tomo/tgt.git;a=shortlog
[2] http://lists.wpkg.org/pipermail/stgt/
[3] http://www.amazon.com/Rebel-Code-Linux-Source-Revolution/dp/0738203335

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard]

On 2011.06.12 17:02, Peter Stuge wrote:
> Pete Batard wrote:
>> Peter, do you agree that libusb would benefit for additional maintainers
>> (such as Segher), with the same kind of privileges as you have (such as
>> being able to issue releases), yes or no?
>
> Not really, no.

Textbook dictatorial behaviour #1: Refusal to share power.

>> how comes you find time for lesser matters
>
> How I prioritize is quite frankly none of your business, since you
> are not a customer of mine,

It is when you not prioritizing libusb as you should is a problem for
_many_ (not just for me).

If you're not ready/willing to devote the time you should, which, if the
best you can offer as a justification is "none of your business", then
please leave the place for somebody else who is willing to.

>> Especially how comes very critical e-mails about the current state
>> of libusb, such as one where a frequent contributor declares that
>> the project you are in charge is "one the most dishevelled" they
>> have ever seen [2], don't even elicit the Customer Relationship 101
>> reply
>
> Indeed; why is there no reply? Everyone else who is on the list is
> also a contributor and could also have sent one.

Textbook dictatorial behaviour #2: If only a minority are vocal against
me, and everybody else stays silent, then it must mean that I am doing a
good job.

>> when we went around this mailing list to find out who here thought
>> you were still doing a proper job as a libusb maintainer,
>
> This was not likely the most constructive question you could have
> asked. It feels good to bash on someone else when you're unhappy,
> but keeping focus on the project and how to make it work would be
> more useful.

Which is what I tried to do, as I don't see the project going forward
with you alone at the helm, period. Sorry, but that's just how I see it.
I don't have a problem trying to work with you, but if there can be no
arbitration between our diverging approaches, which I go great length to
try to justify each time (and this is taxing to me too), we're going to
continue to have a problem. I have no issue with Segher or somebody else
providing this arbitration, but then they need to have the same rights
as you do, or else I can't see how that will work. If you continue to
ignore libusb users, which if you point to any e-mail I wrote, I hope
actually transpires as my prime motivation for being very vocal, I see
it as inevitable that you and I will continue to have disagreement that
require arbitration from a third party with actual authority. And this
is actually part of my proposal to solve the current issues. But that
requires some acceptance from you to share power.

Are you ready to accept compromise, which I believe this list would very
much welcome, or should I go textbook #3 here?

Oh, and I am extremely serious here: I take no pleasure whatsoever in
bashing your actions (or yourself, if you think this is personal). None.

> I'll continue doing what I think is needed for rc1.

Textbook dictatorial behaviour #3 (or #4): I know better than anybody
else what people want, and will ignore their plea wholesale.

> It's
> obvious that neither you nor I find the current process to work well.

Yes, because I am afraid you have the textbook behaviour of a dictator,
as highlighted above (the bad kind, not the benevolent one) which
doesn't fit well with a process that actually requires a little bit of
democracy, flexibility, and balance of power. You are not infaillible.
Neither am I. So please stop pretending that in your libusb maintainer
position, as you have done in the 2 previous e-mails, you have not
committed any mistake yourself and that the current mess is only caused
by others. Thank you.

Regards,

/Pete




------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Sun, Jun 12, 2011 at 11:17 PM, Peter Stuge <[hidden email]> wrote:
> You and Xiaofan seem to agree with me that OpenOCD is an active
> project. As you know, OpenOCD has gone longer than libusb without
> a release.

Yes OpenOCD is active since the developers are still actively accepting
patches (very fast), and the patches are accepted in the main git tree, not in
a testing branch or a separate git.

However, OpenOCD's lack of release is also causing problems for
the users. Please read this thread.
https://lists.berlios.de/pipermail/openocd-development/2011-June/019344.html

My proposal got acked by some active members in OpenOCD.
https://lists.berlios.de/pipermail/openocd-development/2011-June/019467.html
https://lists.berlios.de/pipermail/openocd-development/2011-June/019472.html

And your point of view of no need a release got NAKed by at least one user.
https://lists.berlios.de/pipermail/openocd-development/2011-June/019466.html

--
Xiaofan

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Michael Plante]

Peter Stuge wrote:
>> Hasty commits that need to be corrected are bad. They create extra
>> work in the future and they lead to low code quality.

It sounds like you're the only one spotting the problems with commits.
Perhaps it would be useful to you not to have to both find them AND fix
them?  In other words, a possibly-useful compromise might be for you to send
a list of problems to the list and let someone share the burden of fixing
them?  Or is it too serial for that to work?

Michael


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

Now that Peter's stand is very clear and it is absolutely impossible to
convince him that timely release is necessary for libusb project.
So I will just give up trying to convincing him. Enough have been said.

I understand that libusb-1.0 is now widely used under Linux and
Mac OS X so that it will probably not die so soon even with
Peter's handling of the project. However, it will still in a bad
situation since there will be less and less active contributors.
libusb-1.0 Windows will probably die quite soon in Peter's hand.

So for those who want a timely release, I think we have to forget
about Peter and do it our own way (to fork, or to switch to
competing library, or create a new library) or just no longer
recommend libusb-1.0, at least for Windows platform.

Since Pete is basically against a fork, so right now I will
forget about libusb-1.0 Windows for a while myself and
no longer recommend Windows users to use libusb-1.0.


--
Xiaofan

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Xiaofan Chen wrote:
> Now that Peter's stand is very clear and it is absolutely impossible to
> convince him that timely release is necessary for libusb project.

What is timely one could ask, but never mind. The point is that more
frequent releases are desired, and I have absolutely nothing against
frequent releases, as long as three criteria are met; not too many
significant tickets are left open, not too many patches are pending,
and that what gets released is actually understood and has been
reviewed. But this is getting a little ahead of time. Maybe can get
back to this once there's a rc.

On another matter, I agree completely with Pete that low visibility
of project activity is a huge problem. I think the bulk of this could
be fixed with a little documentation about which repo has what
together with using a branch in libusb.git as merge queue, instead of
a separate repo. I think gerrit may also help with this, maybe mostly
because Trac has too weak support for git concepts. :\


> right now I will forget about libusb-1.0 Windows for a while myself

I think that's the only right thing to do if libusb-1.0 is not useful
for you on Windows now.


> and no longer recommend Windows users to use libusb-1.0.

That's up to you of course, and I agree that the gap between what
will be released and -pbatard master makes libusb-1.0 less attractive
for now, but I believe Pete is as eager as I am to close that gap.


//Peter

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Michael Bender-3]

On Jun 12, 2011, at 6:31 PM, Xiaofan Chen wrote:

> Now that Peter's stand is very clear and it is absolutely impossible  
> to
> convince him that timely release is necessary for libusb project.
> So I will just give up trying to convincing him. Enough have been  
> said.
>
> I understand that libusb-1.0 is now widely used under Linux and
> Mac OS X so that it will probably not die so soon even with
> Peter's handling of the project. However, it will still in a bad
> situation since there will be less and less active contributors.
> libusb-1.0 Windows will probably die quite soon in Peter's hand.
>
> So for those who want a timely release, I think we have to forget
> about Peter and do it our own way (to fork, or to switch to
> competing library, or create a new library) or just no longer
> recommend libusb-1.0, at least for Windows platform.
>
> Since Pete is basically against a fork, so right now I will
> forget about libusb-1.0 Windows for a while myself and
> no longer recommend Windows users to use libusb-1.0.

This is why we created OpenUSB years ago - pretty much the same
issues with Johannes back then that we are having with Peter now.
I don't understand why someone signs up to be a maintainer for a
project and then just decides to not listen to the community (the user
and developer base).

mike


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard]

On 2011.06.13 03:17, Peter Stuge wrote:
> Xiaofan Chen wrote:
>> Now that Peter's stand is very clear and it is absolutely impossible to
>> convince him that timely release is necessary for libusb project.
>
> What is timely one could ask, but never mind.

Whatever other projects of a similar size and activity as libusb, such
as stgt (which is why I keep referencing to it, as whenever you will try
to justify that RERO on a project similar in scope to libusb simply
cannot work, I will show you one that does _prove_ you wrong) do. Or, if
you want a non explicitly RERO project closer to you, the 6 months or so
between releases of flashrom [1] (I'd say the next one is a bit overdue,
but that of course depends of how much new code has been integrated
since the last) doesn't seem like that bad a deal, especially in
comparison to libusb. When there is a normal level of activity, one year
between releases should never happen.

> The point is that more
> frequent releases are desired,

At last, some progress!

> and I have absolutely nothing against
> frequent releases,

I'll dispute that statement. If you firmly believe that RERO simply
cannot work for libusb, then you are against frequent releases, but
we've already been over that.

> as long as three criteria are met; not too many
> significant tickets are left open,

Lets quantify this with an actual number then. We have exactly 30 open
defect tickets in trac right now. Of the ones we currently have (and yes
I understand that every situation will be different depending on the
content and criticality of tickets), what is the lowest percentage you
reckon we need to go through for the next release? See the list below
for help.

> not too many patches are pending,

I'd add an addendum: if there are patches that are very critical and we
have fixes for them, we should do our best to produce a release,
regardless of how many other open tickets are pending. Delaying the
release of critical patches is bad, OK?

> and that what gets released is actually understood and has been
> reviewed.

This is more fuzzy, because your description is a bit vague. By whom?
And how many people should review it before it is declared good?

My understanding, and what I have seen on other projects including
flashrom or OpenOCD, is that whenever a patch is submitted, a maintainer
or acting maitainer takes the review and integration of the patch under
his or her wing, while tacitly inviting comments from anybody who is
interested (which, depending on the patch, may not necessarily amount to
a great deal of people, or any at all, and that's why I also believe it
very important to define explicit maintainers, as people tasked to take
the review upon them of patches that nobody else has manifested interest
in reviewing).

Judging from what happened in the past on this list, and also (I hope)
to go with some of the ideas you exposed in your previous mails, I think
it might help if, whenever a patch is submitted, we ensure that it is
officially "assigned" to a reviewer, who will then be tasked with doing
the work they see necessary for integration, and then, once they are
satisfied with it, provide an ack (or tell the list "we might want to
delay the integration of that one for the release after next"). And, we
need to consider then that a patch that has not seen a reviewer
explicitly attaching their name to it for some time (preferably days, at
most a couple of weeks), action must be taken by a maintainer to ensure
that it is never left orphan.

I'm pretty sure neither Segher, Nathan or myself would have much of a
problem regularly attaching our name for review of patches targeted at
Linux, OSX and Windows respectively, as well as more global ones. And
believe we have more than enough other people willing to step in in case
we don't, should we formalize the review process as I exposed above.
Official assignation of a task, such as patch review, to someone is of
course pretty much what is expected to occur with trac (and possibly
gerrit), except I don't think libusb is big enough right now to require
that every contributor goes to trac to submit a patch (the overhead of
doing that would be more trouble than it's worth IMO, especially with
trac still being dreadfully slow).

Would doing something as what's exposed above work for you? Of course,
we'll also need to go through the backlog.

For what is worth, since my name is attached to it in trac (and it's an
enhancement anyway), I think libusb0.sys support is best targeted at the
release after next.

And while I'm there:
#2 (use of -pedantic) #28 (Clang warnings) -> better left for next
release when we had better things to do (but you already dealt with #28)
#39 (1.06 segfault) & #47 (USB-SUN device affects
libusb_get_device_list) -> we don't have enough for testing => unless
the user comes back to us, we should ignore these
#48, #63, #70, #96 - already dealt with in -stuge
#56 - acked by yourself, but not integrated (I believe) because you
couldn't find a function name you liked
#62 - nobody seems to have looked into it. I'd suggest we leave it for
next release.
#64 - user is unwilling to contribute to this one until his previous
ones have been merged into a release (obviously I'm not surprised there)
-> leave it for next release
#65 - acked by Nathan, but you still want more review to it? Talk about
asking for help with regards to review, and then ignoring that altogether.
#68 - acked, fixed but no longer relevant since HID has been removed
#69 (WMware bulk transfers take too long) - will require some
involvement in testing - better leave for release after next
#70 - has been fixed with the .ac/.am ovehaul
#73 (libusb_get_string_descriptor_ascii fails on powerPC platform) - who
has a powerPC platform to test? If not: delay
#75 acked by Segher
#77 (get_max_packet_size returns bad value) - no idea here how important
you think it is. This is the only one so far that I see as possibly
requiring action before release, but Tim said it might be tricky to
address and probably "isn't worth fixing"
#80 (Lose a packet when there is null packet in an isochronous
transfer): looks serious, and nobody has looked into it. It should be
assigned to someone IMO, be it only to find out whether we want it for
next release or not
#81 (Race condition between libusb_submit_transfer() and
usbi_handle_disconnect()): Looks like I should have added it to my repo
(since it was targeted at -pbatard), so that I could feed it back to you
from my integration branch. I want to have it in my repo anyway, so I'll
add it. If you want it reformatted for -stuge then, just ask.
#82 (Crash in timed-out transfer): I can handle this one too in -pbatard
if you want. Would prefer if you apply directly on -stuge without going
through -pbatard first, as it touches more than previous patch (so it
would benefit from maintainer's review), and I'll have to waste time
rebuilding my integration branch against your bloody ever-rebased -stuge
to format the patch in a way you can apply it.
#83 (Valgrind buffer overflow): patch is very simple and short. A
maintainer should not have to ask for help to decide whether he wants to
apply it for next release or not
#83 (incomplete docs) - not a showstopper
#88: assigned to Nathan, up to him to decide whether we should have it
for next release or not
#97 (remove "-fgnu89-inline") - very straightforward, everybody agrees
on the course of action, yet not yet applied in -stuge
#100 (cast of 32 bit value to 64 bit, pthread_exit) - low risk, simple
easy fix, and pretty much acked by Segher. Shouldn't take 5 months to apply
#101 (Income data is lost after a timeout reading from
libusb_interrupt_transfer) - potentially serious, would need
investigation. Any volunteer?
#106 (typo): self explicit

As to the enhancements, I think the ones needed for next release have
already been dealt with, while the ones that haven't can wait.

Seriously, I don't see anything in the above that cannot be handled
single handedly by a busy maintainer (who can ask for some of the issues
that need investigation to be assigned to people willing) during the
course of a couple of weeks.

By the way, you know what works wonders to speed up dealing with open
items: text lists of everything that's open, with latest update and that
gets updated by a maintainer on a weekly basis. Makes everybody happy,
as users can also see whether their issues are getting the attention it
requires on regular basis, especially when trac is EXTREMELY slow (as it
is today), and practically unworkable.

> But this is getting a little ahead of time. Maybe can get
> back to this once there's a rc.

In that case could we have an actual ETA for the rc, and some assurance
that you will do you best to try to stick to it? I know you don't like
ETAs, but if we have to wait another 6 months in the dark for your rc,
the situation will not have changed one bit.

> On another matter, I agree completely with Pete that low visibility
> of project activity is a huge problem.

It is, which is why I firmly believe that adding more maintainers to the
project would help, as maintainers are expected to produce some
visibility on the integration/release process be it only by having
patches reviewed and officially acked.

> I think the bulk of this could
> be fixed with a little documentation about which repo has what
> together with using a branch in libusb.git as merge queue, instead of
> a separate repo.

Or, doing what other project do, and make patches appear into mainline
as soon as possible (which, again, does not mean "hasty"), so that
people don't have to juggle with more than one git repo to get the
latest changes.

The only time we should use non mainline git repos is for new
developments that will take some time to get stable. None of what you
are currently applying to -stuge (apart perhaps get_speed(), if we are
still missing OSX, and the .ac/.am changes when you were still trying to
figure them out) qualifies for that. The rest should really be applied
to mainline IMO. For the record, this is exactly what Daniel appeared to
be doing (yes, I am aware that he was using his own internal repo,
before pushing anything to mainline, but unlike -stuge, it was
_internal_, meant as temporary usage: it didn't take him months to push
whatever he had there onto mainline), so you deviated from his methods some.

> I think gerrit may also help with this, maybe mostly
> because Trac has too weak support for git concepts. :\

Let's have the debate about the benefit of gerrit when the libusb
situation is stable (and when we have seen the outcome of its usage on
coreboot), shall we?

> That's up to you of course, and I agree that the gap between what
> will be released and -pbatard master makes libusb-1.0 less attractive
> for now, but I believe Pete is as eager as I am to close that gap.

A lot more. I've spent the last 18 months trying to close the gap by
submitting (and resubmitting) patches to effectively close it... which
fell into oblivion for the most part.

Regards,

/Pete

PS: Please also seriously consider the need for external arbitration
when we have diverging views, as well as power sharing (What happens if
you get hit by a bus? Do we wait months for Daniel to assign a new
maintainer? There should be at least some level of redundancy at the
head of libusb). This is another problem that needs to be addressed.

PS2: A fork very much means to me that people somewhere were _stupid_
enough not to settle their differences (which is where arbitration by a
third party comes into play) and lose track of what's best for users.
That's one of the biggest sin you can commit against users of a project
IMO. Not to say that resolving differences is easy, and will not result
in a very lengthy and vocal discussions, but I think that every time
someone sees a fork as a better solution than a compromise (and I'm
talking about both forker and forked parties here), they're not trying
hard enough.

[1] http://freshmeat.net/projects/flashrom/releases

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Ludovic Rousseau]

Hello,

2011/6/12 Peter Stuge <[hidden email]>:
> Pete Batard wrote:
>> how comes you find time for lesser matters
>
> How I prioritize is quite frankly none of your business, since you
> are not a customer of mine, but someone I work together with in a
> setting where we both contribute what we can.

It is a bad news that I need to be a customer of Konsult Stuge [1] to
get some/more attention from you.

Maybe you only support libusb users if they are customers of your
consulting company? Maybe you have your own version of libusb for
paying customers? In that case it is logical to NOT do anything with
the public libusb version if your business model is to _sell_ support
for your version of libusb.

libusb.org is a domain name belonging to Konsult Stuge [2].
libusb.org is hosted on 212.116.89.126 also known as earth.stuge.se,
lists.stuge.se and ns.stuge.se so also managed by Peter Stuge.

The libusb project [3] on sourceforge is administered [4] by Daniel
Drake and Johannes Erdfelt. Both of them have disappeared from this
mailing list. It is no more possible to take over a sourceforge
project without the explicit consent of the admins using the Abandoned
Project Takeover [5] procedure.

So it will be hard to reuse the domain name libusb.org or the libusb
sourceforge project.

The only viable option I see now is to fork libusb in a new project
(libusb-ng?) maintained by people working for the library users.

Regards,

[1] http://stuge.se/
[2] http://www.whois.net/whois/libusb.org
[3] http://sourceforge.net/projects/libusb/
[4] http://sourceforge.net/project/memberlist.php?group_id=1674
[5] http://sourceforge.net/apps/trac/sourceforge/wiki/Abandoned%20Project%20Takeovers

--
 Dr. Ludovic Rousseau

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard]

On 2011.06.13 16:58, Ludovic Rousseau wrote:
> Maybe you only support libusb users if they are customers of your
> consulting company? Maybe you have your own version of libusb for
> paying customers? In that case it is logical to NOT do anything with
> the public libusb version if your business model is to _sell_ support
> for your version of libusb.

To be fair, I don't think Peter is selling anything related to libusb,
or making money out of it (but I may stand corrected). And even if that
was the case, I don't believe someone who has participated in OSS as
long as Peter would voluntarily reduce the appeal of a project just so
he can personally benefit from it. On the contrary, I think he has
generously offered to host libusb as well as other projects, on his own
private server, and he has apparently paid for the domain as well. If
anything, he should be commended for doing that, as his actions there
very much helped the project.

> The libusb project [3] on sourceforge is administered [4] by Daniel
> Drake and Johannes Erdfelt. Both of them have disappeared from this
> mailing list. It is no more possible to take over a sourceforge
> project without the explicit consent of the admins using the Abandoned
> Project Takeover [5] procedure.
>
> So it will be hard to reuse the domain name libusb.org or the libusb
> sourceforge project.

Now, I agree that, if we decide to fork, we shouldn't really count on
being able to reuse the original domain name, and this is another reason
to be careful about a forking decision: it would take time to establish
the fork on equal footing and visibility as the original project, which
would mean less contributions and/or reports from users.

Regards,

/Pete

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Mon, Jun 13, 2011 at 7:56 PM, Pete Batard <[hidden email]> wrote:
> PS: Please also seriously consider the need for external arbitration
> when we have diverging views, as well as power sharing (What happens if
> you get hit by a bus? Do we wait months for Daniel to assign a new
> maintainer? There should be at least some level of redundancy at the
> head of libusb). This is another problem that needs to be addressed.

I agree with this one. The issue is that who is the 3rd party? The community?
Daniel Drake? Who? The license grants the user no right to ask for a release
after all. So Peter did nothing wrong in terms of the license. No
release is okay from the license' point of view even though the users
will not be happy with it.

> PS2: A fork very much means to me that people somewhere were _stupid_
> enough not to settle their differences (which is where arbitration by a
> third party comes into play) and lose track of what's best for users.
> That's one of the biggest sin you can commit against users of a project
> IMO. Not to say that resolving differences is easy, and will not result
> in a very lengthy and vocal discussions, but I think that every time
> someone sees a fork as a better solution than a compromise (and I'm
> talking about both forker and forked parties here), they're not trying
> hard enough.

I really admire your patience here. Hopefully you two can work
together and get 1.0.9 released. Before that, I am out of the
libusb-1.0 discussions for Windows and will not recommend
any users to use libusb-1.0 under Windows.

--
Xiaofan

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Mon, Jun 13, 2011 at 9:11 AM, Xiaofan Chen <[hidden email]> wrote:

> On Sun, Jun 12, 2011 at 11:17 PM, Peter Stuge <[hidden email]> wrote:
>> You and Xiaofan seem to agree with me that OpenOCD is an active
>> project. As you know, OpenOCD has gone longer than libusb without
>> a release.
>
> Yes OpenOCD is active since the developers are still actively accepting
> patches (very fast), and the patches are accepted in the main git tree, not in
> a testing branch or a separate git.
>
> However, OpenOCD's lack of release is also causing problems for
> the users. Please read this thread.
> https://lists.berlios.de/pipermail/openocd-development/2011-June/019344.html
>
> My proposal got acked by some active members in OpenOCD.
> https://lists.berlios.de/pipermail/openocd-development/2011-June/019467.html
> https://lists.berlios.de/pipermail/openocd-development/2011-June/019472.html
>
> And your point of view of no need a release got NAKed by at least one user.
> https://lists.berlios.de/pipermail/openocd-development/2011-June/019466.html
>

Just an update, OpenOCD now has a release manager who is pushing
for frequent release, actually too aggressive if I may say so.
https://lists.berlios.de/pipermail/openocd-development/2011-June/019593.html
https://lists.berlios.de/pipermail/openocd-development/2011-June/019601.html

6 release in a year! I think for project like OpenOCD, 2 is not bad already,
4 is actually quite aggressive, let alone 6.

For libusb, I will be quite happy with 2 release per year. :-)


--
Xiaofan

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Sean McBride]

On Sun, 12 Jun 2011 17:17:55 +0200, Peter Stuge said:

>> > If this is really how things look that is bad.
>>
>> It is. .. should agree that the situation is bad, since they have
>> arguably overextended their expected maximum release deadline by
>> at least 6 months now...
>
>You misunderstood. It is bad if it looks as you describe, because the
>reality is quite different from your description.

It looks as bad as he (Pete) describes!!!

I use and contribue to several open source projects, and have never seen one as sadly managed as libusb.

For casual users/contributors like myself, who don't follow the inner workings much, the public view is extremely discouraging.  Most websites have a big 'download' link somewhere, the closest I see is 'browse source':

<http://www.libusb.org/browser>

>From there there's a link described as "The libusb C library", which sounds pretty definitive.  The other links look like personal branches, given that they contain usernames.  The definitive looking one says "age 8 months".  8 months is a long time between releases, let alone changes to a source control repository!

Add to that the fact that (my) trivial bugs, with patches! (97 & 100), are still unapplied months later.

The project looks dead, frankly.  It is in desperate need of a fork, compromise, or something!

Cheers,

--
____________________________________________________________
Sean McBride, B. Eng                 [hidden email]
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada



------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel