On Friday 14 December 2007, Andreas Pakulat wrote:
Are you sure about that? I don't know how SuSE or RedHat and others do
their releases but I'd expect them to need at least 2 or rather 4 weeks
after a KDE 4.1 release until its patched up/fixed for inclusion in the
next release. So if the next
I agree to Mauricio's points, we should do a 'relatively quick' 4.1, then
try to move into a time-based release schedule.
End January: Lifting feature freeze for trunk/
End of March: (feature/string) freeze trunk/
Mid May: KDE 4.1
I fully agree with Sebas here: What we need most right now
On 14.12.07 15:49:24, Cyrille Berger wrote:
On Friday 14 December 2007, Andreas Pakulat wrote:
Are you sure about that? I don't know how SuSE or RedHat and others do
their releases but I'd expect them to need at least 2 or rather 4 weeks
after a KDE 4.1 release until its patched up/fixed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 13, 2007, at 5:49 AM, Sebastian Kuegler wrote:
On Thursday 13 December 2007 12:35:29 Mauricio Piacentini wrote:
I think we might want to bump pretty quickly to a 4.1 release and
that's when we can enable it again (and move some games and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 13, 2007, at 5:53 AM, John Tapsell wrote:
+1 vote for not including and having a 4.1 release within 3-4 months
of 4.0. I think everyone can be satisfied with that.
I'm not. :P You get basically two months to develop and add new
features
On 13.12.07 07:10:20, Matt Rogers wrote:
On Dec 13, 2007, at 5:53 AM, John Tapsell wrote:
+1 vote for not including and having a 4.1 release within 3-4 months
of 4.0. I think everyone can be satisfied with that.
I'm not. :P You get basically two months to develop and add new
features
On Thursday 13 December 2007 14:08:32 Matt Rogers wrote:
How do people feel about this as rough planning?
How about starting a new thread for it instead?
Good call. I'll post a more thought-through proposal shortly.
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
I'm not. :P You get basically two months to develop and add new
features and that's quite crazy. If we do this, you once again leave
out KDevelop and kdewebdev from the release because i don't think
those are going to be ready in 3-4 months. You also leave out a
significantly better
On Thursday 13 December 2007 16:59:16 Mauricio Piacentini wrote:
Well, I think that *AFTER* 4.0 it is wrong to continue doing
feature-based releases, and we could experiment a bit with
schedule-driven ones. If it is 3 or 4 or 6 or 8 months it is open for
discussion. But the basic idea is:
Aaron J. Seigo wrote:
of course that's what we always used to do. 2.0 and 4.0 have been the only
two
exceptions i can think of since i've been around the project.
Yes, this was something we talked about during last Akademy, when there
was the suggestion to move to 6 months cycle. We already
Aaron J. Seigo wrote:
If something can not be
done in 3 months, it is doubtful that it would be ready in 4 or 5, at
least in the open source world, right?
i haven't seen that to be the case, no.
The half of my brain that almost understands English is confused by this
double negative, in
On Thursday 13 December 2007 18:25:16 Aaron J. Seigo wrote:
After 4.1, we should probably experiment with the 6 month release
schedule that seems to be working for other projects,
for certain values of working. for at least one major project, there
was an immediate and noticeable decline in
On Thursday 13 December 2007 18:43:53 Mauricio Piacentini wrote:
i'd sooner see us (loosely) sync along with the Qt dev cycle (which has
become much more regular, ~9 month per release) to keep a steady flow
of feature / bug fixes going between KDE and Qt.
Ok, keeping a pace with Qt
Excellent. Great News!
Then I suggest you:
1) commit your patches into kdesdk/kompare
2) uncomment the add_subdirectory(kompare) line in kdesdk/CMakeLists.txt
I need SVN commit access for that first.
Oh,... but before doing that... any idea how many new i18n() strings are in
your
Op Tuesday 11 December 2007 03:14 schreef u:
If Kevin wants to take over maintenance, that's fine, but making
Kompare ready for KDE 4.0 seems like a goal not reachable considering
when the release is going to be.
Hi Matt,
Seeing the recent mail about the current state of Kompare from
On Tuesday 11 December 2007 05:08:09 Tom Albers wrote:
Op Tuesday 11 December 2007 03:14 schreef u:
If Kevin wants to take over maintenance, that's fine, but making
Kompare ready for KDE 4.0 seems like a goal not reachable considering
when the release is going to be.
Hi Matt,
Seeing the
On Tuesday 11 December 2007 14:10:36 Matt Rogers wrote:
On Tuesday 11 December 2007 05:08:09 Tom Albers wrote:
Op Tuesday 11 December 2007 03:14 schreef u:
If Kevin wants to take over maintenance, that's fine, but making
Kompare ready for KDE 4.0 seems like a goal not reachable
On Tuesday 11 December 2007 20:40:38 Allen Winter wrote:
On Tuesday 11 December 2007 10:07:09 Sebastian Kügler wrote:
On Tuesday 11 December 2007 14:10:36 Matt Rogers wrote:
On Tuesday 11 December 2007 05:08:09 Tom Albers wrote:
However, seeing as the change has already been made,
[EMAIL PROTECTED] wrote:
I'm with Matt here, as much as i'd love a kompare on KDE 4.0 we began
removing
unmaintained games and not allowing new ones in kdegames quite a time
ago,
actually when the schedule said so, so if we had applied the the same
rule to
kdesdk, kompare would have
A Dimarts 11 Desembre 2007, Allen Winter va escriure:
On Monday 10 December 2007 18:04:16 Kevin Kofler wrote:
In Bug 153463 [1], Kevin Kofler provides some patches to make the
current Kompare code in kdesk compile (and work, I guess).
It definitely works here, at the very least. :-)
On Monday 10 December 2007 18:18:04 Kevin Kofler wrote:
Excellent. Great News!
Then I suggest you:
1) commit your patches into kdesdk/kompare
2) uncomment the add_subdirectory(kompare) line in kdesdk/CMakeLists.txt
I need SVN commit access for that first.
Ok, I committed your
On 10.12.07 18:13:20, Allen Winter wrote:
On Monday 10 December 2007 18:04:16 Kevin Kofler wrote:
In Bug 153463 [1], Kevin Kofler provides some patches to make the current
Kompare code in kdesk compile (and work, I guess).
It definitely works here, at the very least. :-)
Kevin,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 10, 2007, at 4:50 PM, Allen Winter wrote:
Howdy,
Kompare currently isn't being built in kdesdk.
In fact, the kdesdk/CMakeLists.txt file has this line:
MESSAGE(STATUS Kompare from the branches/work/kompare/3-way-
kompare will replace \
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 10, 2007, at 5:16 PM, Albert Astals Cid wrote:
A Dimarts 11 Desembre 2007, Allen Winter va escriure:
On Monday 10 December 2007 18:04:16 Kevin Kofler wrote:
In Bug 153463 [1], Kevin Kofler provides some patches to make the
current Kompare
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 10, 2007, at 6:04 PM, Allen Winter wrote:
On Monday 10 December 2007 18:18:04 Kevin Kofler wrote:
Excellent. Great News!
Then I suggest you:
1) commit your patches into kdesdk/kompare
2) uncomment the add_subdirectory(kompare) line
25 matches
Mail list logo
