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 
<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 (~cosi...@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 (~n...@ 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 (~n...@ 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 (~math...@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* 
<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 
<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 
<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 
<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
Evolution-hackers mailing list

Reply via email to