[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    KDE 3.0 / CVS HEAD branch
From:       Dirk Mueller <mueller () kde ! org>
Date:       2001-08-06 11:35:35
[Download RAW message or body]

Hi, 

Given the CVS branching in a KDE_2_2_BRANCH and HEAD by Waldo yesterday, I'd
like to outline the rules for the HEAD branch. 

The HEAD branch should continue to be the main working branch for all 
developers with CVS account. This is mainly a technical decision, because 
CVS is just the easiest way to handle in HEAD. 

However, many developers (including myself) want to move to Qt 3 asap. 
Doing such a switch today will cause too many problems (as too many things 
in kdelibs will break) and therefore scare the developers, who will therefore
 either switch to KDE_2_2_BRANCH or stop working with CVS at all. I'd also 
assume that there several developers out there that have some patches on disc
waiting for the CVS tree to be opened again. Last, but not least, I think 
there are several developers on holidays currently, including those Trolls 
that know most about the caveats of Qt 3's changes. 

I know that this is a difficult situation, so I'm asking everyone to have a 
bit discipline, given that we just branched for a 2.2 which will (as always) 
have enough bugs that we have to release a 2.2.1 (and maybe 2.2.2) to fix 
the most grave issues in the code.   

Therefore, I want to recommend the following guidelines:

- CVS HEAD is open again for binary incompatible changes. Please help
  in doing all the necessary changes to be able to maintain binary 
  compatibility (including adding new features) for a long time. That includes
  such trivial things like adding a Private-class pointer to all classes 
  which are external API, but also such difficult issues like (re-)designing
  a class in a way that it is extensible and flexible. There are some
  of "### KDE 3.0" marks in the source to indicate things that break
  binary compatibility. Right now is the right time to review these things
  and change them if they still make sense.

- CVS HEAD is open for new-feature commits. However I'd like to remind
  everyone that we have a KDE 2.2.1 release pending which will only consist
  of bugfixes. Therefore I'd ask everyone to focus on stability and  
  bugfixing first and never forget to backport bug-fixes to the 
  KDE_2_2_BRANCH (and to test them there as well). However, if you have
  a patch waiting on your harddisc, then this is the right time to commit 
  it (after discussing it with the maintainer of that code etc first). 

- CVS HEAD is open for i18n-string changes. However, to reduce the work
  for the translators, please keep unnecessary changes at a minimum. 

- CVS HEAD remains closed for source-incompatible changes. Any change
  that might seriously affect applications that use this API (mainly 
  kdelibs) at compilation or runtime (changed behaviour) has to 
  be posted to the appropiate mailinglist first and has to be approved. 
  Any source-incompatible change that is approved has to be fully documented
  in the KDE3PORTING document (which has yet to be created). If these
  rules are not met, then I'm forced to revert those changes. 

- The main Qt version for CVS HEAD branch is Qt 2.3.1. Patches are allowed
  to be included which make the code compileable with current Qt 3, given
  they met the following criterias:
      - they do not break any compilation or functionality of the code
        with Qt 2.3.1. 
      - the amount of #ifdef's etc is at a minimum. 
      - it is doing the "right thing". That means not stupidly making
        it compile with both Qt versions, instead just adapts the code to 
        reflect the changes in Qt 3 in an apropiate way. I'd recommend
        posting a patch therefore first for nontrivial things, but it
        is not required. 

I'd recommend and ask everyone to check out current Qt 3 beta and start a 
work on the port of the parts that can be separated well, i.e. the porting 
of the widget styles we have in CVS or of applications that use Qt 
functionality that is dropped in Qt 3.x comes to my mind. 

Please communicate to avoid duplicate work first and identify the "hot-spots"
and think about solutions. We know about the toolbar and charset problems 
already, but there might be more caveats. 

On about September, 1st, which is in about 3 weeks, I'd like to propose a 
switch to current Qt 3 beta in the CVS HEAD. I hope till then the major 
issues are addressed to make transistion for the developers in general 
easier and less functionality is broken and lost during the porting. If this 
timeline is too short, it has to be delayed, but in general I want to avoid 
a delay, so I'd ask everyone to help where they can. 

I hope there is no major disagreement with this proposal, so I wish KDE 3 
all the best and thank you for reading,


Dirk

[prev in list] [next in list] [prev in thread] [next in thread]