Updated SlimServer 7.0 Spec with Schedule

[MickeyG]

I’ve noticed that some community members on various threads have expressed interest in moving more rapidly toward a 7.0 release. I think we would all agree that it would be great if we could do that, and in my role here as a Slim Devices/Logitech Program Manager I’d like to offer my help to the community in doing that.

How could I help? Here are some thoughts on how I could work with the community to accelerate 7.0 development:

1. Encourage everyone to publish their plans for 7.0 – to-do lists, plans for changes or new features, when you want to do it, and when you want to be done.
2. Initiate community discussions to review and seek guidance on potential 7.0 plans and features.

To kick off this effort, I’ve updated the SlimServer 7.0 wiki with a detailed list of milestones that Dean’s team is working towards, and a brief description of what we’re doing:

http://wiki.slimdevices.com/index.cgi?SlimServer7Spec

I’d encourage everyone in the community developing for SlimServer 7.0 to update this wiki with similar info.

Let me also take this opportunity to summarize what’s going on….

The release of SlimServer 7.0 is the first step in an effort to address some long-standing, well-known issues with SlimServer and SqueezeNetwork:

- Tighter integration between SlimServer and SqueezeNetwork.
- Update user interfaces to both.
- Make web UI and players easier to use for everyone with consistent user interfaces and the same features everywhere.
- Guided wizard for first-time set-up.

Also included is Jive support, of course.

I’ll try to keep the wiki up-to-date as circumstances inevitably change.

What are your thoughts? Let me know if you’d like more details about what’s going on, and I’ll answer them if I can.

Thanks for listening!

Mickey
Slim Devices / Logitech Software Program Manager

[erland]

What are your thoughts? Let me know if you’d like more details about what’s going on, and I’ll answer them if I can.

As a plugin developer it is great to finally get some sort of indication on which date SlimServer 7.0 is aiming at.

Does "Beta start" also mean a feature freeze where any major features not implemented at this date will be implemented in 8.0 or later instead of 7.0 ?

[MickeyG]

As a plugin developer it is great to finally get some sort of indication on which date SlimServer 7.0 is aiming at.

Does "Beta start" also mean a feature freeze where any major features not implemented at this date will be implemented in 8.0 or later instead of 7.0 ?

That's a great question, Erland. I know my answer would be "yes" because any software project needs to stop adding features if it is ever going to be released with any stability. I think my addition of "Coding Done" after "Beta Start" hinted at my feelings about that. *^)

However, SlimServer has always been community software and does not belong to Slim Devices or Logitech. So I'm not comfortable creating rules that the community must follow. I am OK with suggesting guidelines to help the community achieve its goal of a SlimServer 7.0 release.

And if the community is OK with those guidelines or some other set of agreed-upon rules, I would then be OK enforcing those.

So ... how about it? Beta Start = Feature Freeze? I would propose branching the trunk for SlimServer 7.0 at that milestone and new features after that go into the trunk. After 7.0 is released, then the developer can decide whether to merge the new feature into the branch.

Everyone OK with that? If not, alternative proposals are welcome.

Mickey

[kdf]

On 13-Jul-07, at 10:14 AM, MickeyG wrote:
>
> So ... how about it? Beta Start = Feature Freeze? I would propose
> branching the trunk for SlimServer 7.0 at that milestone and new
> features after that go into the trunk. After 7.0 is released, then the
> developer can decide whether to merge the new feature into the branch.
>
> Everyone OK with that? If not, alternative proposals are welcome.
>
This is roughly how it has been done thus far. There are, however,
always exceptions.
Sometimes it is a last minute feature always intended to be included
but held off
for reasons of official announcement dates, etc.

Where we could improve is to set the feature plans and maintain focus
on that. In the past, there is a
lot of spontaneous feature adds, feature flip-flops (never ending
flip-flops) that aren't planned. Understandable sometimes, but it does
lack focus and does hinder more careful design of the intended
features/fixes. That's always the problem when you rely on volunteers.
They jump in when it's fun, but much harder to get the last details.
Not just because it's less fun, but also because it is harder to get
everyone together to brainstorm when you have many different timezones
and none with any sort of critical mass of contributors at one time.
Every design needs someone at the helm making sure everyone is going in
the same direction.

-kdf

[MickeyG]

On 13-Jul-07, at 10:14 AM, MickeyG wrote:
>
> So ... how about it? Beta Start = Feature Freeze? I would propose
> branching the trunk for SlimServer 7.0 at that milestone and new
> features after that go into the trunk. After 7.0 is released, then the
> developer can decide whether to merge the new feature into the branch.
>
> Everyone OK with that? If not, alternative proposals are welcome.
>
This is roughly how it has been done thus far. There are, however,
always exceptions.
Sometimes it is a last minute feature always intended to be included
but held off
for reasons of official announcement dates, etc.

