elease,
because this would mean less hassle for packagers and people upgrading
their systems, and also guarantee a smoother transition when the new
version is ready for 4.4.
Regards,
Mauricio Piacentini
___
release-team mailing list
release-tea
policy where applications that have stayed in the module with no
active maintainer for a given period of time need to be Q&A'd by the
module maintainer, if no one else steps up. If problems can not be
solved, they should probably be removed befo
t is already fixed in 4.5.2, just released? I
am at fisl and with a low bandwidth connection, can someone please try
it to verify?
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
as tidy as it could be, but it was still working
with all versions of Qt up to 4.4.
BTW, there are still some redraw bugs in KMines, introduced in Qt 4.5
as well. I am not sure what to do in that case as removing KMines is
not an option, and the bug does not appear to be ours... Dmitry, di
Thanks, Albert and Helio. Stanislas wrote to me that he followed the
thread, and will be moving Kamala to extragear when it is time,
following the kdereview process.
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
at the tree and could not find a suitable
directory, though. Should it be extragear/other, or extragear/misc?
We can later discuss then if our kdegames approach of letting lots of
games in is still valid, given this fact. Maybe we should consider
moving some to extragear/games, which does not exist
-selected sets of applications that
they could pick easily.
But we did not implement this, yet. Maybe it is time to do so? And maybe
with a provision for a place that applications like Kamala or your
Preventive Maintenance Schedule could live, knowing that they will be
tagged and released align
do what some do today: ship only the best 4, or 5, or 10 on
their distros. By the same reasoning, having something in kdetoys or
kdemisc or kdespecialinterest does not mean it has to be shipped by
every KDE distro: it just means it is released in
g ones seems suitable.
So... what now? kdetoys and kdeutils do not seem right. Kdeedu is
probably not good as well, as it is more geared towards sciences that
are part of the curriculum in most countries. Do we start a new module?
If we decide to do this, then maybe it could be a place for o
branch
(of course) and trunk will be updated again in the future, after the
release, right?
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
menus, right? At least it is what I am seeing here with pt_BR.
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
le maybe it could be moved to kdeutils or something.
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
d the decisions already made regarding this
topic
b) An offer to experiment with this in a non-mandatory module like kdegames.
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
cause (as you say) the decision was already made, is it?
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
this, I am against encouraging resource
wasting for a basic part of the system that has to run and be installed
by default.
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
kdereview/playground and be moved before the hard freeze on May?
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
e user.
The main drawback to consider is the burden on the release team, but
Dirk seems to agree that 6 months is doable.
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
interval for inclusion of new features and
applications in the main release seems too long, at least for me.
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
g on?
I think it is just lack of communication. I will update the
Module-Status page, but we (the kdegames team) were really working with
our Project Status page, and everything that is currently on the module
is going to be released.
Regards,
Mauricio Piacentini
___
h is confused by this
double negative, in answer to my already less-than-clear question :)
Do you agree with me, or not?
:)
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
leases or extragear.
This is something we should consider maybe, with feedback from TT.
And of course, everything will be magically better after 4.0 is out :)
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
o waste energy, we can delay this
discussion to January. The same applies to the Kompare issue: let us
follow the path that generates less stress for now, and move on to this
4.0 release.
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
it seems like
the modules and apps with active maintainers and release managers are
indeed in better shape compared with the ones that do not have one, so
it is apparently "a good thing" to require :)
Regards,
Mauricio Piacentini
___
releas
ill all start to flow again positively after the
release.
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
odule that will not have
their apps in 4.0 because they missed the July cut, and stick by the
schedule.
To finish, I also think we really need to get this 4.0 thing out, as we
are stressing about smaller things almost daily :)
Regards,
Mauricio Piacentini
_
this Friday. We have
a KDE Games team meeting on this Thursday (IRC) and I have added this
item to the agenda. To speed up discussion, a short list of names:
Konnect4
KonnectFour
KAlign4
KFourInLine
K4InLine
I think I prefer the "Four" format instead of the numeric "4"
The click bug in lskat is fixed in revision 74772, no need to revert.
Apaku, thanks for finding it.
Which reminds me: we (kdegames) really need to do a through check of all
applications. A topic for our next meeting, this Saturday.
Regards,
Mauricio Piacentini
, but really... Come on people.
The goal is to get closer to a release, right?
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
onsideration for 4.0, as
it could potentially solve some xine-lib issues?
Regards,
Mauricio Piacentini
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
July).
As this is also when the string freeze occurs.
So each individual game could perhaps use this time to implement a
missing feature, but we would not add new games to the module after June
1st.
Regards,
Mauricio Piacentini
___
relea
31 matches
Mail list logo
