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? -Allen 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 > 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. > -- KDEPIM Developer I accept PayPal payments to [EMAIL PROTECTED] _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
