0.7.0 release preparation meeting minutes

[Ruben Vermeersch <ruben savanne be>]

Hi guys, a summary of the stuff that was discussed (log attached):

* F-Spot 0.7.0 will come on Wednesday June 17. There might be some
breakage in there but that's okay, it's a development release. There are
a lot of changes so breakage can be expected, but there's also a ton of
awesome stuff.

* Further 0.6 releases are unlikely, as there are such large changes in
0.7 that it might not be worth to spend much time on this.

* We will try to push out 0.7 development releases regularly (every 4
weeks or so), with the goal to stabilize towards the end of summer and
have a 0.8 release out in september (in time for Ubuntu 10.10 according
to Sebastian Bacher).

* After that we will adopt 6 month cycles. This means that after the 0.8
release, a new 0.9 cycle will be started. Further 0.8 releases will be
provided for distributions, at their request. A proposed release
planning will follow.

* The coming week will be spent on ironing out some of the breakage of
0.7. Lorenzo Milesi volunteered to work on type-to-tag in fullscreen.

* In the next cycle, we will focus on integrating Taglib# and the Hyena
ModelProvider facilities. This will allow us to fix a huge pile of bugs
and will lead up to things such as multiple sources and bring cleaner
internals. This in turn paves the way for new features (e.g.
geotagging), which will then be much easier to do with the more hackable
codebase.

* That does not mean we are restricting ourselves to just that, other
stuff is obviously welcome (and will happen). So go crazy, send those
patches! ;-)

* Mike Gemünde brought up the issue of our source tree organization,
which is less than stellar. We will gradually clean this up towards
something that looks similar to Banshee's folder structure.

* Before we do that, we will go over the open patches in bugzilla, to
see what's usable (and what not).

That's all from the top of my head. Let's make this happen!

