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

List:       kde-core-devel
Subject:    Re: RFC: Life beyond 2.0
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-08-28 0:52:16
[Download RAW message or body]

   Hi!

On Fri, Aug 25, 2000 at 02:33:22PM -0700, Waldo Bastian wrote:
> 1) During the 2.x series no more than 1 release will be made per month. A 
> release will contain at most 3 packages.
> 2) At _ALL TIMES_ a package shall only depend on packages that have been 
> released already. This also applies to packages in CVS.
> 3) A new release of a package may not break any other package that depends on 
> this package (backwards compatibility).
> 4) Bug-fix releases can be excempt from 1) if no change in the translatable 
> strings has occured and no change in the API has occured.

Sounds like a base to build on. The only real alternative would be splitting
everything in individual packages. But supposing we go with about this, then
the following issues come to my mind:

 * maximum "release wait" requirement

I think everybody agrees that releasing more often is a good idea. From my
personal experience with the old standalone ksynth/aRts releases, to stay
in touch with users of your software the optimal time span is about releasing
every two months. The problem is that if you report a bug or request an
improvement as user, and time drags on longer than this, you get increasingly
frustrated. Same is valid for developers who want their new stuff to be used.

 => I think besides a possible first come first serve wants-release-package
    queueing we should provide a way that package do get the "right" to
	release once every three months regardless whether all slots are filled.

 * sorting in music apps

When there are only packages to be released, a home has to be found for
the pure-music apps which are currently brahms and artstracker. They
definitely should be included in the regular releases ASAP. I've heard
complaints that people only wanting to listen to mp3's don't want to get
a sequencer like brahms installed each time. However, I also know that
keeping the package count down is essential, especially if the management
of releases is difficult (with time plans, multimedia apps).

 => Probably it would be okay to simply include brahms and artstracker in
    kdemultimedia and see if somebody complains.

 * ogg, divx, mod, ...

There is quite a bit of third party code that might get used for decoding
various multimedia formats, such as the ones mentioned above. Fortunately
Martin already has code for all these, however they require larger bunches
of third party code like the vorbis/ogg libs to work. Should we include them
all in kdesupport? kdemultimedia? There is also the problem with them
conflicting with distribution-grown versions of the same software, but
probably if we install everything in $kdedir, most stuff will be fine

 => I think including them in kdemultimedia after KDE2.0 should be sufficient
    for now (Martin would like to have them in kdemultimedia-support to
	indicare that they independantly developed from the KDE project).

 * i18n pipelining

I think the way to go for translating asynchronously without making
translating hard due to always changing strings and without frustrating
developers due to always holding up their work having stable, frozen
and unstable split like this:

                    10/2000  11/2000  12/2000  01/2001  02/2001  03/2001   ...
release stable      KDEMM2.0 KDEMM2.0 KDEMM2.0 KDEMM2.1 KDEMM2.1 KDEMM2.2  ...
release frozen         -        -     KDEMM2.1   -      KDEMM2.2   -       ...
release unstable    KDEMM2.1 KDEMM2.1 KDEMM2.2 KDEMM2.2 KDEMM2.3 KDEMM2.3  ...

 - stable is what user ought to use for daily work: completely translated
   and tested packages

 - frozen is a state each package gets in for a month once developers decide
   that their work is complete - this is also the package translators are
   working on for this month - only critical bug fixes may be applied to
   frozen packages, and they may not change the translation strings

 - unstable is what developers are working on all the day

 * version numbering

It seems that some thought will have to be put in actually naming the
packages as it may seem strange to understand that the stable kdemultimedia
version for instance is 2.3 while kdenetwork is 2.1 and kdebase is 2.2.

A possible idea would be to include the month in the version, such as 2.0.1
for a stable package released in 01/2001 or 2.0.7 for a stable package
released in 07/2000. And maybe 2.2.1 for a stable package released in
01/2002.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         

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