Hi all! As you all know Lenny is near, which also means that our 4.2 packages will enter Unstable in the very near future. Until today, we still have not decided how to handle KDEHOME. The current situation is, that KDE 3 applications use ~/.kde and KDE 4 applications use ~/.kde4. The problem with this approach is, that no data/settings are automatically converted to be used by KDE 4. The question is now: should we a) continue to use ~/.kde4 for KDE 4 applications b) use ~/.kde for KDE 4 applications. The problem with a) is, that as mentioned no data is is moved to KDE 4. The problem with b) is, that we don''t know for sure, if all upgrade scripts work and users don''t loose critical data. Apart from that users already using KDE 4 won''t find their settings copied. (Add here more pros and cons for either option.) To overcome this, we had the following idea in IRC: Provide a little Qt application which starts at the first KDE 4 start and allows the users to copy their KDEHOMEs around. In case we would use ~/.kde for KDE 4 the script could offer to create a backup in ~/.kde3 so lost data can be reverted if anything goes wrong. If we continue to use ~/.kde4 the application could offer to copy ~/.kde to ~/.kde4. Non-KDE users are a bit lost here, we could document what to copy where. So, which options do you see? What would you prefer? Don''t forget that we have to decide/code all this before we upload kde4libs to unstable. Greetings, Armin
Armin Berres
2009-Feb-03 21:56 UTC
Uploads to Squeeze and the $KDEHOME dilemma (was: Uploads to lenny and the $KDEHOME dilemma)
I meant Squeeze and not Lenny for sure. On Tuesday 03 February 2009 22:53:42 Armin Berres wrote:> Hi all! > > As you all know Lenny is near, which also means that our 4.2 packages will > enter Unstable in the very near future. Until today, we still have not > decided how to handle KDEHOME. > The current situation is, that KDE 3 applications use ~/.kde and KDE 4 > applications use ~/.kde4. The problem with this approach is, that no > data/settings are automatically converted to be used by KDE 4. > > The question is now: should we > a) continue to use ~/.kde4 for KDE 4 applications > b) use ~/.kde for KDE 4 applications. > > The problem with a) is, that as mentioned no data is is moved to KDE 4. The > problem with b) is, that we don''t know for sure, if all upgrade scripts > work and users don''t loose critical data. Apart from that users already > using KDE 4 won''t find their settings copied. > (Add here more pros and cons for either option.) > > To overcome this, we had the following idea in IRC: Provide a little Qt > application which starts at the first KDE 4 start and allows the users to > copy their KDEHOMEs around. > In case we would use ~/.kde for KDE 4 the script could offer to create a > backup in ~/.kde3 so lost data can be reverted if anything goes wrong. > If we continue to use ~/.kde4 the application could offer to copy ~/.kde to > ~/.kde4. > Non-KDE users are a bit lost here, we could document what to copy where. > > So, which options do you see? What would you prefer? > Don''t forget that we have to decide/code all this before we upload kde4libs > to unstable. > > Greetings, > Armin
Scott Kitterman
2009-Feb-03 22:15 UTC
Uploads to Squeeze and the $KDEHOME dilemma (was: Uploads to lenny and the $KDEHOME dilemma)
On Tue, 3 Feb 2009 22:56:27 +0100 Armin Berres <armin at space-based.de> wrote:>I meant Squeeze and not Lenny for sure. > >On Tuesday 03 February 2009 22:53:42 Armin Berres wrote: >> Hi all! >> >> As you all know Lenny is near, which also means that our 4.2 packageswill>> enter Unstable in the very near future. Until today, we still have not >> decided how to handle KDEHOME. >> The current situation is, that KDE 3 applications use ~/.kde and KDE 4 >> applications use ~/.kde4. The problem with this approach is, that no >> data/settings are automatically converted to be used by KDE 4. >> >> The question is now: should we >> a) continue to use ~/.kde4 for KDE 4 applications >> b) use ~/.kde for KDE 4 applications. >> >> The problem with a) is, that as mentioned no data is is moved to KDE 4.The>> problem with b) is, that we don''t know for sure, if all upgrade scripts >> work and users don''t loose critical data. Apart from that users already >> using KDE 4 won''t find their settings copied. >> (Add here more pros and cons for either option.) >> >> To overcome this, we had the following idea in IRC: Provide a little Qt >> application which starts at the first KDE 4 start and allows the users to >> copy their KDEHOMEs around. >> In case we would use ~/.kde for KDE 4 the script could offer to create a >> backup in ~/.kde3 so lost data can be reverted if anything goes wrong. >> If we continue to use ~/.kde4 the application could offer to copy ~/.kdeto>> ~/.kde4. >> Non-KDE users are a bit lost here, we could document what to copy where. >> >> So, which options do you see? What would you prefer? >> Don''t forget that we have to decide/code all this before we uploadkde4libs>> to unstable. >>In the long run KDE is KDE4. I''d recommend KDE4 in .kde and a backup in .kde3. Do it the other way and eventually it''ll be .kde4, no .kde, and people finding it odd. In Kubuntu we just migrated people in .kde without the backup tool and I would describe it as mostly OK. Scott K
Julian Hernandez Gomez
2009-Feb-04 01:44 UTC
Uploads to Squeeze and the $KDEHOME dilemma (was: Uploads to lenny and the $KDEHOME dilemma)
Hi, I think we should use whatever the upstream choose as default, so users will not get confused by the (possible) difference between upstream documentation and the Debian settings. A debconf preconfigure dialog with an explanation of the change and that more information can be found in the Debian.Readme would be a good thing IMHO. Bye! On Wed, Feb 4, 2009 at 5:56 AM, Armin Berres <armin at space-based.de> wrote:> I meant Squeeze and not Lenny for sure. > > On Tuesday 03 February 2009 22:53:42 Armin Berres wrote: > > Hi all! > > > > As you all know Lenny is near, which also means that our 4.2 packages > will > > enter Unstable in the very near future. Until today, we still have not > > decided how to handle KDEHOME. > > The current situation is, that KDE 3 applications use ~/.kde and KDE 4 > > applications use ~/.kde4. The problem with this approach is, that no > > data/settings are automatically converted to be used by KDE 4. > > > > The question is now: should we > > a) continue to use ~/.kde4 for KDE 4 applications > > b) use ~/.kde for KDE 4 applications. > > > > The problem with a) is, that as mentioned no data is is moved to KDE 4. > The > > problem with b) is, that we don''t know for sure, if all upgrade scripts > > work and users don''t loose critical data. Apart from that users already > > using KDE 4 won''t find their settings copied. > > (Add here more pros and cons for either option.) > > > > To overcome this, we had the following idea in IRC: Provide a little Qt > > application which starts at the first KDE 4 start and allows the users to > > copy their KDEHOMEs around. > > In case we would use ~/.kde for KDE 4 the script could offer to create a > > backup in ~/.kde3 so lost data can be reverted if anything goes wrong. > > If we continue to use ~/.kde4 the application could offer to copy ~/.kde > to > > ~/.kde4. > > Non-KDE users are a bit lost here, we could document what to copy where. > > > > So, which options do you see? What would you prefer? > > Don''t forget that we have to decide/code all this before we upload > kde4libs > > to unstable. > > > > Greetings, > > Armin > > > -- > http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20090204/ee6a298b/attachment.htm
On Tue, Feb 03, 2009 at 10:53:42PM +0100, Armin Berres wrote:> As you all know Lenny is near, which also means that our 4.2 packages will > enter Unstable in the very near future. Until today, we still have not decided > how to handle KDEHOME. > The current situation is, that KDE 3 applications use ~/.kde and KDE 4 > applications use ~/.kde4. The problem with this approach is, that no > data/settings are automatically converted to be used by KDE 4. > > The question is now: should we > a) continue to use ~/.kde4 for KDE 4 applications > b) use ~/.kde for KDE 4 applications. > > The problem with a) is, that as mentioned no data is is moved to KDE 4. The > problem with b) is, that we don''t know for sure, if all upgrade scripts work > and users don''t loose critical data. Apart from that users already using KDE 4 > won''t find their settings copied. > (Add here more pros and cons for either option.) > > To overcome this, we had the following idea in IRC: Provide a little Qt > application which starts at the first KDE 4 start and allows the users to copy > their KDEHOMEs around. > In case we would use ~/.kde for KDE 4 the script could offer to create a backup > in ~/.kde3 so lost data can be reverted if anything goes wrong. > If we continue to use ~/.kde4 the application could offer to copy ~/.kde to > ~/.kde4. > Non-KDE users are a bit lost here, we could document what to copy where. > > So, which options do you see? What would you prefer? > Don''t forget that we have to decide/code all this before we upload kde4libs to > unstable. >I would go for a) continue to use ~/.kde4 for KDE 4 applications. This option keeps .kde for KDE3 apps data that a lot of people will have to use for some time and for backuping in case users want to go back to KDE 3. Some people will say here downgrades are not supported, but we all know the change from KDE 3 to 4 won''t please to everybody and it is easy keep on the safe side and do not mess with people''s data. I do not fully see KDE 4 as major upgrade of KDE 3, it is different in a lot of ways... What could be done here is when users log first time in KDE 4 get some dialog telling then "hey welcome to KDE 4, your settings are not migrated because X and Y, you have this migration guide|program from migrating then"... The option of start a migrating program instead of this warning dialog, also works for me, but: i do not volunteer for doing or testing it and i still think even in this case, it is better keeping .kde4 and not moving to .kde. Ana
Ana Guerrero
2009-Feb-04 01:58 UTC
Uploads to Squeeze and the $KDEHOME dilemma (was: Uploads to lenny and the $KDEHOME dilemma)
On Wed, Feb 04, 2009 at 09:44:52AM +0800, Julian Hernandez Gomez wrote:> Hi, > > I think we should use whatever the upstream choose as default, so users will > not get confused by the (possible) difference between upstream documentation > and the Debian settings. >Documentation can be patched (and it already is).> A debconf preconfigure dialog with an explanation of the change and that > more information can be found in the Debian.Readme would be a good thing > IMHO. >That is debconf abuse, and configuration dialog here should be done to every use...
Sune Vuorela
2009-Feb-04 07:05 UTC
Uploads to Squeeze and the $KDEHOME dilemma (was: Uploads to lenny and the $KDEHOME dilemma)
On Tuesday 03 February 2009 23:15:55 Scott Kitterman wrote:> In Kubuntu we just migrated people in .kde without the backup tool and I > would describe it as mostly OK.I have heard similar things from fedora. If you could elaborate what you mean by "mostly", it will be appreciated. /Sune -- How can I log in the directory on the mail on a EPRAM BIOS driver? From Word you either can never close a GPU, or have not to explore the computer for sending a editor to the ISDN terminale of the line.
On Tuesday 03 February 2009 22:53:42 Armin Berres wrote:> So, which options do you see? What would you prefer? > Don''t forget that we have to decide/code all this before we upload kde4libs > to unstable.The biggest problem, as I see it, is that choosing .kde screws our current kde4 users, because data also isn''t migrated "the other way", and choosing .kde4 screws the kde3 users on upgrade. I don''t know if any of you have noticed it, but in general, I''m quite against appending the number 4 anywhere if it can be avoided. /Sune -- How might I get access over the proxy from Outlook or from the panel inside Excel 96? You neither should open the forward, nor can ever unlink to a editor in order to reset a Fast cache over the pointer of the tower. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20090204/ef10b5b3/attachment.pgp
Armin Berres wrote:> The question is now: should we > a) continue to use ~/.kde4 for KDE 4 applications > b) use ~/.kde for KDE 4 applications.I''m in favor of b). I think there are more users interested in (or requiring) a smooth upgrade from KDE 3 than users interested in (or requiring) a smooth upgrade from KDE 4 in experimental. For the latter group, just document in NEWS.Debian that they should do a "mv .kde4 .kde" and they''re done. Also, consistency and compatibility with the rest of the world would be good to have.
Ana Guerrero wrote:> I would go for a) continue to use ~/.kde4 for KDE 4 applications. This option > keeps .kde for KDE3 apps data that a lot of people will have to use for some > time and for backuping in case users want to go back to KDE 3. Some people > will say here downgrades are not supported,Supporting downgrades even marginally would require keeping the KDE 3 packages around. Is anyone committed to doing that? Is that even possible under the current package naming scheme?
On Wed, Feb 04, 2009 at 10:46:31AM +0200, Peter Eisentraut wrote:> Ana Guerrero wrote: >> I would go for a) continue to use ~/.kde4 for KDE 4 applications. This option >> keeps .kde for KDE3 apps data that a lot of people will have to use for some >> time and for backuping in case users want to go back to KDE 3. Some people >> will say here downgrades are not supported, > > Supporting downgrades even marginally would require keeping the KDE 3 > packages around. Is anyone committed to doing that? Is that even > possible under the current package naming scheme?You do not need to keep any package around, user X installs KDE 4.2 realizes that does not like it, user can: - install kde 3.5 from testing (yes, for limited time this one) - install kde 3.5 from local apt cache or copy made on purpose. - build his/her own kde 3.5 packages fetching debian/ from our repo (branches/lenny( - go to snapshots.debian.net and fetches a copy from there. And of course, never ever update kde...
Le mercredi 04 f?vrier 2009 09:45:02, Peter Eisentraut a ?crit :> Armin Berres wrote: > > The question is now: should we > > a) continue to use ~/.kde4 for KDE 4 applications > > b) use ~/.kde for KDE 4 applications.I am working on kdebase3-legacy and wondering if b) won''t make systemsettings and kcontrol interfere badly. there are automatic kconf_update tokens to migrate a .kde from kde3 to kde4 settings, but I wonder how kde3 apps handle the updated config. For instance, one should check we can use .kde for both and still change kde3 colors/style/fonts without messing up the kde4 configuration. If not, we have to disable these KCMs too. -- Xavier Vello
Armin Berres wrote:> To overcome this, we had the following idea in IRC: Provide a little Qt > application which starts at the first KDE 4 start and allows the users to copy > their KDEHOMEs around. > In case we would use ~/.kde for KDE 4 the script could offer to create a backup > in ~/.kde3 so lost data can be reverted if anything goes wrong. > If we continue to use ~/.kde4 the application could offer to copy ~/.kde to > ~/.kde4.Could we just patch kdelibs to make a backup copy by itself, without an external application?
Scott Kitterman
2009-Feb-04 11:35 UTC
Uploads to Squeeze and the $KDEHOME dilemma (was: Uploads to lenny and the $KDEHOME dilemma)
On Wed, 4 Feb 2009 08:05:10 +0100 Sune Vuorela <Sune at vuorela.dk> wrote:>On Tuesday 03 February 2009 23:15:55 Scott Kitterman wrote: > >> In Kubuntu we just migrated people in .kde without the backup tool and I >> would describe it as mostly OK. >pppoI have two systems here that were upgraded from 3.5.10 to 4.1.2 (and later 4.1.3/4) without issue, so I have seen no problems with upgrading myself. I have helped users with problems where moving .kde away and recreating it helped (I don''t recall specifics). Of course this also happens with KDE3 and not-upgraded-from-KDE3-KDE4 systems too, so I don''t actually know that it''s KDE3 to KDE4 problems that are being resolved. I recently also saw that work with a Gnome system that had KDE4 installed onto it. Sorry I don''t have more specifics. Scott K
Hi. First of all, I want to say that I''m mostly a user, but since I follow KDE development as much as my time allows, I want to say something from my point of view. Sorry if I missed something important, though. :-) El Martes, 3 de Febrero de 2009, Armin Berres escribi?:> To overcome this, we had the following idea in IRC: Provide a little Qt > application which starts at the first KDE 4 start and allows the users to > copy their KDEHOMEs around. > In case we would use ~/.kde for KDE 4 the script could offer to create a > backup in ~/.kde3 so lost data can be reverted if anything goes wrong. > If we continue to use ~/.kde4 the application could offer to copy ~/.kde to > ~/.kde4. > Non-KDE users are a bit lost here, we could document what to copy where. > > So, which options do you see? What would you prefer?Say that you decide to keep ".kde4" as default. Is there a way of migrating the configuration of those who don''t use a KDE 4 desktop? I can''t thing of one. If I understood properly, the kres-migrator from kdepim was created with this in mind: if a KResources enabled application starts (no matter if it''s inside a KDE desktop or not), it will be triggered. So the only way I can imagine is patching kdelibs. :-( Say one user has Lenny''s akregator installed, and has not only its configuration, but has in the akregator storage some stories that considers valuable marked as important. When upgrades to Squeeze, if is not using KDE 4 as desktop, there is no way that Squeeze''s akregator finds the feeds in the old KDEHOME, isn''t it? Is somehow the situation I am right now: I''ve selectively upgraded many packages to its KDE 4 version, but I''ve been a bit conservative, and I have not touched kdebase or kdepim. I had to spend some time reconfiguring apps or manually copying config files, but it wasn''t a big deal because there was not any important data. My next step will be to upgrade kdepim, but I will not notice any improvement with a migration tool, because kdebase will be the last package. I will have to migrate manually. In my humble opinion, this is a big con against this idea. And you still have to create a tool that does the copying from one config to the other, which is not the upstream way. But what are the problems of reverting back to ".kde"? Well, the only users who will have problems with this will be those who upgrade to KDE 4, dislike it, want to go back to KDE 3, and find that some configuration is not downgradable. I think this problem is not as important as the others for the following reasons: First, I think that the most important data will still be there in the same format (KMail will save in maildir or mailbox, KAdressBook and KOrganizer in whatever format the resource the user has set, Kopete''s logs in XML, etc.). Second, the user who wants to go back, will very likely be a user of unstable/testing (we don''t know how will be the KDE shipped with Squeeze, but I doubt it will be so bad), so we can expect that users of this Debian''s branches are enough proficient to realize that a big KDE upgrade is coming, and make a copy of their ~/.kde if they care a lot about that. A warning through NEWS.Debian can still be included, of course. A different issue are programs not properly upgrading their config to KDE 4, but this is clearly a bug in the application (not a Debian specific issue), and upstream should help to properly use kconfig_update to fix it, because it''s the mechanism explicitly created to do this. My 2?. :) Greetings. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net
On Tuesday 03 February 2009 21:53:42 Armin Berres wrote:> Hi all! > > As you all know Lenny is near, which also means that our 4.2 packages will > enter Unstable in the very near future. Until today, we still have not > decided how to handle KDEHOME. > The current situation is, that KDE 3 applications use ~/.kde and KDE 4 > applications use ~/.kde4. The problem with this approach is, that no > data/settings are automatically converted to be used by KDE 4. > > The question is now: should we > a) continue to use ~/.kde4 for KDE 4 applications > b) use ~/.kde for KDE 4 applications. > > The problem with a) is, that as mentioned no data is is moved to KDE 4. The > problem with b) is, that we don''t know for sure, if all upgrade scripts > work and users don''t loose critical data. Apart from that users already > using KDE 4 won''t find their settings copied. > (Add here more pros and cons for either option.) > > To overcome this, we had the following idea in IRC: Provide a little Qt > application which starts at the first KDE 4 start and allows the users to > copy their KDEHOMEs around. > In case we would use ~/.kde for KDE 4 the script could offer to create a > backup in ~/.kde3 so lost data can be reverted if anything goes wrong. > If we continue to use ~/.kde4 the application could offer to copy ~/.kde to > ~/.kde4. > Non-KDE users are a bit lost here, we could document what to copy where. > > So, which options do you see? What would you prefer? > Don''t forget that we have to decide/code all this before we upload kde4libs > to unstable. > > Greetings, > ArminI think it would be better to support migration from KDE4 experimental seamlessly, but also issue a message to those upgrading from KDE3 that settings haven''t been migrated because KDE4 has major architectural changes from KDE3 (in simpler terms). However, it would still be useful to migrate mail, rss feeds, IM accounts, and the like. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20090204/fdec9c8a/attachment.htm
On Tuesday 03 February 2009 22:53:42 Armin Berres wrote:> Hi all! > > As you all know Lenny is near, which also means that our 4.2 packages will > enter Unstable in the very near future. Until today, we still have not > decided how to handle KDEHOME. > The current situation is, that KDE 3 applications use ~/.kde and KDE 4 > applications use ~/.kde4. The problem with this approach is, that no > data/settings are automatically converted to be used by KDE 4. > > The question is now: should we > a) continue to use ~/.kde4 for KDE 4 applications > b) use ~/.kde for KDE 4 applications. > > The problem with a) is, that as mentioned no data is is moved to KDE 4. The > problem with b) is, that we don''t know for sure, if all upgrade scripts > work and users don''t loose critical data. Apart from that users already > using KDE 4 won''t find their settings copied. > (Add here more pros and cons for either option.) > > To overcome this, we had the following idea in IRC: Provide a little Qt > application which starts at the first KDE 4 start and allows the users to > copy their KDEHOMEs around. > In case we would use ~/.kde for KDE 4 the script could offer to create a > backup in ~/.kde3 so lost data can be reverted if anything goes wrong. > If we continue to use ~/.kde4 the application could offer to copy ~/.kde to > ~/.kde4. > Non-KDE users are a bit lost here, we could document what to copy where. > > So, which options do you see? What would you prefer? > Don''t forget that we have to decide/code all this before we upload kde4libs > to unstable.After thinking even further, I really think that going .kde is the only way. If not, people will lose their contacts in kopete People will lose their contacts in kaddressbook People will lose their book database in tellico when tellico goes kde4 people will lose emails stored locally people will lose the content of their kwallet. and so on. (really powerusers understanding where and how kconf_update might do and not do things might be able to recover things, but not any ordinary user - and I might have issues as well) The only way to avoid users losing data and sticking to .kde4 is by making kdelibs in kde4 (not in startkde or anywhere else) migrate data on application startup. To be honest, I''m quite sure we don''t have the skills in kde team to actually do these changes to kdelibs) Who are we screwing by keeping using .kde for kde4 data? - users who might want to migrate back. - current users of kde4 in experimental. The first group of the users we are screwing should just do a cp .kde kde3 if they are unsure. The second group of users managed to migrate from .kde to .kde4. They should be able to migrate back as well. But by screwing those two groups of users, we are actually unscrewing all the other users of the kde desktop *and* the kde applications. And we just heard; in ubuntu they had no problems with this large scale migration of things. So, currently I think the only right decision is .kde. /Sune -- Man, how can I debug a LCD BIOS periferic of the CPU to the hard disk on the modem from Office 7.4? You either should never save a ROM e-mail, or can never doubleclick a sendmail for booting a TCP display. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20090204/75e7a66d/attachment.pgp
Raúl Sánchez Siles
2009-Feb-04 20:47 UTC
[pkg-kde-talk]Re: Uploads to lenny and the $KDEHOME dilemma
El Mi?rcoles 04 Febrero 2009, Alejandro Exojo escribi?:> Hi. > > First of all, I want to say that I''m mostly a user, but since I follow KDE > development as much as my time allows, I want to say something from my > point of view. Sorry if I missed something important, though. :-) > > El Martes, 3 de Febrero de 2009, Armin Berres escribi?: > > To overcome this, we had the following idea in IRC: Provide a little Qt > > application which starts at the first KDE 4 start and allows the users to > > copy their KDEHOMEs around. > > In case we would use ~/.kde for KDE 4 the script could offer to create a > > backup in ~/.kde3 so lost data can be reverted if anything goes wrong. > > If we continue to use ~/.kde4 the application could offer to copy ~/.kde > > to ~/.kde4. > > Non-KDE users are a bit lost here, we could document what to copy where. > > > > So, which options do you see? What would you prefer? > > Say that you decide to keep ".kde4" as default. > > Is there a way of migrating the configuration of those who don''t use a KDE > 4 desktop? I can''t thing of one. If I understood properly, the > kres-migrator from kdepim was created with this in mind: if a KResources > enabled application starts (no matter if it''s inside a KDE desktop or not), > it will be triggered. So the only way I can imagine is patching kdelibs. > :-( > > Say one user has Lenny''s akregator installed, and has not only its > configuration, but has in the akregator storage some stories that considers > valuable marked as important. When upgrades to Squeeze, if is not using KDE > 4 as desktop, there is no way that Squeeze''s akregator finds the feeds in > the old KDEHOME, isn''t it? > > Is somehow the situation I am right now: I''ve selectively upgraded many > packages to its KDE 4 version, but I''ve been a bit conservative, and I have > not touched kdebase or kdepim. I had to spend some time reconfiguring apps > or manually copying config files, but it wasn''t a big deal because there > was not any important data. My next step will be to upgrade kdepim, but I > will not notice any improvement with a migration tool, because kdebase will > be the last package. I will have to migrate manually. > > In my humble opinion, this is a big con against this idea. And you still > have to create a tool that does the copying from one config to the other, > which is not the upstream way. > > But what are the problems of reverting back to ".kde"? > > Well, the only users who will have problems with this will be those who > upgrade to KDE 4, dislike it, want to go back to KDE 3, and find that some > configuration is not downgradable. I think this problem is not as important > as the others for the following reasons: > > First, I think that the most important data will still be there in the same > format (KMail will save in maildir or mailbox, KAdressBook and KOrganizer > in whatever format the resource the user has set, Kopete''s logs in XML, > etc.). Second, the user who wants to go back, will very likely be a user of > unstable/testing (we don''t know how will be the KDE shipped with Squeeze, > but I doubt it will be so bad), so we can expect that users of this > Debian''s branches are enough proficient to realize that a big KDE upgrade > is coming, and make a copy of their ~/.kde if they care a lot about that. A > warning through NEWS.Debian can still be included, of course. > > A different issue are programs not properly upgrading their config to KDE > 4, but this is clearly a bug in the application (not a Debian specific > issue), and upstream should help to properly use kconfig_update to fix it, > because it''s the mechanism explicitly created to do this. > > My 2?. :) > > Greetings. > > -- > Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 > http://barnacity.net/ | http://disperso.netMostly +1. Developing an application, mostly Debian specific it''s quite time, resources and test demanding. Worst of all is that Debian would diverge from upstream which as I see it, it''s not Team''s policy. If we consider user''s data critical, as worst case[0], there should also be a method to rollback the operation. In summary, tricky. Focus would also have to be paid into Lenny -> Squeeze migration. If we consider Lenny stable and testing(future Squeeze) a moving target, there should be some "guaranty" that migration from KDE3 to testing(future Squeeze) KDE4.x version will be successful. If that fails, upstream should be informed. Additionally, just because the undesirable result(data loss) can happen, a backup mechanism should be provided, IMO either telling the user to backup ~/.kde or doing it automatically if such migration is detected[1]. I think this method will be less painful for the Team and simpler for all in general. [0] I reckon some data/configurations are irrelevant, like icons position on desktop. Some other, as e-mail is not. [1] Raise hand if you don''t have a backup of your important data. ;) -- Ra?l S?nchez Siles ----->Proud Debian user<----- Linux registered user #416098 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20090204/75ab31d0/attachment.pgp
Hello, I''m fine with ~/.kde for KDE4. However: 2009 m. Vasaris 4 d., tre?iadienis, Sune Vuorela ra??:> The first group of the users we are screwing should just do a cp .kde kde3 > if they are unsure.The question is how you are going to communicate with such users (as well as current experimental users)? I disagree that changing a line in variables.mk and forgetting about it is the way to go. It might be enough for users of individual kde applications, but not for the users of the KDE desktop. What is more, I don''t think that a mail to mailing list and a note in release notes are enough.> The second group of users managed to migrate from .kde to .kde4. They > should be able to migrate back as well.Probably they will if we let all of them know that they should do that. -- Modestas Vainius <modestas at vainius.eu> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20090205/88960bc0/attachment.pgp
Hi,> The question is now: should we > a) continue to use ~/.kde4 for KDE 4 applications > b) use ~/.kde for KDE 4 applications.My choice would go for b), ie using ~/.kde even in KDE 4. Users that will upgrade from Lenny to Squeeze expect their data & configuration to be preserved and used as they did them. A new KDEHOME could be nice if you want to start from scratch, but not really if you had lot of settings in your ~/.kde.> The problem with a) is, that as mentioned no data is is moved to KDE 4.Exactly, and users don''t know that copying stuff anually should be working anyway, and then they report bugs[1] for each application asking for migration procedures, or for "global migration wizards".> The problem with b) is, that we don''t know for sure, if all upgrade scripts > work and users don''t loose critical data.Upgrading is something that must be supported by any KDE application, either by adapting the old configuration to a new format (kconf_update), or just by simply discarding the old one. But they should not misbehave because of old configuration/data; and if they don''t, it is a bug to be reported ASAP to us (KDE). (Given that Squeeze will ship with at least KDE 4.4, if not greater, there''s time to solve these problems as they are reported.)> Apart from that users already using KDE 4 won''t find their settings copied. > (Add here more pros and cons for either option.)It all goes down to which "current KDE 4 users" should be supported, ie current Lenny users (ktorrent and okular) or experimental too.> To overcome this, we had the following idea in IRC: Provide a little Qt > application which starts at the first KDE 4 start and allows the users to > copy their KDEHOMEs around.kpersonalizer strikes again? :-P> In case we would use ~/.kde for KDE 4 the script could offer to create a > backup in ~/.kde3 so lost data can be reverted if anything goes wrong. > If we continue to use ~/.kde4 the application could offer to copy ~/.kde to > ~/.kde4. > Non-KDE users are a bit lost here, we could document what to copy where.As Kevin said already, this can create the problem of the disk space; other than that, what you decide what is worth copying or not? For example, I have a session with ~2-3 konqueror windows with a few tabs in each, and I would not like to lose it. Or also configurations of "smaller" KDE applications, let it be kate, rsibreak or a KDE-Edu application. Sure, not a big deal in configuring them again, but can be a small annoyance too. [1] a quick search on bugzilla gives me: #157367, #163771, #167276, #167374, #169827, #181210, and probably there''s a couple more. -- Pino Toscano -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20090205/37edfaa5/attachment.pgp
* Modestas Vainius [Thu, 05 Feb 2009 12:27:56 +0200]:> > The second group of users managed to migrate from .kde to .kde4. They > > should be able to migrate back as well. > Probably they will if we let all of them know that they should do that.For this group, maybe a small patch in kdelibs that raises a one-time pop-up if ~/.kde4 exists would be enough. -- Adeodato Sim? dato at net.com.org.es Debian Developer adeodato at debian.org Everything you read in newspapers is absolutely true, except for that rare story of which you happen to have first-hand knowledge. -- Erwin Knoll
On Thu, 05 Feb 09 14:10, Adeodato Sim? wrote:> * Modestas Vainius [Thu, 05 Feb 2009 12:27:56 +0200]: > > > > The second group of users managed to migrate from .kde to .kde4. They > > > should be able to migrate back as well. > > Probably they will if we let all of them know that they should do that. > > For this group, maybe a small patch in kdelibs that raises a one-time > pop-up if ~/.kde4 exists would be enough.The question is where to integrate this? I don''t really see it. I''m in favour to do this right now: Use ~/.kde as default KDEHOME and patch startkde (or whatever kind of autostart) to show a message that it would be good to have a backup of ~/.kde if people are having important stuff in there. If they want, they can terminate the startup, do the backup, and restart KDE. Maybe a slightly similar message, if ~/.kde4 exists. Non-KDE users are alone in the wild now, but yeah, what should we do. At least right now I do not see a better solution which notifies everybody. Greetings, Armin
On Tue, 03 Feb 09 22:53, Armin Berres wrote:> Hi all! > > As you all know Lenny is near, which also means that our 4.2 packages will > enter Unstable in the very near future. Until today, we still have not decided > how to handle KDEHOME. > The current situation is, that KDE 3 applications use ~/.kde and KDE 4 > applications use ~/.kde4. The problem with this approach is, that no > data/settings are automatically converted to be used by KDE 4. > > The question is now: should we > a) continue to use ~/.kde4 for KDE 4 applications > b) use ~/.kde for KDE 4 applications.When looking at the thread it seems as if we will go with b). The question is now: Is anyone working on any kind of conversion tool? Of yes, wht is the timeframe until it will be usable? Greetings, Armin
On Wed, Feb 11, 2009 at 11:13:16PM +0100, Armin Berres wrote:> On Tue, 03 Feb 09 22:53, Armin Berres wrote: > > The current situation is, that KDE 3 applications use ~/.kde and KDE 4 > > applications use ~/.kde4. The problem with this approach is, that no > > data/settings are automatically converted to be used by KDE 4. > > > > The question is now: should we > > a) continue to use ~/.kde4 for KDE 4 applications > > b) use ~/.kde for KDE 4 applications. > > When looking at the thread it seems as if we will go with b). > The question is now: Is anyone working on any kind of conversion tool? > Of yes, wht is the timeframe until it will be usable? >Yeah, it looks like b) is prefered. So let''s plan with this option. In case nobody is interested in (or have time for) doing a settings migrating tool for the stuff that is not migrated by the apps [1], we always can setup a page (and also maybe a README in the packages?) with some hints for migrating the stuff and have some pointer when people yells: WHERE IS MY EMAIL? We have several cases: - User of KDE 3 going to KDE 4 when it enters in unstable. (base case) - Current user of KDE 4.2 who have already migrated settings. (nothing to do in our side, they have already migrated themselves) - And the hard one: user of KDE 3 using some KDE 4 stuff. They have .kde and .kde4 with data in both. Ana [1] For what I have understood in this thread, everything should be migrated, and when it is not possible, being ignored. And when it is not correclty migrated it is a bug to report to upstream.
On Thursday 12 February 2009 12:14:02 Ana Guerrero wrote:> [1] For what I have understood in this thread, everything shouldbe> migrated, and when it is not possible, being ignored. And whenit is not> correclty migrated it is a bug to report to upstream.That''s also my understanding. And ack to the rest of the mail. /Sune