On 16-Nov-07, at 9:18 PM, erland wrote: >> > Of course, if there was some kind of roadmap available so we could see > where SqueezeCenter was heading for the next 12 months, it would be > very easy to just refer users to that. Unfortunately no such thing > exists. > You don't need 12 months in plans to make one patch. Every patch changes the plans.
> ink the problem here is that if some new developer was going to > develop a patch like this he/she would need some guide how to do it to > make it fit the SqueezeCenter style and architecture. The problem is > that when you ask questions and guidance regarding development of > features that isn't planned in the near future, my experience is that > it is very hard to get help/thoughts from the core developers. Sorry, but I call foul on this one. Try it with something specific and small, not a personal preference, plugin handling idea, API rework or worst of all something that just stinks of a way to pry for promises or future plans. Take a bug and post a patch. The code is there, so you can see the style. If you have specific style questions, ask. Most of what I see is "I want this, how do I do it or how do I get someone to add the hook to do it". That's not the same thing at all. While it's great to have plugins and enthusiastic authors (I AM a big fan of your plugins, just so you are aware I'm not on the attack here), it is a far cry from writing FOR slimserver and for other people. It requires getting away from one's own agenda and make something happen without expecting someone else to do it for you or promise that the patch get immediately committed. It would be nice if it were possible, but there really aren't the resources. Even I can see that. If it's a question with a large scope, and you don't get answers, then it's probably because it takes as much time to investigate as it takes to start writing. I'm well aware of how much time can be given up just looking into an idea. Why not come up with a proof of concept. You have the source. Even if it's rough, a demo can go a long way. The basics have been mentioned before: unix line endings, lots of whitespace, tabs (stops on 4 seems to work best). After that, patches can be evaluated and modified. You'll learn quickly after a few. > There > are a few that tries to answer if the question is in the area they > have > worked, and you are certainly one of those, but if the feature is > something completely new it is sometimes hard to get a discussion > started about "how to do it". To be frank, something completely new isn't always the best place to start. There are plenty of bug reports, all with a nice link for posting patches. I started with a simple patch for adding a 'gt' and 'lt' comparison in the original skin template system. Two lines, in order to do something I saw missing in a skin I didn't even use. > If new developers starts to make patches that doesn't fit the > SqueezeCenter style/architecture, it will just result in that they get > tired to develop for SqueezeCenter because thier patches never is > applied. I see that as an agenda, I'm afraid. I've had many patches taken, many not. I've submitted work, and had someone else come along and tell me I have to do it differently. I've spent a week on one idea, only to have someone else say it's lame, rewrite it get the patch in and disappear, leaving me as the "guy who worked on that area" to answer questions when it turns out broken. You get it all. There are no guarantees. I think having someone to be at the beck and call of demands for answers would be a quick road to a job vacancy. I'm sorry it all sounds harsh, but that's just how it is. I understand it's a huge commitment. I know how much time it takes, and I also know how little you can get done if you spend time responding to all requests in all directions. It's very easy to get into something that just doesn't end (as I'm expecting the case will be here). I can't say it enough: start simple. -kdf _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