15:02 @      rubenv | shall we give it a go?
15:02 @      rubenv | anyone around?
15:02 @      tigger | heyho.
15:03       palango | yeah.
15:04 @      rubenv | okay, so here's what I had in mind in terms of a "program":
15:05 @      rubenv | 1) look at the current state / 0.7.0 milestone and plan the release
15:05 @      rubenv | 2) discuss what we'll try to get done for 0.7.1
15:05 @      rubenv | anyone else has topics that should be discussed?
15:07        maxxer | i'm fine
15:07 @      rubenv | okay, let's go with that and if things come to mind during the talking, we can always add them in the end
15:08 @      rubenv | let's try to keep this quick
15:08 @      rubenv | ### 1) look at the current state / 0.7.0 milestone and plan the release ###
15:08 @      rubenv | so, there are *a lot* of changes in git
15:08 @      rubenv | so I think we should start thinking about releasing it
15:09 @      rubenv | as you can see on https://bugzilla.gnome.org/browse.cgi?product=f-spot
15:09 @      rubenv | I have created three milestones
15:09 @      rubenv | 0.7.0 (which will be the next release), 0.7.1 (the one after that) and 0.8.0 (longer term future)
15:10 @      rubenv | with 0.7.0 we're going into a major cycle of development releases, leading up to 0.8.0 (which will form the basis of a stable branch)
15:10 @      rubenv | so for now it's okay to have a bit of breakage here and there, but obviously we should try to avoid it
15:11 @      rubenv | do you guys think that's fine, or should we stabilize and continue on the 0.6 stable path?
15:11        maxxer | f-spot has been stuck for too long, let's give a shock ;-D
15:12       palango | sounds good for me too.
15:12        maxxer | at least with 0.7 out, there will be some more testers
15:12 @      tigger | we can think about doing a 0.6.x release now.
15:12 @      tigger | but I think the next one will definitely a dev-release.
15:12        maxxer | 063 has been released out with some important fixes..
15:13 @      rubenv | ?
15:13 @      tigger | but it doesn't cound for me, if it is  called 0.6.4 or 0.7
15:13        maxxer | 062 maybe? :-P
15:13 @      rubenv | we're currently at 0.6.2 :-)
15:13 @      tigger | ok, then 0.6.3
15:14 @      rubenv | to give an idea, this is the difference between current git and 0.6.2:
15:14 @      rubenv |  523 files changed, 18550 insertions(+), 37728 deletions(-)
15:14        maxxer | getting a 0.6.x release would mean piclking up selected patch, and test them...
15:14        maxxer | is it worth?
15:15        maxxer | then we'll have a lot of bugs for 0.6 which maybe are fixed already in 07
15:15 @      rubenv | okay, let's think a bit longer term
15:15 @      rubenv | what is the next ubuntu going to ship?
15:15 @      tigger | ;-)
15:15 @      rubenv | 0.6, or a .7 release?
15:15 @      rubenv | or are we going to try to push out a .8 release by then
15:16 @      rubenv | and do the really crazy stuff on a .9 track?
15:16 @      tigger | the decision for ubuntu is taken, or am I wrong?
15:16 @      rubenv | am not talking in terms of shotwell vs. ubuntu
15:17 @      rubenv | errr
15:17 @      rubenv | shotwell vs. f-spot
15:17        maxxer | i'll go straight for 07. and around ubuntu freeze, we'll see the point 
15:17 @      rubenv | when is feature freeze?
15:17 @      rubenv |  15
15:17 @      rubenv | 	
15:17 @      rubenv | August 12th
15:17 @      rubenv | 	
15:17 @      rubenv | Release Development Iteration 3
15:17 @      rubenv | 	
15:17 @      rubenv |  /!\ FeatureFreeze 
15:18        maxxer | 2m? already?
15:18 @      rubenv | yeah, we're already quite late in the cycle
15:18 @      rubenv | so here's a proposal
15:18        seb128 | rubenv, ubuntu ships whatever will be stable for septembre
15:18 @      rubenv | let's go full steam ahead on .7 (like maxxer said)
15:18        seb128 | which I guess is 0.6 there
15:19        seb128 | I doubt you will get 0.8 by september?
15:19 @      rubenv | and try to stabilize towards feature freeze
15:19        maxxer | i agree. 0.7 is not yet a dev branch, imho
15:19 @      rubenv | seb128: I'm planning to push out at least some unstable releases
15:19        maxxer | there are a lot of things to fix up, refine...
15:20 @      rubenv | seb128: but if we plan it, we should consider stabilizing towards the ubuntu release, so that you guys can go for .8
15:20 @      rubenv | it'd be a short cycle, but considering the things we have in git right now, it could be a shame to ship 0.6.2 in ubuntu maverick
15:21        maxxer | yes, also considering the fixes released for exporters
15:21 @      tigger | from that point of view. I'm fine.
15:21 @      rubenv | basically the choice is to do a short cycle until 10.10
15:21 @      rubenv | or a long cycle until 11.04
15:22 @      rubenv | from then on I'd like to do 6 month cycles
15:22 @      rubenv | seb128: when would you guys like to see stuff stabilised?
15:23        seb128 | we need a stable before octobre
15:23        seb128 | ie you should start on 0.7 early
15:23        seb128 | and aim at 0.8 by GNOME 2.32
15:24 @      rubenv | seb128: well, I plan to do 0.7.0 somewhere within a week, that's what we're planning right now
15:24        seb128 | also we will not have gtk3 by default so don't depends on it if you can avoid it ;-)
15:24 @      rubenv | we won't depend on it yet, given that GTK# 3.0 probably won't be there by then and we have some other distributions (suse) we need to take into account
15:25 @      rubenv | seb128: so if we aim for a very stable .8 release in september, it'd be good for ubuntu?
15:26        seb128 | seems great yes
15:27 @      rubenv | okay, everyone in favor of doing a .7 development cycle (like we are doing now) for 2.5/3 months (june, july, august) and try to stabilize from mid august / september on towards .8?
15:28 @      rubenv | then when that is out of the door, we branch of for a .9 development branch, from which we can backport stuff to .8 at the request of distributions
15:28 @      tigger | what are the features which should go in .8 ? (or is that just stabilizing?)
15:28 @      rubenv | and then we'd have 4-5 months of .9 development cycle
15:29 @      rubenv | tigger: so .8 would be the end result of hacking on the 0.7 track, anything that goes in there will be in 0.8 (obviously)
15:29 @      rubenv | the bump in version numbering from .7 to .8 indicates that we consider it stable
15:30 @      rubenv | so most of the crazy stuff will come now and near the later .7 releases we'll try to make sure it's solid such that we can push out .8
15:30 @      rubenv | the minute that one is out of the door, we'll start doing crazy stuff again for .9
15:32 @      rubenv | is this clear, any problems / questions?
15:32 @      tigger | I'm fine.
15:33 @      rubenv | okay, I'll make a tentative schedule and send it to the list soon, we can then discuss about it later on
15:34        maxxer | me too
15:34 @      rubenv | this is very important stuff :-)
15:34 @      rubenv | so, back to the present
15:34 @      rubenv | have you guys tested master?
15:34 @      rubenv | and reported all the bugs you encountered?
15:35 @      rubenv | and more importantly: do you think there are serious issues that need to be fixed before we can put it into a release (I can think of some)?
15:36        maxxer | i updated to master few days ago, but didn't use it exgtensively so far :/
15:37 @      rubenv | have you tried importing?
15:39        maxxer | notyet
15:39        maxxer | or i tried, from folder
15:40        maxxer | and worked
15:40        maxxer | did you fix jimmac's bug?
15:40 @      rubenv | no, that is one that needs fixing
15:41        jimmac | i have the card still so I can provide an image if needed
15:42 @      rubenv | jimmac: I will look into it very soon (unless someone else wants to do it sooner)
15:42 @      rubenv | https://bugzilla.gnome.org/buglist.cgi?query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;target_milestone=0.7.0;product=f-spot
15:42 @      rubenv | this is a list of bugs that are currently scheduled for 0.7.0
15:42 @      rubenv | we should probably decide which ones of those are *must fix* and which ones can be deferred to the next release
15:43 @      rubenv | okay let's make homework from this
15:44        jimmac | a simple rule of thumb - if it has jimmac in there somewhere it's a showstopper!
15:44 @      rubenv | have a look at the list, add those that are missing (set milestone to 0.7.0)
15:44             * | jimmac ducks
15:44 @      rubenv | jimmac: for the right amount of money, we can make that arrangement
15:45 @      rubenv | the one bug I wanted to talk about the most is this one:
15:45 @      rubenv |     	'add tag' context menu item too slow. totally kills workflow. 
15:45 @      rubenv | https://bugzilla.gnome.org/show_bug.cgi?id=620608
15:46 @      rubenv | should we restore the horribly unusable long list of tags? or add type-to-tag in fullscreen?
15:47        maxxer | i vote for the latest
15:47        maxxer | and I believe i can do some tests in the weekend
15:47        maxxer | to merge it
15:47        maxxer | merge... write
15:48 @      rubenv | okay, that would be great
15:49 @      rubenv | I also have a branch that changes duplicate detection https://bugzilla.gnome.org/show_bug.cgi?id=621066
15:50 @      rubenv | it'll bring database changes, but it'll also make import much faster, less memory hungry and make duplicate detection work
15:50 @      rubenv | it's mostly done minus the database migration code
15:51 @      rubenv | should we wait for that to release 0.7.0 or keep the potential breakage for 0.7.1 and focus on import bugfixing right now?
15:51        maxxer | i believe 0.7 will have some bugs... so why not keeping 0.7.1 for fixing those?
15:51        maxxer | for sure there will be a bugfix release
15:52 @      tigger | full agree. if it is out, we'll find more bugs ;-)
15:52 @      rubenv | so as long as we put a big fat "THIS IS A DEVELOPMENT RELEASE" warning in the release notes, it should be okay?
15:52 @      tigger | yes.
15:53        maxxer | right!
15:53 @      rubenv | okay
15:53        maxxer | well. it's not so much a dev release, right now... ;)
15:53 @      rubenv | proposal: let's spend a week more on the current code
15:53             * | maxxer bbiab
15:53 @      rubenv | fix a couple of jimmac bugs
15:53 @      rubenv | and possibly merge that code + type-to-tag in fs (maxxer)
15:54 @      rubenv | and push out 0.7.0 on wednesday June 17
15:54 @      tigger | agree.
15:55 @      rubenv | that means that if you're the kind of guy that hacks on big and crazy stuff (looking at you tigger), it'll be mergeable at the earliest next thursday
15:55 @      tigger | ;-)
15:56 @      rubenv | okay, raise complaints if you disagree, but I call that we're doing it like that ;-)
15:56 @      rubenv | let's go to the fun part and round up quickly:
15:56 @      rubenv | ## 2) discuss what we'll try to get done for 0.7.1 ##
15:56 @      rubenv | so tigger, what will be most doable soon, models or taglib#?
15:57 @      tigger | before we use the hyena models, we should replace DbStore with hyena's ModelProvider (ok the name is a little bit misleading)
15:57 @      rubenv | how much work is that?
15:58 @      tigger | not sure. I'll tell you, when its done ;-)
15:58 @      tigger | but in addition, taglib should also be doable for the .7.1
15:59 @      rubenv | we will need to be able to parse the most common RAW formats
15:59 @      rubenv | most of them are TIFF based though
15:59 @      tigger | what is the schedule for .7.1 ?
15:59 @      rubenv | let's say around 4 weeks?
16:00 @      rubenv | we can always adjust this rate of releases after .8, when we have 5 months of development time as opposed to 2.5 (6 weeks might be a better rate)
16:03 @      tigger | you prefer taglib?
16:03 @      rubenv | I want both right away :-)
16:04 @      rubenv | how far are you into the modelproviders?
16:04 @      rubenv | if that's coming along nicely: that first
16:04 @      rubenv | I can look into format support for taglib#
16:04 @      tigger | ok.
16:04 @      tigger | lets do it ;-)
16:05 @      rubenv | having taglib# will allow us to kill a ton of bugs and problems with the crufty metadata library
16:05 @      rubenv | and the models will make hacking so much nicer, which means we can move the program forward
16:05 @      tigger | hey, I did gif and png. You have to close the gap ;-)
16:05 @      rubenv | am also thinking of taking on the loading (part of my gsoc branch) and combining it with the mipmap experiments we did
16:06 @      tigger | would be cool. But should we wait until .8 with that?
16:06 @      tigger | it will be hard to stabilize too much changes.
16:07 @      rubenv | true, let's see how it goes
16:07 @      rubenv | we still have three and a half month though
16:10 @      rubenv | let me recap for a second:
16:10 @      rubenv | * 0.7.0 next wednesday
16:10 @      rubenv | * a couple of 0.7 releases in the next months (will propose schedule soon)
16:10 @      rubenv | * try to stabilize for a 0.8 release near the end of september
16:11 @      rubenv | * potential breakage in 0.7.0 allowed, it's a dev release anyway
16:11 @      rubenv | oh and * full-file dupe-detect + type-to-tag in fs might go in 0.7.0
16:12 @      rubenv | 0.7.1 is largely undecided + taglib# + models are short term goals
16:12 @      tigger | great.
16:12 @      rubenv | which will lead up to things like multiple sources and much cleaner internals
16:12 @      rubenv | which in turn will allow us to add features like geotagging etc
16:13 @      tigger | ok, I missed the opportunity to add a point to the discussion...
16:13 @      rubenv | no
16:13 @      rubenv | that opportunity is now
16:13 @      tigger | 3) folder structure
16:13 @      rubenv | what about it?
16:14 @      tigger | we should clean up our code organization a lot.
16:14 @      rubenv | ah you mean source code folder structure
16:14 @      rubenv | good point!
16:14 @      tigger | ;-)
16:14 @      rubenv | src/ is indeed a mess
16:14 @      rubenv | am all for it, but there's one problem
16:15 @      rubenv | https://bugzilla.gnome.org/page.cgi?id=patchreport.html&product=f-spot&patch-status=none
16:15 @      rubenv | all of these will break if we start moving things around
16:15 @      rubenv | question is: do we care?
16:15 @      rubenv | and what will we do with old patches?
16:15 @      rubenv | is there anyone who wants to look into those, sorting out the ones we need and the ones we don't?
16:19 @      tigger | ;-)
16:20 @      tigger | so I suggest the following. keep the files until .8 and move just the stuff around which is touched.
16:20 @      tigger | after that, we move around the remaining.
16:22 @      rubenv | so move files to their proper place if they are being edited?
16:22 @      rubenv | don't do a patch (changes) + a move in one commit though
16:22 @      rubenv | otherwise I can't review it
16:23 @      tigger | hm, good point.
16:23 @      rubenv | maybe we should just go through the patch list at some point
16:23 @      rubenv | and very quickly decide what's usable and what not
16:23 @      rubenv | do a "look at 10 bugs per day" kind of thing to get rid of them or to nominate them for inclusion
16:24 @      rubenv | anyway, regardless of how we do it
16:24 @      rubenv | I suppose you suggest we adopt something similar to the banshee naming scheme?
16:24 @      tigger | y.
16:24 @      tigger | also agree with the 10 bugs per day.
16:25 @      rubenv | okay
16:25 @      rubenv | should we have some guidelines on how to structure things into assemblies / namespaces?
16:27 @      tigger | I don't think that this guidelines will be kept.
16:27 @      tigger | we should think about moving the current stuff around.
16:27 @      rubenv | agree
16:29 @      rubenv | okay, let's come up with guidelines when we run into it
16:29 @      tigger | ok.
16:29 @      rubenv | session closed?
16:30 @      tigger | y.
16:30 @      rubenv | great, I will send a mail with some conclusions