Re: [Evolution-hackers] GNOME 3.0 - Evolution plans & IRC team meeting

["P Chenthill" <pchenthill novell com>]

I will not be able to attend the irc meeting today. But the following
log has the discussion we had on Wednesday night in the channel. My
opinions are put in there. It would be good if its taken into account
while discussing this in the meeting.


- Chenthill.
On Tue, 2009-06-23 at 22:47 +0530, Srinivasa Ragavan wrote:
> Guys,
> 
> We have made some proposals to the release-team on GNOME 3.0 plans for
> Evolution. Specially release/scheduling specifics. Read through the
> thread.
> 
> http://mail.gnome.org/archives/release-team/2009-June/msg00018.html
> 
> We'll probably workout the exact schedule/decision.
> 
> I wanted to discuss this in tomorrow irc team meeting. But due to my
> busy schedule and tight meetings tomorrow, I won't be able to make it,
> and I want to post-pone the team meeting to thursday (UTC 10:00) just
> this time. Sorry, if this is a late notice.
> 
> Try to make it or keep me informed if you have some
> suggestions/thoughts. TIA.
> 
> -Srini.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Evolution-hackers mailing list
> Evolution-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers


<seb128> srag: hi
<seb128> srag: you 2.26 to be 2.28 and 2.27 to be unstable is a very not cool idea!
<seb128> your 
<seb128> srag: it basically means "let's screw all those who track GNOME 2.27 and have already updated to 2.27.n"
<xkahn> !  The final composer addressbook bug seems to be related to whether the data has finished loading when you press enter.
* nxvl has quit (leaving)
<srag> hey seb128 
* cosimoc (~cosimoc jalfrezi collabora co uk) has joined #evolution
<xkahn> no...  I can't reproduce...
<xkahn> :(
<srag> but do you think 2.28 will be stable with eds/dbus port and KB merging? or delaying that would stabilize 3.0 ?
* nxvl (~nxvl 200 106 87 231) has joined #evolution
* tbf__ has quit (Read error: 145 (Connection timed out))
* nxvl has quit (leaving)
<srag> seb128, but do you think 2.28 will be stable with eds/dbus port and KB merging? or delaying that would stabilize 3.0 ?
* You are now known as chen
* nxvl (~nxvl 200 106 87 231) has joined #evolution
<andre> if current 2.27.x is stable enough and does not contain dbus-port and kill-bonobo it should become 2.28. evo should branch very early (soon) for 2.29.x and get dbus and kill-bonobo in.
<andre> but i think that's discussed by the evo team
<andre> seb128, ^^
<chen> yes, i would like to see if we can get a window for three major things lined up for calendar along with older patches (which I have noted in my release machine),
* tbf (~mathias dslb-088-067-108-091 pools arcor-ip net) has joined #evolution
<chen> * cache rewrite - http://www.go-evolution.org/CalendarStore ,
<chen> Gsoc eds optimization patches and google calendar replaced by caldav at the backend 
<andre> so who maintains the addressbook and can finally review 556061?
<srag> andre, chen but that leaves master out of testing for quite some time.
<chen> my other worry is many good patches which inbolves more changes have not been taken into trunk. i just heard from mcrha early w.r.t caldav which we need to look at..
<srag> its as simple as merging late.
<chen> srag, so if these are covered, i have no issues :)
<andre> srag: well, distros are free to package master for testing
<srag> chen, the patches ?
<andre> kill-bonobo is available for fedora
<andre> ubuntu can also package it
<hggdh> er
<andre> er?
<chen> srag, i have noted some which break freezes, but really good to have. I have the list on another system in office. i can mail them across
<chen> as a reply back to thread..
<srag> andre, but honestly, people won't use it, unless its the *official* version
<hggdh> andre, yes, I guess we could. But it will be a PPA release, not a main
<srag> chen, we can take up that.. not a problem.
<andre> hggdh, sure
<srag> andre, Im fine to have both 2.27.x and 2.26.x released till 3.0 comes out..
<chen> but have not covered the patches which have not committed in stable. i think all individual maintainers have to look at the patches on the components to just ensure..
<andre> srag, encourage people to do so
<hggdh> srag, the issue is we already delivered 2.27.3 to Karmic, going back will be a pain
<andre> there's blogs and mailing lists.
<srag> hggdh, if its a matter of version, we can work that out.. cache shouldn't be a problem.
<srag> hggdh, but I understand your issue 
<andre> that's why i currently also favor making 2.27.x -> 2.28.x and branch very early (and to be very conservative for 2.27.x for the rest of the time)
<srag> andre, right, I love that proposal really, but Im afraid, it would miss the good amount of testing that can happen if its called 2.27.x :(
<hggdh> andre, +1
<andre> srag, what is "it"?
<srag> the master branch 
<srag> Im trying to recall something that happened with gdm, dont know the exact releases/numbers
<andre> archlinux and debian still ship gdm 2.20 in their current unstable
<andre> i don't think it's that similar though
<srag> not similar, but would be great, if distros ship 2.27.x and together with 2.26.0 for stability reasons
<srag> It could be stupid though, but I think just a discussion could point out some new direction, where the master gets tested well.
<chen> i may be wrong in the following perspective but let me put it,
<andre> if 2.27.x become very very unstable (that's what i call it when merging dbus and KB) it's too late in the cycle anyway
<andre> it's one month until freezes start
<chen> I would love more community testing for bonobo stuff. but we need ensure we find all the bugs and fix it in our unit testing and internal qa. Once we ensure all things are working from our side. It would be good to push it to the community and get the un-identified bugs ..
<andre> yes. distros can do that
<chen> so it means we are delivering a quality product and not expecting the community to face the issues which could have been identified by us. And i really like mbarnes providing rpms from the kill-bonobo branch for testing. I will also provide some testing effort over the eds-dbus port by getting some rpms using obs (opensuse build service) and using those rpms for testing. 
<srag> andre, honestly, KB & dbus port shouldn't break any freezes. neither UI nor API/ABI by design
<srag> so its not the freezes that bothers me but the stability and the amount of testing it undergoes
<andre> still everybody expects more or less stable software the later we get in the gnome release cycle
<hggdh> srag, I agree with stability. And I also worry about 2.27 + KB + dbus being potentially unstable
<srag> andre, which is where I wanted the 2.26.x series to help in.
<srag> andre, and honestly tracking 3 release cycles is gonna be a new pain. 
<mbarnes> chen: are you proposing we create a gnome-2-28 branch early and continue with 2.27 releases from -that- branch while master gets nuked by merges?
<srag> I can just help 2.26.x stabilize more, cherry pick from master and focus on GNOME 3
<chen> mbarnes, yes once we ensure things are stable, we can get the patches into master if we branch early
<chen> mbarnes, and provide rpms from master for distros for people to test
<mbarnes> that sounds sensible to me.  sounds the distro problem too
<mbarnes> *solves the distro problem
<mbarnes> so essentially, after branching bump master to 2.29.1 while the rest of gnome is still in the 2.27/2.28 cycle
<chen> yup we can choose to..
<srag> mbarnes, right, a neat proposal. but what scares me more is
<srag> when people start using 2.29.1 in ~september we could be very short of a testing cycle for what KB and dbus port needs to stabilize
<srag> honestly what it might turn out is just instea dof working on a branch called kb or dbus-hybrid you work on master.. which is not gonna be the mainstream thing till 2.29.x starts
* solsTiCe has quit (Ex-Chat)
<srag> which is something I wanted to avoid and create a more problems now and solve in the next 9+ months available.
<seb128> srag: sorry it's dinner time here but use whatever you have in 2.27 now to do 2.28
<seb128> and start early (ie now) on 2.29
<seb128> bbl
<srag> seb128, no worries
<srag> seb128, we can catch up later.
<chen> srag, we can still provide the rpms to interested people for testing and not force them to use what we give :) prolly will catch up on mailing list and irc tommorow, need to catch for some sleep..
<chen> good night all
<srag> chen, then you really don't have to branch out now..
<srag> we can aswell give the rpms from KB or dbus-hybrid
<chen> srag, its good to have the code in master soon though..
<srag> mbarnes, my aim is to have the master as the only focus point for next 9 months..
<mbarnes> my problem with the "merge-now, fix-later" approach is I can't handle the additional entropy from other committers
<mbarnes> not until the branch is feature-complete, at least
<srag> chen, the branch name doesn't do magic really, unless it gets tested by real users
<srag> mbarnes, chen  but I get your point  too, not that Im neglecting it.
<srag> we just need to look at all dimensions and take the call :-)
<srag> Im open for everything to look forward for a stabel Evolution/GNOME 3.0
<srag> s/stabel/stable
<mbarnes> I think once I get the calendar into a somewhat usable form I'll be okay with finishing the rest on master
<srag> mbarnes, right, I would say that calendar-not working is a blocker for the merge, once done, we can look at the pending/not working htings and merge post that
<mbarnes> I'm okay with that
<chen> srag, will discuss over tomorrow, a bit sleepy now
<srag> chen, cya