> We hardly ever assign them so that is not a good way to measure things.
> I'd say reminding us about the patch(es) by posting here is a good
> way, if not done too often.
So I guess those of us who don't like to be a "squeaky wheel" are at a
> We often feel under-manned, so we are always ready to offer skilled
> and interested patch contributors full CVS commit access to help us
> avoid bottle necks (and add yet another one that can apply other's
Does anyone control what goes in then? Or do you just back things out
when someone submits something that isn't popular?
> Daniel Stenberg wrote:
>> Of course making sure that the patch follows the guidelines and
>> applies cleanly is a good way to make it get applied faster.
> I'd say that this is one of the major "patch-stoppers". Very often the
> patch author has only solved the problem on one of the platforms, and
> perhaps not even in the simulator. Then it's up to us developers to
> make it work in the simulator and the other platforms. That's often
> quite a lot of work.
For my own part (regarding my A-B Repeat patch) I've tried to be careful
to cross all the t's and dot all the i's but I discovered after posting
my latest update that I accidentally broke the simulator. I usually
check that before releasing but forgot to this time. I will post a new
update soon that fixes this.
As for solving the problem on all of the devices, this can be very hard
to do sometimes (even with the simulator) for devices that you don't
have access to for testing. And the problem is only getting worse as
new devices are added.
As for A-B Repeat, I only have an FMR, so of course I have it working
fully on there. Not necessarily so on the other devices. The core
functionality should work on all the devices as there is nothing
device-specific. Two areas that are device-specific are key assignments
and display elements. I've defined the key assignments for
'CONFIG_KEYPAD == PLAYER_PAD' devices and 'CONFIG_KEYPAD ==
RECORDER_PAD' devices but I don't even know what the hardware looks like
for the others (never mind which buttons are available for use). As for
the display, I've implemented a graphical marker to show the A & B marks
for 'HAVE_LCD_BITMAP' devices. I'm not sure this is even possible for
others. I've also implemented an A/B Repeat status icon for those
devices and I asked about implementing one for the others but was told
it's probably not possible. So I'm not sure how to solve those problems
or if it's even possible to do so. If all else fails, I've wrapped all
of my code in '#ifdef AB_REPEAT_ENABLE' (defined in abrepeat.h) so the
feature can just be disabled on devices that aren't yet supported (or
which cannot be supported).
It should be possible to at least introduce A-B Repeat for the recorder
devices for 2.5 (maybe players too, if someone can test it).
Received on Wed Jul 6 22:17:34 2005