[RFC] KDE 4.0 Release Roadmap
winter at kde.org
Fri Mar 16 16:31:08 CET 2007
There's such much in here I don't even know where to start. :)
I suggest we get past the roadmap stage first.
Then take up the issue of what apps belong in $BASE vs. KEG.
A brand new thread in a week or two, perhaps?
On Thursday 15 March 2007 12:45:50 pm Aaron J. Seigo wrote:
> On March 15, 2007, Andreas Zehender wrote:
> > you have my vote :)
> thanks =)
> > maybe that's not the right place for this discussion, but KEG means I
> > have to make separate releases?
> not at all! =)
> one of the procedures planned for a long time with KEG is to do releases that
> coincide with KDE releases. the idea is that app developers can set
> a "stable" tag on their code at whatever point they deem it releasable.
> whenever kde goes into doing a release, the KEG mainatainer (Helio) will
> first send out a reminder announcement (probably when the beta cycle starts)
> and then when it comes time to release he will check out all of KEG that is
> marked with that tag, ensure everything builds and then provide tarballs of
> those apps.
> this has never actually been followed through with, however. so i spoke with
> Helio the other day and we've committed to making it happen starting with
> that means that as long as you simply set the right tag on your software,
> you'll get a release of your software that goes out at the same time (and i
> would hope with mentions in the announcements!) as the main KDE release. this
> will bring greater exposure to the wonderful apps we have in KEG and relieve
> one of the big "reasons" some people are reluctant to put their app in KEG.
> btw, this is all noted in brief (Helio is set to add some more details) on
> this page:
> personally, i would hope that when kpovmodell is in KEG, that you remain as
> involved in the kde graphics hacking community as you are now. in fact, as
> i'll talk about in great verbosity later in this email, i hope that these
> actions grow that community.
> > Or do the distribution packagers include
> > KEG in their distribution automatically?
> depending on the distribution and the specific application. remember that
> amarok, digikam, k3b, kst and others are all in KEG.
> > I don't have the time to coordinate releases any more as I am the only
> > half active developer in the kpovmodeler project and therefore want to
> > participate in the normal kde release cycles.
> that's understandable; and why i made sure we would have the KEG releases
> going before suggesting this.
> > I'm happy that porting is almost finished.
> woo! i know, it feels like a huge party when that happens =)
> > Why don't we let the packagers decide to split up the
> > packages as SuSE does with the kdegraphics3d package?
> what i'm about to suggest is not going to hold for all packages in kde as
> there are different schools of thought. this is simply mine:
> our main packages used to contain representative software for a given topic.
> so pretty much all the good network related kde software was in kdenetwork,
> for instance. many years pass and the number of people writing kde
> applications has skyrocketted. do we put them all in the package? no: not
> every author wants that, our packages would be insanely huge making release
> coordination even more difficult, efforts to translate and document the "KDE
> release" would mount ever upwards, etc. because of this, our packages have
> become an odd hodge-podge of apps that are neither representative of "common
> usage" nor even "best of breed" in some cases.
> personally, i think we've outgrown the idea of packages as a container for all
> apps of a given sort.
> however, the packages -do- provide a very important support system for
> application developers. namely, community support, improved visibility and
> coordinated releases.
> KEG has met some of these needs for some apps. amarok, k3b and digikam all
> have excellent visibility and community support, but that's at least as much
> due to them as it is to KEG. many other apps in KEG flounder in obscurity,
> and not always because they deserve that =) on the flip side, how many people
> know about kpovmodeller? so... neither model is working 100%.
> my thought is that we should raise the importance, visibility and coordination
> in KEG. this means primarily doing coordinated, opt-in releases of apps in
> KEG. the currently stable versions, whatever they are at the time, of apps in
> KEG should be released alongside the core module releases. this will allow us
> to mention them in community announcements and press releases; it will allow
> us to provide some release discipline as well as packaging help for those who
> want or need it (amarok, for instance, neither needs nor wants it, and that's
> OK under this plan too!). this will also allow us to adopt many, many more
> apps than we can right now because of being concerned of "bloating up" the
> main packages.
> eventually, i'd like to offer KEG applications some "certification badges"
> that they can display based on meeting checklist items. this will help OSVs
> as well as end users decide which apps are "more complete" or "higher
> quality" (e.g. "more kde-rific" =) than others.
> which leaves us with the main modules. the original goal of KDE was to provide
> a complete desktop environment that would meet the needs of your general
> desktop user. we've gone way past that, which is an awesome success on
> everyone's part who has been a part of it.
> i'd like to see the main modules get back to that spirit, however. our main
> modules should, imho, be the collection of recommended applications for a
> given topic that are of general interest and do the essential jobs. they
> don't have to be the fanciest or "best", they just have to be usable and rock
> by installing kdegraphics, one should be able to view any graphic format, do
> basic editting and have some commonly used utilities like a screenshot
> grabbers, ruler and color picker. the utilities are smaller and easier to
> maintain which makes the ubiquity of their necessity less important while
> making it harder to host them effectively (particularly for end users) in
> KEG. so once you have installed kdegraphics, you are ready to do most general
> graphics tasks.
> the KEG graphics package, along with KOffice, should augment the kdegrahpics
> package's basic set and open up the entire world of possibilities for you: 3D
> rendering, advanced image creation and manipulation, photo management, etc.
> this gives OSVs and users a really good set of guidelines to go by as to what
> makes a basic, essential desktop from our perspective. having sat down with
> people recently in fedora and gone through the packages one by one with them,
> it's apparent we're not servicing them very well in this regard. i suspected
> as much, but i'm rather sure that's the case now =)
> it will also be key that kde-graphics and extragear/graphics are all part of
> the same sub-community within KDE. i don't want KEG to be the divider it is
> right now, community-wise. there are those who are quiet and reclusive by
> nature, and that's great. but i want to signal to more app developers that by
> being part of KEG they can join the general development community, which
> includes the relevant main module hackers, even if their app isn't suitable
> for inclusion in a main module.
> this will get us away from the "4 packages that do $TASK" issue; it will let
> us identify which are absolutely, must be solid apps (this has been an issue
> with the 4.0 cycle for me); it will allow people to assemble basic desktops
> easier by just following our guidance; it can strengthen our extended
> developer community; and it will give more equal footing to all our
> applications that may not be general purpose but which rock by putting all of
> those apps in an actively managed and released KEG.
> in that sense, i actually see this as growing our app devel community and
> increasing the number of apps we endorse and ship without muddying the waters
> of what a base KDE environment is and does.
I accept PayPal payments to awinterz at earthlink.net
More information about the release-team