Hello,
Finally it is time to start working on 2009
First, exchanging ideas.
Judging by the release schedules of the most important packages that
we are bound to, and the release of Pardus 2008 in June, I have tried
to shape up the release schedule for Pardus
2009.
We will be using KDE4 as the default desktop environment for 2009. Wth
the 4.1.x releases, KDE has made big improvements on stability and
performance, but unfortunately lacks some components important for us
as in features (complete power management, printer management system
etc.) and in technical aspects (plasmoid python bindings etc.). That is
why I decided we should wait for 4.2
series.
First of all, we are porting all of Pardus managers to KDE4. This semi
re-write will be a chance for us to clean up the code and make the GUI
and processing code more contained in their own files. This will make
the maintenance easier, allow us write small toys (plasmoid based for
example) using the managers' code easier, and make the life of
developers who would like to write other GUI's doing the same job for
other desktop environments (XFCE for example.).
By checking out the release dates of main packages of Pardus, it looks
like the latest will be KDE 4.2, which is announced [1] to be released
end of January 2009. In KDE's release schedule system, minor updates
are usually done in 2 month periods. For the unforeseen last minute
fixes, to have enough time for testing, I am planning on releasing
Pardus 2009 at the end of March or the begining of April 2009, with KDE
4.2.1. I am not sure about the strict release dates now, I will decide
the exact dates due to how we progress on the 2009 road and announce.
About base / critical packages;
- We will be using Python 2.6.x series and will not switch to 3K. This
way with the warnings, we will have time to pinpoint what needs to be
removed / changed for 3k.Since we are using lots and lots of Python
everywhere, I believe we don't need a big Python adventure yet.
- Till the release of 2009, it seems there won't be major changes in
GCC/GLIBC/Binutils. I am planing to keep GCC at 4.3.x, and use stable
enough glibc / binutils snapshots and stabilize them on the way. Same
goes for other system.devel tools (auto*) too.
- We need to be as "up to date" as possible with kernel, but the point
of settlement will be decided by the package maintainer. Some
kernel.drivers packages have beenput into mainline kernel, and
developement of some of these packages outside the kernel has stopped.
We will decide together which package we will keep as seperate package
and which drivers will be used in kernel.
- Version of Xorg which will be used in 2009 will be decided by the
Xorg maintainer, Fatih.
One of the main advantages of 2009 will be that we won't have to do a
major API/ABI breakage. This will give us developers the advantage to
do our developement for 2009, within 2008. Until the beta, all API/ABI
breakage is good to go. After beta, we will be discussing on situations
when we need / want to break. After RC, unless it will ve a critical
necessity, ABI/API breakage is forbidden
With 2009, my wish is that debug packages and delta packages will be
summoned. Probably it will happen long before 2009, and may rise within
2008 repos, decision is Ekin's. Right now Ozan, Faik and Ekin are
working on the subject.
After we decide what will be done and by whom, there will be a wiki
page again displaying the progress status. This time we will also have
percentage charts for the progress of packages be ready for 2009 too.
Especially for users who will be updating from 2008 to 2009, we need to
make sure all packages are ready on the day of the 2009 release.
Within December I am planing to warm up the 2009 farm and svn repo.
We have a lot of time (and a lot of things to do) till the release of
2009. We must find our weak spots, figure out unmaintained tasks /
technologies / packages and we must share the work together so we don't
have any unmaintained holes left. I see this period as a great chance
to step up higher in Pardus' technological status and to fix bugs,
please use this chance as efficient as possible
Comments, suggestions, questions ?
[1]
http://techbase.kde.org/Schedules/KDE4/4.2_Release_Schedule
Author