headers
Fredy Yanardi | 1 Jul 03:29
Picon

Re: Permission Request to Backport a Desktop File Addition to kdebase 4.3

Hello Tom and Albert,

If that's the case, I'll surely follow the rule :)

Thank you,

Fredy Yanardi

On Wed, Jul 1, 2009 at 4:53 AM, Tom Albers <toma@...> wrote:
>
> Op Tuesday 30 June 2009 22:11 schreef u:
>
> > In my opinion we are too late in the process for new features, besides i'm not
> > sure if that'd need new strings to translate but then it would be a double no
> > from my side.
> >
> > Albert
>
> I agree with Albert, hard freeze is there for ages already. And it is on a very visible point in KDE, so we want
it properly tested before releasing it...
>
> Besides the plugins are released at the same time as konq, so that's no convincing argument.
>
> Toma
> --
> KDE Developer
> _______________________________________________
> release-team mailing list
> release-team@...
> https://mail.kde.org/mailman/listinfo/release-team
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Majewsky | 1 Jul 23:03
Picon
Gravatar

Re: [Kde-games-devel] Regression testing

Am Mittwoch 01 Juli 2009 19:28:51 schrieb Albert Astals Cid:
> > In the present case, we would NOT abandon Kolf.
> >
> > Rather we would abandon Qt 4.5 for now (i.e. hold it over till
> > KDE 4.4).
>
> Sadly it seems its a issue that's being ignored.

[I'm yet again pulling in release-team@ as my question is also directed 
towards them.]

What is if Kolf is not fixed in time? Everyone should agree that we can not 
ship software that is obviously broken (as in: absolutely unfunctional). Given 
the reaction on this topic (no one knows the reason, no one really has the 
time and/or desire to dig into this mess, and Kolf has no maintainer 
currently), it seems quite realistic that Kolf has to be removed from the 4.3 
branch.

My question is: What implications does that have on the timeline? Does removal 
of an application after RC1 imply RC2, or can we hold our schedule?

BTW I would also vote to also completely move Kolf 1.9 to tags/unmaintained, 
as I'm confident to get Kolf 2.0 ready in time for KDE 4.4. It will most 
probably not have as much features, but it would at least work. But that is 
another story which is not that urging.

Greetings
Stefan

P.S. Please keep both lists CCd.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Albers | 2 Jul 01:04
Picon
Favicon

Re: [Kde-games-devel] Regression testing

Op Wednesday 01 July 2009 23:03 schreef u:
> Am Mittwoch 01 Juli 2009 19:28:51 schrieb Albert Astals Cid:
> > > In the present case, we would NOT abandon Kolf.
> > >
> > > Rather we would abandon Qt 4.5 for now (i.e. hold it over till
> > > KDE 4.4).
> >
> > Sadly it seems its a issue that's being ignored.
> 
> [I'm yet again pulling in release-team@ as my question is also directed 
> towards them.]
> 
> What is if Kolf is not fixed in time? Everyone should agree that we can not 
> ship software that is obviously broken (as in: absolutely unfunctional). Given 
> the reaction on this topic (no one knows the reason, no one really has the 
> time and/or desire to dig into this mess, and Kolf has no maintainer 
> currently), it seems quite realistic that Kolf has to be removed from the 4.3 
> branch.
> 
> My question is: What implications does that have on the timeline? Does removal 
> of an application after RC1 imply RC2, or can we hold our schedule?
> 
> BTW I would also vote to also completely move Kolf 1.9 to tags/unmaintained, 
> as I'm confident to get Kolf 2.0 ready in time for KDE 4.4. It will most 
> probably not have as much features, but it would at least work. But that is 
> another story which is not that urging.
> 
> Greetings
> Stefan
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Majewsky | 2 Jul 09:43
Picon
Gravatar

Re: [Kde-games-devel] Regression testing

Am Donnerstag 02 Juli 2009 01:04:16 schrieb Tom Albers:
> I think this is up to the maintainer of kdegames to decide which is Matt
> Williams. If you are the maintainer of Kolf, I trust Matt to consider your
> opinion.
>
> If Kolf 2.0 is what is developed in trunk currently and it will be shipped
> in kde 4.4.0, there is no need to move stuff to unmaintained. That's for
> real dead apps. We can remove applications, there is no need for an extra
> RC in that case.
>
> Again, the module maintainer should deal with this, together with the app
> maintainer.

I forgot that the release-team usually does not follow the discussion here: In 
trunk is Kolf 1.9, its maintainer has resigned about a year ago. Around this 
time, I started work on Kolf 2.0, which is in playground/games/kolf-ng at the 
moment.

Greetings
Stefan
Permalink | Reply | 0 comments |
headers
Ian Wadham | 2 Jul 14:41
Picon

Re: [Kde-games-devel] Regression testing

On Thu, 2 Jul 2009 5:43:04 pm Stefan Majewsky wrote:
> Am Donnerstag 02 Juli 2009 01:04:16 schrieb Tom Albers:
> > I think this is up to the maintainer of kdegames to decide which is Matt
> > Williams. If you are the maintainer of Kolf, I trust Matt to consider
> > your opinion.
> >
> > If Kolf 2.0 is what is developed in trunk currently and it will be
> > shipped in kde 4.4.0, there is no need to move stuff to unmaintained.
> > That's for real dead apps. We can remove applications, there is no need
> > for an extra RC in that case.
> >
> > Again, the module maintainer should deal with this, together with the app
> > maintainer.
>
> I forgot that the release-team usually does not follow the discussion here:
> In trunk is Kolf 1.9, its maintainer has resigned about a year ago. Around
> this time, I started work on Kolf 2.0, which is in playground/games/kolf-ng
> at the moment.
>
Hello Tom and release team,

