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.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
