On Thursday 06 May 2010 16:44:26 you wrote: > On ketvirtadienis 06 Gegužė 2010 23:48:43 Boyd Stephen Smith Jr. wrote: > > > But whether > > > upstream software meets users' needs is out of Debian scope. > > > > There's a lot to consider, since Debian needs upstream's help in > > addressing bugs throughout the lifetime of stable, and that's easier to > > achieve with the latest release. But then again, stable needs to be > > usable on release day. "Release early, release often" is great for > > development, it is not so great for stability (both in "lack of bugs" and > > "lack of change" meanings). Sometimes the most recent release from > > upstream is not best for Debian stable. > > You missed my point completely. What is subjectively unusable for you, is > perfectly usable for others and the other way round. Debian is not your > personal distro, it strives to keep balance. And balance is towards 4.4 > side you like it or not due to many factors. When Squeeze is released, KDE > 4.5 may be in .3 or later patch release upstream so the point about the > latest and greatest here is completely out-of-place. Lenny didn't have KDE package from a single upstream release. It's not like the choice is "all of KDE SC 4.3", "all of KDE SC 4.4", or "all of KDE SC 4.5". Debian could release a Squeeze that has software from any or all of those. (Or none, I suppose, but no one here wants to consider that.) I wasn't making a "don't release the latest-and-greatest" argument. I was making a "release the best-and-brightest" argument. If certain things in KDE SC 4.4 aren't release quality, use the version from KDE SC 4.3 or KDE SC 4.5. > Now if at particular time upstream software does not meet your personal > needs, you go and look for alternatives. You talk like kdepim 4.3 was > flawless. But it wasn't! > There is no place for "software does not do X, > remove it from stable" discussions here. Where is that appropriate, because it *should* be discussed somewhere. > > > Just find > > > another software/solution which does, develop it by yourself, pay > > > somebody to develop it for you or ask kindly and wait till somebody > > > else is motivated enough to do it. > > > > I will, but I see no reason not to air my grievances. > > Insisting that others do something (revert to kdepim 4.3) based solely on > your personal grievances does not help productive communication. I'm not insisting. I'm asking. I'm raising an issue that I have, and that I know is shared by at least a few other users. Reverting to KDEPIM 4.3 is an option, as is shipping an Akonadi that doesn't require MySQL. I know KDEPIM 4.3 works in a mostly KDE SC 4.4 environment (that's my current setup). I'll bet that pre-Akonadi-integration KMail could work with the rest of KDEPIM 4.4. There are a lot of ways to address my issue, and I don't *demand* that you address it at all. I am trying to argue that it's worth the work to make sure stable isn't burdened with a KMail that depends on MySQL. I think that's appropriate discussion for this list. Technically, I'm not even a member of the group I'm advocating for. Currently, I run a *very* mixed system. I would *like* to move back to being a user of Debian stable; I find the lack of change comforting. If KMail in Squeeze requires MySQL, I'll just keep my 4.3.x package until Sid gets a version that doesn't require MySQL, but I'd prefer to be able to use Squeeze without mixing in KDE packages from testing/Sid. I should have some time to pitch in and help before and after the freeze date. What can I do to make sure KMail doesn't need Akonadi when Squeeze is released? I've been told that back-porting the Akonadi/PostgreSQL patches is unlikely to help. I'm not averse to helping, but I don't have lots of time -- a few evenings a week at most. I'm not "unable" to help, but I'm not too familiar with Debian packging of the KDE SC 4.x code case -- I can read/write all the computer languages involved, though. > You started this off on a wrong foot by demanding to accommodate to your > needs. "Please" is not a demand last time I checked. I think that KMail requiring MySQL to function in Debian stable is a problem. I request that the Qt/KDE packaging team take steps to ensure that Debian stable users are not stranded with that situation for the lifetime of stable. I know that the volunteers that make up the Qt/KDE team have the last say and I don't pretend that I have any right or privilege to force them to do something. I'm voicing an opinion that I hope someone will act on. I'm trying to come up with ideas that are less bad as we continue the discussion. Shipping KDE SC 4.5 with Squeeze would likely be a nightmare. Shipping KDE SC 4.3 with Squeeze might even be worse. Picking and choosing the correct version(s) of specific applications to include in Squeeze seems not-so-bad, since MOST of KDE SC 4.4.3 seems pretty good. Shipping Akonadi/SQLite (which seems to be in the works upstream) or Akonadi/PostgreSQL (which seems to be mostly done upstream) or even Akonadi/Virtuoso would also be a solution, which could be better if one of them has enough time in testing/Sid to become release-quality. If my words came off as a demand, I beg your pardon. I did not mean to lay claim to that authority. > > > YOU say KDE 4.4 is inappropriate for stable. > > > > That is my opinion. > > > > > Nothing objective and > > > > > > YOU assume that your truth is an ultimate one. > > > > Not really. I made objective statement about KMail based on observable > > facts. I also voiced an opinion that I based on that statement. > > What facts? That kdepim/kmail needs akonadi? That's hardly news. That the KMail from KDE SC 4.4.3, as packaged by Debian now needs MySQL to function. I've been running KMail from KDE SC 4.x since 4.2.x hit Sid. I choose not to install KAddressBook and KOrganizer because they did bring in the Akonadi server (and MySQL with it); KMail, Akregator, and Kontact did not prior to this latest round of packaging. > Akonadi > integration is not stable enough? I wouldn't know; until Akonadi doesn't require MySQL, I an actively not installing it. > > > If YOU have so > > > many problems with particular piece of software, look for better > > > options or read the first part of this mail again. > > > > I have problems with a very narrow selection of selection of the > > software. Specifically, I don't want to need MySQL installed in order to > > use KMail effectively in Debian stable. > > It is not like every mail client on the market suddenly needs MySQL. > Actually, kmail is probably unique in this area. Migration from one client to another is not as easy as (aptitude install mutt kmail_). I'm not writing the option completely off, but it would be nice if not every KMail user had to choose MySQL or MiGRATION. > > There are a number of solutions to this. Newer Akonadi should run on > > non- MySQL data stores. Older KMail doesn't talk to Akonadi. Patches > > could be applied to either. Stable could include software from multiple > > KDE releases, as has been done before. > > What I tried to say to you all this time, if Akonadi renders Kmail unusable > to you, switch the client! Akonadi by itself is not a bug, it is not going > away! Take it or switch to something else, simple as that. I'm not saying to get rid of Akonadi-tied KMail. I'm certainly not saying "Akonadi by itself is a bug". I'd be perfectly happy with Akonadi/PostgreSQL making it into stable, in fact I'd be excited to play with Akonadi! -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.