Re: [Krusader-devel] Re: Krusader in KDE's SVN
I´m following the disscution from afar (Chile right now..), I havn´t commited any code for quite sometime and when I´ll come back I´ll probably concentrate on bug fixes - but I feel that the general mood is to accept the offer. I don´t feel that I should cast a vote on this matter due to the reasons above - but why don´t the krew vote on this issue ? If most people are comfartable with the idea - we can talk about details like saving history and the right point in time to do it later, if the krew rather contiue with the current SVN - than the details are irrelevent :) Keep up the great work (both on KDE and Krusader), Rafi. On Wed, Nov 26, 2008 at 12:40 PM, Sebastian Kügler [EMAIL PROTECTED] wrote: On Tuesday 25 November 2008 23:31:23 Jonas Bähr wrote: Since 2.0.0 would be our first KDE-4 release, it would be an acceptable point to beginn with a blank history. Sebastian, you mentioned possibly losing history as a disadvantage. Does this mean there is a chance to keep our history? Under which conditions? My svn knowledge regarding such migrations is limited, but I could only think of a replay of our repository. This does not really make sense As David said (and which might not have made it to the krusader list), it *might* be possible to import history using svk. But you need to talk to [EMAIL PROTECTED] about that. So I cannot be conclusive here. i think it has other advantages not mentioned here (mostly from PR perspective), but that aside, i would like to know which module krusader would be getting into. ideally, i'd like to see krusader in a package that usually gets installed by default, which (i *think*) is not the situation with extragear? I think extragear would be perfectly fine, at least for the beginning. Some of the most popular KDE apps, like Amarok, live in extragear. Plus, there we have the maximum of freedom. We can't claim our independence on the one hand and ask for inclusion in a core module on the other. Well, installed by default is ambiguous. If you're referring to kdebase, I think that is not an option for Krusader (at least not in the current situation). We're already shipping two filemanagers with it (while, with KDE4, we've tried really hard to get the number of apps in the standard modules down to one per type (i.e. one image viewer, one video player, ...). Extragear, to *me* sounds like a sensible option indeed, but ultimately it's up to module maintainers where Krusader can find its home. what do you think guys? I'm all fo a move as soon as 2.0 is out of the door. What does the rest of the Krew think? Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iQEcBAABAgAGBQJJLTW2AAoJEGdNh9WRGQ759JcIAIb77OkZcWQTEE43CPoKh4fC 9d2s1SsDPik1r6tCdmwbtoKhyKU4JJLuh+4cVWoOyjEBu79+NENAlo3Ysudn56UV 0BEJBk0+kJauZ0e02ri7nV08+g/EP9cWKVKWMr7KwAP8bW3HRG3CTYSzcybDNUVg 1KmoDXniF7N4J52cH1T5lgShpSiWiUCnLISiZzO5M4i5z2j2sejO1P/mTUhdMHnu G8m70kiCtZPVOHkR9eH+zMp3zi+0pNWJDxz5fnff5at+2AJ6GkyjU3JFrXRVXo4G EwIsWBNiqYJgkU3sied04jCinmMEIyeJ0L9x+dpwNTiutMgsrWYkuASeBeFZEhI= =wvve -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
reopen trunk for KDE 4.3?
Hi, I know we haven't implemented the whole always summer in trunk scheme, but I wonder if we can go ahead and branch KDE 4.2 and reopen trunk. Just for kopete alone, I have 3 patches, and a whole new protocol support plugin to integrate and I'm sure other projects would benefit from this as well. Thoughts? -- Matt ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: reopen trunk for KDE 4.3?
Op Wednesday 03 December 2008 23:17 schreef u: Hi, I know we haven't implemented the whole always summer in trunk scheme, but I wonder if we can go ahead and branch KDE 4.2 and reopen trunk. Just for kopete alone, I have 3 patches, and a whole new protocol support plugin to integrate and I'm sure other projects would benefit from this as well. Thoughts? The problem is that we are only setup to handle two active branches for the translations. Currently 4.1 and 4.2, if we branch off 4.2, we need to setup a third branch for translations. That said, I really think we should think about the 4.1.4 release, who are we actually going to do a pleasure with that release? 4.2 is around the corner and is so much better than a possible 4.1.4. Are trunk bugfixes being backported to the branch currently and tested over there? I don't think a lot of developers are testing that branch anymore. Our users are probably best served with a rocking 4.2. I'm not going to fight for this idea, it is just my opinion. Adventurous users can go to 4.2 beta1, stable users are already served with 4.1.3. So, just in my personal opinion, we can drop 4.1.4 and spent our energy to 4.2.0. Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: reopen trunk for KDE 4.3?
On Wednesday 03 December 2008, Tom Albers wrote: Op Wednesday 03 December 2008 23:17 schreef u: Hi, I know we haven't implemented the whole always summer in trunk scheme, but I wonder if we can go ahead and branch KDE 4.2 and reopen trunk. Just for kopete alone, I have 3 patches, and a whole new protocol support plugin to integrate and I'm sure other projects would benefit from this as well. Thoughts? The problem is that we are only setup to handle two active branches for the translations. Currently 4.1 and 4.2, if we branch off 4.2, we need to setup a third branch for translations. or would it make sense to ignore trunk until 4.2 is released for translations? so that the two branches being tracked would be 4.1 and the upcoming 4.2? for that matter, why are thranslations still being tracked for 4.1 when 4.2 is now in string freeze? should translators not be working on 4.2? (Honest questions, i know next to nothing about the translation procedures) So, just in my personal opinion, we can drop 4.1.4 and spent our energy to 4.2.0. +1 from me, for the imho good reasons you outline. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: reopen trunk for KDE 4.3?
A Dijous 04 Desembre 2008, Aaron J. Seigo va escriure: On Wednesday 03 December 2008, Tom Albers wrote: Op Wednesday 03 December 2008 23:17 schreef u: Hi, I know we haven't implemented the whole always summer in trunk scheme, but I wonder if we can go ahead and branch KDE 4.2 and reopen trunk. Just for kopete alone, I have 3 patches, and a whole new protocol support plugin to integrate and I'm sure other projects would benefit from this as well. Thoughts? The problem is that we are only setup to handle two active branches for the translations. Currently 4.1 and 4.2, if we branch off 4.2, we need to setup a third branch for translations. or would it make sense to ignore trunk until 4.2 is released for translations? so that the two branches being tracked would be 4.1 and the upcoming 4.2? for that matter, why are thranslations still being tracked for 4.1 when 4.2 is now in string freeze? Because 4.1.4 is planned for tagging in 10th of december[1]. should translators not be working on 4.2? (Honest questions, i know next to nothing about the translation procedures) Who says they are not working on trunk? For example, in 5 hours there have been 3 commits to the 4.1.x translation branch and 19 to trunk translation branch. Albert [1] http://techbase.kde.org/Schedules/KDE4/4.1_Release_Schedule So, just in my personal opinion, we can drop 4.1.4 and spent our energy to 4.2.0. +1 from me, for the imho good reasons you outline. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: reopen trunk for KDE 4.3?
On Thursday 04 December 2008 00:42:27 Aaron J. Seigo wrote: Hi, for that matter, why are thranslations still being tracked for 4.1 when 4.2 is now in string freeze? should translators not be working on 4.2? Every team can decide how to work. The german team switched to trunk a few weeks ago but I think some teams continue working in branches until the final release. Even if the strings there are frozen for quite some time, the translation might not be completed. If it is decided to copy 4.2 to branches and open trunk again, you put another pile of management work (and confusion?) on the translators. If only a few apps really need a place to commit (was that the reason?), consider the work/ dir an alternative. Talking about backports, http://websvn.kde.org/branches/KDE/4.1/?sortby=revview=log should give an impression of the backporting impact on 4.1. Unfortunately dir logs do not seem to load very easily in websvn. MfG ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: reopen trunk for KDE 4.3?
On Wednesday 03 December 2008, Albert Astals Cid wrote: A Dijous 04 Desembre 2008, Aaron J. Seigo va escriure: On Wednesday 03 December 2008, Tom Albers wrote: should translators not be working on 4.2? (Honest questions, i know next to nothing about the translation procedures) Who says they are not working on trunk? For example, in 5 hours there have been 3 commits to the 4.1.x translation branch and 19 to trunk translation branch. I assumed they were working on trunk primarily, I just wasn't sure why work continued in the 4.1 branch. Is this because it is what distributions are currently shipping, so there is value in improving translations for it? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
