[Kde-extra-gear] Hello and let's start to bugging everyone with proposals :-)

[Helio Chissini de Castro]

Hi

After proper Klas introductions, now it's time to put some questions in the 
air to make new decisions.
Some of this can be related to kde-[core]-devel threads, but let's start here 
in the  list, since all you are the maintainers fo keg apps and of course 
have more decision power in this subjects.
So, the proposals:

1 - CRITICAL ONE - About keg modules new layout
Recent thread suggests a new way to divide keg modules. One of most appreciate 
sugestions is move keg-1,2,3 to keg-multimedia, keg-utilities, etc..
First valid point of Klas is this will make keg looks like an alternative KDE 
modules, and people start to package this modules and complain about have 5 
image apps, 4 mm players, etc, and break the original idea of keg
The point is, i like this idea, and i think is very difficult for catch apps 
searching keg-1,2,3, and with this system a guy that was looking for an 
alternative mm player easily will find it. But Klas have a strong point and i 
think this will looks like a kde module replacement, which leads a confusion 
and is exactly what we don't want.
Let's just add one more variable on the equations which is if we start to get 
more and more apps on keg ( and that's exactly what we want ), easier we will 
reach keg-1,2,3,4,5,6,7..... imagine the nightmare, for everyone from the guy 
want's to pick up some tool to the maintainer ( actually me ) to find where 
the app is to fix the buildsystem ( or do you expect i have all things on my 
mind :-) 
So, this is time to everyone reflects and let's try to get a consensus, and 
after, if was valid, let's move the decision, or the state of discussion to 
main devel lists.

2 - Please have mercy of packagers :-)
Well, everyone knows that proposit of keg is just a place for apps, and apps 
maintainers edcide when release ( or not ) launch their apps, not tied to KDE 
releases at all.
well, this is good, but this is bad from the point of distributions. Good or 
not, the first point of visibility for all our apps comes with a 
distribution, whatever they are. And people moves more of their attention for 
KDE and their apps ( hint, hint: even keg apps ) on the KDE releases,so, i 
have a simple and usefull proposal:

Create a keg_release_branch !

Why this ? Main keg modules stay untouchable on their current behaviour. But 
this branch will have the last stable release of your application, doesn't 
matter if yuo decide that those two years old code was the most stable or the 
bleeding edge was tha last stable. You decide when, how, which, everything
So, at the point some packager decides pick up keg modules, unless for some 
purposes they decide using main HEAD cvs, he will always have the 
keg_release_branch to package.
And the rules would be simple:
- Stable code must have a check for minimal or fixed kde release and if check 
i not valid, disable the compilation
- Have a defined MACRO with the stable version numbering ( hint, hint: not all 
apps have this in a uniform way to reach ) to packagers put the version of 
app in package, and not kde release version
- Have to add a switch on configure to define --with-app=yes.no with "no" by 
default, making easy just turn on just the apps needed, even for newcomers 
that get this keg module for compile a application ( Is really hard for 
beginners understand the "cvs co -l keg; cvs co keg/app; cd keg; cvs co 
admin; make -f Makefile.cvs, ./configure". you know what i'm talking )

So, let's two of major decision to decide.
Remember, after all this we even can stay with current buildsystem, so this 
still in the proposal mode.

Depending on which way things go, i have an addendum for both proposals, since 
the decisions could lead a important new things.

Thanks for take time and read my long and starnge english mail and hope 
someone understand my points :-)

[]'s

-- 
Helio Chissini de Castro
KDE Project South America Primary Contact
Curitiba - Brasil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-extra-gear/attachments/20041005/33163d74/attachment.pgp