Post 2.0.0 release plan discussion

[Big O]

On Sun, Nov 23, 2008 at 9:55 PM, Dan Meltzer
<parallelgrapefruit at gmail.com> wrote:
> 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)
yay

>
> 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)
As I'm interested in these two i'll help out as I'm able and time permits.