I do not think you are in possession of all the facts.  There is nothing wrong
with Kolf 1.9, currently in trunk/kdegames, except that it currently does not
have a maintainer.  A lot of work was done on it by the previous maintainer
and our artists to bring it up to KDE 4 standard.

Kolf 1.9 works perfectly fine with Qt 4.4 and has been working fine for
several years through successive releases.  It fails horribly with Qt 4.5,
which was introduced into KDE 4.3 at a rather late stage in the release
cycle.  Two other games (at least) are also affected by regressions in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Majewsky | 2 Jul 15:02
Picon
Gravatar

Re: [Kde-games-devel] Regression testing

Am Donnerstag 02 Juli 2009 14:41:07 schrieb Ian Wadham:
> I think there is a strong case for holding over Qt4.5 until KDE 4.4
> and no case for dropping Kolf 1.9, which is an innocent bystander.

The problem is that we break more apps by going back to Qt 4.4 (most 
prominently most of Plasma, as far as I know), as we break by staying with 
4.5.

Greetings
Stefan
Permalink | Reply | 0 comments |
headers
John Tapsell | 2 Jul 15:57
Picon

Re: [Kde-games-devel] Regression testing

2009/7/2 Stefan Majewsky <majewsky@...>:
> Am Donnerstag 02 Juli 2009 14:41:07 schrieb Ian Wadham:
>> I think there is a strong case for holding over Qt4.5 until KDE 4.4
>> and no case for dropping Kolf 1.9, which is an innocent bystander.
>
> The problem is that we break more apps by going back to Qt 4.4 (most
> prominently most of Plasma, as far as I know), as we break by staying with
> 4.5.

For what it's worth, ksysguard breaks in a minor painting way with Qt
4.5.  The graphs are not filled in.  This is purely a cosmetic
problem.
Permalink | Reply | 0 comments |
headers
Sebastian Kügler | 2 Jul 16:16
Picon
Favicon
Gravatar

Re: [Kde-games-devel] Regression testing

On Thursday 02 July 2009 15:02:48 Stefan Majewsky wrote:
> Am Donnerstag 02 Juli 2009 14:41:07 schrieb Ian Wadham:
> > I think there is a strong case for holding over Qt4.5 until KDE 4.4
> > and no case for dropping Kolf 1.9, which is an innocent bystander.
>
> The problem is that we break more apps by going back to Qt 4.4 (most
> prominently most of Plasma, as far as I know), as we break by staying with
> 4.5.

Yes, Plasma will show severe breakage with Qt 4.4. Lowering the requirement is 
not an option if we want a functional desktop shell.

In this case, I'd actually opt for removing kolf from the release. It's not 
ideal and painful, but as it seems, we have to decide between a broken Kolf 
and a broken Plasma, Kolf, with all due respect is less critical for most of 
our users.
--

-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Permalink | Reply | 0 comments |
headers
Mauricio Piacentini | 2 Jul 16:53
Picon
Favicon

Re: [Kde-games-devel] Regression testing

> Yes, Plasma will show severe breakage with Qt 4.4. Lowering the requirement is
> not an option if we want a functional desktop shell.
>
> In this case, I'd actually opt for removing kolf from the release. It's not
> ideal and painful, but as it seems, we have to decide between a broken Kolf
> and a broken Plasma, Kolf, with all due respect is less critical for most of
> our users.

You are correct, of course. Given this choice there is really no other option.
I tried to fix Kolf again today, but failed to understand why it has
broken. I know the kde-games community took a shared responsibility
for maintaining orphaned applications, and we are doing our best at
it. But it is difficult when a major piece of technology that is not
under our control keeps changing in subtle ways, and breaking our apps
at every 2 or 3 months.

Notice that I am not saying that the app is perfect to start with, but
if you look at the last releases each broke a different KDE game in a
subtle way.

And every time we had a problem in the last releases it was connected
to a change in QGraphicsView, which has been sort of a moving target.
KMahjongg and KGoldrunner, who used KGameCanvas, did not suffer from
this. Several games that used QGV did suffer at different times.
Kapman broke completely, then KMines. KPat had (might still have, I am
not following it) redraw issues, and Kolf is completely broken with no
change in our code. KBlocks exhibits weird drawing since version 1.0,
as I chose not to work around the bug that caused it with SVG
elements. These redraw and display issues accont for probably 50% of
our bug reports recently, if not more. All of this was understandable
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dirk Mueller | 4 Jul 18:32
Picon
Favicon

Re: rc2?

On Tuesday 30 June 2009, Pierre Schmitz wrote:

> We used to only put them into a testing or special unstable repository. If
> that's a problem we can hold any packages back until the official
> announcement.

Yes, you should not pour the packagers over hundreds or thousands of users 
before they're announced. It is fine to use them for testing/finding regressions 
by circulating it within a small group of people that you know know and that 
will help with debugging possible packaging issues vs upstream bugs. 

> Another idea: What about weekly snapshots within the RC stage and forget
> about the one week delay for distributions? This way you might get a lot
> more last minute feedback.

Well, so far there haven't been that many commits in the 4.3 branch, where 
weekly snapshots don't make sense yet. 

I suggest to do a RC2 on Tuesday (assuming that there is internet available 
during the KDE e.V. general assembly) and release them within a day or two. 

Greetings,
Dirk
Permalink | Reply | 1 comment |

Gmane