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
srag: hi
srag: you 2.26 to be 2.28 and 2.27 to be unstable is a very not cool
idea!
your
srag: it basically means "let's screw all those who track GNOME 2.27
and have already updated to 2.27.n"
! The final composer addressbook bug seems to be related to whether
the data has finished loading when you press enter.
* nxvl has quit (leaving)
hey seb128
* cosimoc (~cosi...@jalfrezi.collabora.co.uk) has joined #evolution
no... I can't reproduce...
:(
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...@200.106.87.231) has joined #evolution
* tbf__ has quit (Read error: 145 (Connection timed out))
* nxvl has quit (leaving)
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...@200.106.87.231) has joined #evolution
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.
but i think that's discussed by the evo team
seb128, ^^
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
* cache rewrite - http://www.go-evolution.org/CalendarStore ,
Gsoc eds optimization patches and google calendar replaced by caldav at
the backend
so who maintains the addressbook and can finally review 556061?
andre, chen but that leaves master out of testing for quite some time.
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..
its as simple as merging late.
srag, so if these are covered, i have no issues :)
srag: well, distros are free to package master for testing
chen, the patches ?
kill-bonobo is available for fedora
ubuntu can also package it
er
er?
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
as a reply back to thread..
andre, but honestly, people won't use it, unless its the *official*
version
andre, yes, I guess we could. But it will be a PPA release, not a main
chen, we can take up that.. not a problem.
hggdh, sure
andre, Im fine to have both 2.27.x and 2.26.x released till 3.0 comes
out..
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..
srag, encourage people to do so
srag, the issue is we already delivered 2.27.3 to Karmic, going back
will be a pain
there's blogs and mailing lists.
hggdh, if its a matter of version, we can work that out.. cache
shouldn't be a problem.
hggdh, but I understand your issue
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)
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 :(
andre, +1
srag, what is "it"?
the master branch
Im trying to recall something that happened with gdm, dont know the
exact releases/numbers
archlinux and debian still ship gdm 2.20 in their current unstable
i don't think it's that similar though
not similar, but would be great, if distros ship 2.27.x and together
with 2.26.0 for stability reasons
It could be stupid though, but I think just a discussion could point out
some new direction, where the master gets tested well.
i may be wrong in the following perspective but