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 4.0. 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: http://extragear.kde.org/home/docs.php 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 solid. 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. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
pgpkegqxJMlEo.pgp
Description: PGP signature
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
