Post 2.0.0 release plan discussion

Dan Meltzer parallelgrapefruit at gmail.com
Mon Nov 24 03:55:07 CET 2008


On Thu, Nov 20, 2008 at 12:38 PM, Lydia Pintscher <lydia at kde.org> wrote:
> On Thu, Nov 20, 2008 at 6:15 PM, Nikolaj Hald Nielsen
> <nhnfreespirit at gmail.com> wrote:
>> markey, lfranchi and I had a discussion about how to handle the first
>> few releases after 2.0.0 that I think it makes sense to summarize here
>> so others can comment.
>>
>>
>> The main point is that we should do a number of very fast 2.0.x bugfix
>> releases. A sane proposal would be do to 2 3 week release cycles ( 2
>> weeks development, 1 week freeze ) for 2.0.1 and 2.0.2. This will
>> allow us to quickly respond to the worst bugs that show up after the
>> final is released.
>>
>> The main point of discussion is how to handle trunk, and when to
>> branch off the 2.0.x branch. There was agreement that at the very
>> least, 2.0.1 should be developed in trunk. This is simply to encourage
>> people to help out with fixing the worst bugs rather than go out and
>> start implementing huge new features (I know that we are all itching
>> to do this, I have several projects lined up that I cannot wait to get
>> started on, but handling the worst bugs now will save us a lot of time
>> and trouble later). Personally, I currently think that it makes sense
>> to do 2.0.2 in trunk as well (but this might change depending on the
>> number and severity of bugs and how 2.0.1 turns out) others think we
>> should branch off right after 2.0.1.
>>
>> The main point of this though, is that we need to set some fixed dates
>> for freezes and releases so that these first 2 releases do not drag
>> out.
>
>
> Ok, before we decide on how we are going to do it we should decide on
> what we are going to do.
> So first of all please everyone let me/us know about their post 2.0
> plans. No bikesheding and/or discussion here! Just tell what you want
> to work on. Brainstorming! Everything is allowed.
> Once we have that we can see how we are going to to this and when. I
> can make a rough proposal once everyone wrote down their plans and
> then we can discuss it. This also makes it a lot easier to draw up a
> timeline to stick to.

Some of my plans (If I get around to fixing my laptop so that I can
hack happily...

1) Reducing the size of amarok's sources (Some of this is easy..
bumping the kde dep to 4.2 so we can punt our own libplasma and the
encoding stuff, but I'd also like to look into packaging the script
generator separatly so that a clean rebuild of amarok does not require
a clean rebuild of all this stuff)

2) Collection Browser Improvements: Showing the first letter in the
view, and separating by that (like 1.4 allowed)... Cleaning up the
toolbar above hand.

3) Solving the Edit Filter Dialog... This needs an entire rewrite most
likely, but it really needs some love.

4) ++tipsandthis. I'm thinking I'll go on a crusade to add tooltips
(and maybe whatsthis's) to all parts of the gui that should have them.
 This is probably a rainy day type of project (or maybe we should farm
it off as a JJ)

5) Video.  Figure out the smartest way for video playback... If phonon
doesn't solve video-on-canvas by 4.2 (I don't think it has) then I'll
probably make the center a stacked widget that shifts from the context
view to a video widget if the media source has video (with an escape
button for people that want to see the CV)... will need some
exploration

6) Classical playlist view:  I may work on this some, sometimes the
columns would be extremely helpful (but it's a longterm goal of mine,
to be sure)

Probably a few other things here and there... I have a feeling most of
my goals would be for 2.1 rather than 2.0.anything, with the exception
of maybe the editfilter dialog and the collection browser improvements

Dan,
>
>
> Cheers
> Lydia
>
> --
> Lydia Pintscher
> Amarok community manager
> kde.org - amarok.kde.org - kubuntu.org
> claimid.com/nightrose
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>


More information about the Amarok-devel mailing list