pkg kde talk - Feb 2009 - Uploads to lenny and the $KDEHOME dilemma

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

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

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 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.
>>
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

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

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...

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?

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.
>pppo
I 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,
> Armin
I 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

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.net
  Mostly +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 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.
That''s also my understanding.

And ack to the rest of the mail.

/Sune