[Kde-extra-gear] Farewell, so long, the four is coming ...

[Achim Bohnet]

On Wednesday, 18. April 2007, Helio Chissini de Castro wrote:
> Ok
> 
> Let's put some deadline and that's will be the final decision.
> I'm opening trunk of kde extragear to KDE 4 in exclusively state on day after 
> finish the official freeze of kdelibs. No discussion on this. Someone needs 
> take a position, and following a quote of one of commit of dfaure's "things 
> becoming confused on extragear."
> So i'm taking position now.
> 
> During this time, i planned a cleanup in applications as well, so i'll be 
> moving all current trunk for branches/extragear/kde3 and will let on trunk 
> only the apps effectively maintained, and new one's waiting to enter on kde 4 
> life.
> 
> What i need from you all you keg application developers:
>  
> - Is there some special request, non related to your apps only, but for whole 
> module ?

Let the cmake config of a module handle 'DO_NOT_COMPILE' on their own, and
allow the cmake config of an app to fail if some requirements are missing.

I.e. it should be possible to checkout a module or only one application
and the 'build mantra' cmake; make etc is in both cases the same.

> - What kind of information you would like to see in extragear docs to help you 
> on the transition ( i.e. how to handle move on svn, new buildsystem, etc..  )

 o Where should what happen?  KDE4/KDE3 app developement (trunk), maintainance (stable)
   and releases be done.
 o What's done by the extragear transition dude and what has to be done by the
   application developers.  Especially i18n stuff.
 
> - What kind of information you would like to see in extragear docs, if you are 
> a newcomer on extragear module.

An overview of the task in the life cycle of an application would be nice
like. Not much text and explanations (if available refer to other pages).

	o playground -> extragear (don't forget i18n ;)
	o where is what, developement, stable, releases
	o how to create a release (inform kde-i18n-doc, release scripts,
	  uploading tarballs, announcements ...
	o ...

I've also the feeling that often functionality is duplicated in several e.g. apps.
So a 'how-to' help enhancing KDE framework: eg/module/app/mylib/ -> eg/lib/mylib
-> kdelibs/mylib would be nice.  But I assume this needs some 'library-design'
experts that mentor the transitions.
> 
> - Should we commit ourselves to the ( not well ) implementated idea of STABLE 
> tags ? I, and suspect Aseigo, want that as a "yes", since we still plan to 
> launch apps packages. And how we will package this apps ? By app or by 
> module ?

I've answered in another subthread.

Achim

> 
> Well, that's it for now. If i forgot something, please remind me soon, since 
> Oslo meeting and kdelibs freeze is coming right next door
> 
> Thanks for you all.
> 
> -- 
> Helio Chissini de Castro
> KDE Developer
> Brasil/South America Primary Contact
> 



-- 
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- reddy at lion.austin.ibm.com