Re: [Banshee-List] Developers: Gearing up for 1.5.0

["Andrés G. Aragoneses" <knocte gmail com>]

Aaron Bockover wrote:
> First to report on the GIT migration. Unfortunately it has not gone well
> for us. I have little information on what exactly has gone wrong and
> when it will be fixed. Here's what I do know:
> 
>   a) Our tags and branches were improperly migrated, possibly losing all
> history other than the last commit
> 
>   b) The 'master' branch was properly migrated, and it's /more than
> likely/ safe to be pushing to this branch.
> 
> With (b) in mind, let's not block any longer on pushing here. If there
> is a problem, we will make sure that no commits are lost, even if we
> have to rebase from svn again. Everyone just make sure you are always up
> to date so we at least have distributed backups :)
> 
> Also, please make sure you use a proper git workflow where you make
> fairly fine-grained commits (not necessarily pushing) that cover a
> specific feature (or logical subset thereof) or bug fix. Do not make
> commits that cover 800 different unrelated changes.
> 
> With this commit mentality, we do not need to use the ChangeLog any
> more. Commit messages should be of this form:
> 
> [One short sentence/line description of the commit]
> [blank line]
> [Multi-line detailed description of the commit]
> 
> Please do not use a period at the end of the short description (first
> line).
> 
> Now for 1.5.0:
> 
> We would like to release soon, but there are a number of stability and
> possible data issues that I will block the release on. These must be
> addressed first.
> 
> I created a 1.5.0 milestone in bugzilla, and would appreciate it if bugs
> that need to be fixed for this release marked as such (set target to
> 1.5.0) and have proper priority and severity. Any data loss or major
> crashes (regressions from 1.4.3) should be marked as "BLOCKER" for the
> 1.5.0 target.
> 
> These two are specifically on my radar:
> 
>  - http://bugzilla.gnome.org/show_bug.cgi?id=580044
>  - http://bugzilla.gnome.org/show_bug.cgi?id=579370
> 
> Additionally, there was some serious performance regression from 1.4.x
> due to the SQLite provider switch. Some of this performance has already
> been gained back (thank you Bertrand and Gabriel), and Gabriel has
> started working on a performance test suite so we can track future
> regressions (but hopefully improvements!). 
> 
> We must keep performance in mind, and I would really like to see 1.5.0
> fully on-par or better than 1.4.3 performance wise. 
> 
> I would like us all to keep the fantastic WebKit performance mantra in
> mind whenever changes are made:
> 
> "The way to make a program faster is to never let it get slower."
> 
> I would further encourage all developers to read their page on
> performance: http://webkit.org/projects/performance/index.html
> 
> When the performance suite is more complete, I would like to fully adopt
> the WebKit policy - any performance regressions must be fixed or
> reverted immediately.
> 
> Additionally, I would like to stress that we should not be introducing
> breaking changes in the database (or APIs, though we can have some more
> flexibility here). That is, databases created with 1.5.x should work
> reasonably with 1.4.x. There should not be many compelling reasons to

Would that mean that we cannot land a patch for this bug?:

http://bugzilla.gnome.org/show_bug.cgi?id=563630


> introduce breaking changes, and any that arise must be discussed
> thoroughly. 

The reason I think this is important enough to break DB backwards
compatibility is that this use case (which IMO is very usual around any
music collection holders is broken):

* A user has a music collection in folder /X
* Above X, he has some folders (genres): /X/Rock , /X/Jazz , ...
* The user wants to create a smart playlist that only contains stuff
from the "Rock" folder: he uses the File Location field.

Current (bad) results: Songs that contain the word "Rock" in the file
name (because of their title or artist) get added in this smart play list.


> Finally, everyone should be testing and developing against Mono 2.0.1,
> especially if you are using C# 3.0/LINQ features. There are still issues
> in Mono 2.0.1 with these features that otherwise work well on Mono 2.4.
> We will take on a Mono 2.4 requirement in 6-12 months.
> 
> So let's get the 1.5.0 bugs in shape, and release soon!
> 
> Thank you everyone for your hard work and dedication. You are much
> appreciated.

Keep up the good work!

Thanks,

	Andrés

--