On 2010-01-08, at 4:27 PM, snarlydwarf wrote:
>
> Don't some non-Logitech people have SVN commit access?
There are (myself and triode, for example), but it's not complete freedom to
just dump anything we feel like into the core code. Access is given due to a
level of trust. The management of non-logitech commits isn't done in the same
way as it was in the past, but when deadlines approached, all third party (and
employees) were asked to have everything reviewed by key stakeholders before
committing. I'm happy to commit patches by proxy (and have done so frequently)
but only at times when it's open to do so. 7.5.0 is not in that state. Maybe
for 7.4.2 since there is no pending release, and if there was a patch to fix
something known to be broken in 7.4.1.
>
> That would get around the submit-patches-hope-they-get-taken in
> problem.
>
patches still need to be reviewed. I committed something today, but it was a
note in a readme. I'll also fix typos or even add debug lines if it helps look
over a problem mentioned in a thread. I've got a fair number of patches
sitting attached to bugs that I won't even think about committing until Touch
is out or someone more directly on the hook for supporting the code says it's
ok :)
Yes, I'm upset about the changes in communication too, simply opening up svn
isn't the solution. Perhaps when dust settles, we could pitch for a branch to
be created for "third party experiments" that could take in unsupported patches
(via logitech or trusted committers) and be built internally by the same
processes as the trunk. This would allow for wider testing of some changes and
to put money where my mouth is, I can certainly volunteer to merge and commit
patches on something like that. I don't post often nowadays but I'm still
reading most posts, and I would be prepared to respond to patches under this
system without much delay (within reasonable limits so that we aren't loading
up too many wacky experiments in one day).
>
> The SBS API seems to have a lot of cruft especially since there are
> some major design changes between the SB1/2-3/Duet/SqueezePlay devices.
> Then you have the whole json stuff and cli stuff (which to use when?)...
>
Yes, it does. This is sometimes the drawback of third party contribution.
It's a temptation to accept a patch, but then it can turn out later that it
gets in the way of something else. There is always a risk that the patch
provider won't be around later in order to support it. I'm certainly not
completely innocent here either. I still kick myself when I look at some of
the home menu code for the older players. Sure, it allowed for customising the
home menu (and in fact, also manipulating any level), but it hasn't kept up
with how newer features and hardware interact with the UI. It's a huge task to
make what appear to be simple requests work without ripping apart large
sections and starting from scratch.
>
> And god forbid removing any of it. (I could easily see a case for
> yanking the CLI access and focusing on json/http functionality.. but too
> much stuff depends on CLI, and can't break that, even if there is a ton
> of duplication...)
exactly. I've seen many attempts to remove some really painful code problems.
Some have been met with rather strong protest when the change takes away
something that has been used. A case in point was some problematic and error
prone http headers no longer being used by anything in the core and were more
completely handled by the CLI. However, these headers were in use by a third
party application so they went back in. I think that bit of code is mostly
gone now, but at the time, it did limit what could be done to fix some other
known issues of the day.
In this thread, we've seen recognition that larger companies are slower. Very
true. Also, more cautious. This is why startups have room to come in a blow
people away with new ideas. Clearly in this new climate, we can be upset about
changes for third party developers as there are very definite changes going on
for plugin authors and for third party core coders (and, for that matter paid
Logitech employees). However, try turning that around and consider how we can
convince "the powers that be" that there are ways that could be found to allow
"us" to better support ourselves. Surely it's simpler to accept a patch that
gives the core a new API hook for a desired plugin feature than to campaign for
time-limited employees to be given high level support to allocate time to write
that code internally? I started my journey into SS by sending patches to Dean
in order to make my own skin (and it wasn't even a public skin at that point).
At some point in open source, there is always the talk of forking. Maybe what
I'm talking about here is more or less forking, but in a way that still allows
for new features to merge back into the core.
-kdf
_______________________________________________
discuss mailing list
discuss@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/discuss