Where we could improve is to set the feature plans and maintain focus
on that. In the past, there is a
lot of spontaneous feature adds, feature flip-flops (never ending
flip-flops) that aren't planned. Understandable sometimes, but it does
lack focus and does hinder more careful design of the intended
features/fixes. That's always the problem when you rely on volunteers.
They jump in when it's fun, but much harder to get the last details.
Not just because it's less fun, but also because it is harder to get
everyone together to brainstorm when you have many different timezones
and none with any sort of critical mass of contributors at one time.
Every design needs someone at the helm making sure everyone is going in
the same direction.

-kdf

Thanks for the confirmation about how to handle beta start. I'll wait a little while longer for additional feedback before I modify the wiki to reflect that Beta Start = Coding Done = Feature Freeze = Branch from Trunk.

Thank you also for the insight on how the community works. As a newbie here, I appreciate that. I have no problem being the guy that helps everyone move in the same direction or encourage developers to focus on the needs of the community at large.

Mickey

[kdf]

On 13-Jul-07, at 3:21 PM, MickeyG wrote:
>
> Thank you also for the insight on how the community works. As a newbie
> here, I appreciate that. I have no problem being the guy that helps
> everyone move in the same direction or encourage developers to focus on
> the needs of the community at large.
>
I think the process worked fairly well with 6.5.3. Bugs got selected
in a targetted grouping and it got out relatively quickly.
It's a bit easier when it's a bugfix release. 7.0 is really going to
need extra help, so the trick will be to bring more newbies in
and on task. There are lots of folks more than happy to offer ideas,
and some who will even dive into code.

The plugin API is shaping up nicely, but it really needs an installer
UI. I hesitate to suggest that it's getting lost in all of the other
activity, but
it stands out in my mind as something that is very much missing from
what we wanted to make happen. I'm hoping that some of the plugin devs
might be interested enough to chip in, as it is in their own interests
to have a good plugin API from start to finish.
-kdf

[MickeyG]

On 13-Jul-07, at 3:21 PM, MickeyG wrote:
>
> Thank you also for the insight on how the community works. As a newbie
> here, I appreciate that. I have no problem being the guy that helps
> everyone move in the same direction or encourage developers to focus on
> the needs of the community at large.
>
I think the process worked fairly well with 6.5.3. Bugs got selected
in a targetted grouping and it got out relatively quickly.
It's a bit easier when it's a bugfix release. 7.0 is really going to
need extra help, so the trick will be to bring more newbies in
and on task. There are lots of folks more than happy to offer ideas,
and some who will even dive into code.

The plugin API is shaping up nicely, but it really needs an installer
UI. I hesitate to suggest that it's getting lost in all of the other
activity, but
it stands out in my mind as something that is very much missing from
what we wanted to make happen. I'm hoping that some of the plugin devs
might be interested enough to chip in, as it is in their own interests
to have a good plugin API from start to finish.
-kdf

I was very impressed with the organization and discipline exhibited by the community with 6.5.3.

I have heard a few times that a "Firefox-like" plugin installer is what's needed for 7.0. I think that's very high on the wish list. But we're still in hiring mode at Logitech, and we only have just enough people to work on addressing the basics for 7.0.

It would be great if someone(s) from the community would jump in and create a plug-in installer UI. If not, I'm pretty sure it's not going to be in 7.0.

Anyone interested?

Mickey

[erland]

The plugin API is shaping up nicely, but it really needs an installer UI. I hesitate to suggest that it's getting lost in all of the other activity, but it stands out in my mind as something that is very much missing from what we wanted to make happen. I'm hoping that some of the plugin devs might be interested enough to chip in, as it is in their own interests
to have a good plugin API from start to finish.

Has anyone started to think/do anything regarding the installer UI ?
Has there been any discussion about how to do it besides "that it should use the same principle as Firefox extensions" ?

[MickeyG]

Has anyone started to think/do anything regarding the installer UI ?
Has there been any discussion about how to do it besides "that it should use the same principle as Firefox extensions" ?

Not that I'm aware of. Around here, it's been mentioned as a great model for 7.0, but there haven't been any technical discussions regarding implementation.

You could be first .... 8^)

Mickey

[kdf]

On 13-Jul-07, at 4:48 PM, erland wrote:
>>
> Has there been any discussion about how to do it besides "that it
> should use the same principle as Firefox extensions" ?
>
that's the model. the implementation wouldn't have to be a copy.
After all, slimserver isn't firefox.

However, in basic, it should be possible to enter a url in a field,
click install and the installer will download and extract the tar.gz
package to the Plugins folder. The user would then be informed that the
plugin is installed and that it will be active after a restart (the 'on
the fly' option just isn't going to be workable with the new API, as it
isn't really workable now)

The server settings page has buttons for enable/disable and uninstall.
These need to be activated as well.

Plus, some sort of upgrade notification, etc etc.

That's what I recall from initial discussions. Currently, a packaged
plugin can be extracted manually to Plugins, but anything better than
this is welcome.

-kdf