Re: KDE 4.6 RC2 tarballs (try#1) uploaded

2011-01-08 Thread Funda Wang
But it seems the same for kdepim-runtime.

2011/1/5 Dirk Mueller :
> On Wednesday 05 January 2011, Funda Wang wrote:
>
>> In RC1, some l10n packages contain files for calligra. I hope it will
>> be fixed in RC2.
>
> I believe I fixed this for RC2.
>
> Greetings,
> Dirk
>
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: KDE 4.6 RC2 tarballs (try#1) uploaded

2011-01-04 Thread Funda Wang
In RC1, some l10n packages contain files for calligra. I hope it will
be fixed in RC2.

2011/1/5, Dirk Mueller :
> On Tuesday 04 January 2011, Andrea Scarpino wrote:
>
>> > We'll release it as soon as there is positive feedback from the KDE
>> > Packagers.
>> Hi, I don't see packages.
>
> Hi,
>
> now moved and kde-l10n packages added.
>
> Greetings,
> Dirk
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: KDE 4.6 Beta1 tarballs (4.5.80) uploaded

2010-11-21 Thread Funda Wang
I guess akonadi >= 1.4.54 is required for kdepimlibs.

2010/11/21 Rex Dieter :
> On 11/19/2010 01:44 PM, Dirk Mueller wrote:
>>
>> Hi,
>>
>> I just finished uploading the first set of tarballs.. I believe I need a 
>> couple
>> of more tarballs for those to work properly (akonadi etc), working on  that
>> now.
>>
>> Please let me know of urgent fixes/compile issues in those tar balls.
>
> Oh boy, another one,
>
>   * Akonadi (1.4.52 or higher)  
>     Akonadi server libraries (from kdesupport)
>     Akonadi is required to build KdepimLibs.
>
> -- Rex
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: KDE 4.5.0 tagged (1st try of tarballs uploaded)

2010-07-31 Thread Funda Wang
2010/7/31 Volker Krause :
> On Thursday 29 July 2010 14:09:45 Dirk Mueller wrote:
>> Hi,
>>
>> I just finished uploading the first set of KDE 4.5.0 tarballs to
>> stable/4.5.0/src. Please let me know of any blocking issues (JRiddels PyQt
>> 4.7 fix is not yet included I believe).
>>
>> kde-l10n tarballs are still building.
>
> I've uploaded the corresponding Akonadi server 1.4.0 tarball to
> download.akonadi-project.org.
I guess you've forgot doc subdir.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: KDE 4.2 RC1 (4.1.96) try#1

2009-01-09 Thread Funda Wang
2009/1/9 Andreas Pakulat :
> On 09.01.09 13:17:50, Nicolas Lécureuil wrote:
>> On Wed, Jan 7, 2009 at 5:11 PM, Dirk Mueller  wrote:
>> >
>> > Hi,
>> >
>> > I just finished uploading the first set of tarballs for RC1 under unstable/
>> > Please let me know if you find any issues, I've not yet started testing 
>> > them.
>> >
>> > Release is 2 days after 4.1.4 (so next week thursday tentatively).
>> >
>> > Greetings,
>> > Dirk
>>
>>
>> i have some pbs with latest sources on my rpms kdebase-workspace need
>>
>> /usr/lib/libkdeui.so
>> /usr/lib/libplasma.so
>> /usr/lib/libkdecore.so
>>
>> which wasn't needed for Beta2.
>>
>> In + kdepimlibs and kdebase-workspace can't be found and this is needed :
>
> See the kde-buildsystem list, this is because you've built kdelibs with
> a cmake 2.6.3 pre-release that doesn't yet know about the new search
> location for the cmake config-files. You need to either downgrade to a 2.6.2
> release of CMake or use a more recent rc of 2.6.3 (or update your
> checkout).
You mean rc5 is not recent enough?

>
> Andreas
>
> --
> Be free and open and breezy!  Enjoy!  Things won't get any better so
> get used to it.
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: [Krusader-devel] Re: Krusader in KDE's SVN

2008-11-26 Thread Funda Wang
Maybe kdeutils is a good place, if somebody wants to push krusader.
But of course, extragear apps have their own release schedules.

2008/11/26 Jonas Bähr <[EMAIL PROTECTED]>:
> Hi,
>
> Am 25.11.2008 um 19:36 schrieb shie erlich:
>
>> hi Sebas,
>> thanks for the informative mail.
>>
>> I, for one, feel confident that the time is right for krusader to
>> move closer together with kde.
>
> I do also think that it'll be great to move a bit closer to the KDE
> Project and to benefit from KDE's infrastructure (translations, review/
> bugtracking, marketing, ... perhaps even mailinglists).
>
> I feel very comfortable with the SVN Policies on techbase. If they are
> really applied by the guys with svn commit access (which would include
> us after the move) I don't think we will get in trouble with strangers
> doing unwanted code harakiri.
>
> In my eyes we could move immediately *after* the 2.0.0 release. We
> made a first beta for KDE-4 some time ago with a second one on the
> door step. I don't want to move in the middle of a release process.
>
> 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
>
>
>> 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.
>
>> 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?
>
> bye,
> Jonas
>
>>
>> thanks,
>> shie
>>
>>
>> On Tue, Nov 25, 2008 at 6:52 AM, Sebastian Kügler <[EMAIL PROTECTED]>
>> wrote:
>> Hi,
>>
>> Let me try to shine some light on some of the questions raised in
>> the "should
>> krusader move into KDE's SVN?" discussion. Please reply to both lists,
>> [EMAIL PROTECTED] and release-team@kde.org
>>
>> From the thread held on the krusader list, I'm sensing the
>> misconceptions that
>> being developed in KDE's SVN, it means you have to comply with KDE's
>> release
>> schedule. Not true, you can in fact decide that yourself. (Trade-off
>> is
>> basically between doing release management yourself and being free
>> to decide
>> when to release vs. having the KDE release team do it for you, but
>> you have to
>> respect the overall KDE release schedule then). That's your choice,
>> however.
>>
>> * rules
>> That depends largely on how you'd like to release. If you want
>> krusader to be
>> part of KDE releases (be it by means of extragear or some other
>> module),
>> you'll have to respect feature and string freezes. This kind of
>> comes with the
>> release management and translation the KDE team then does for you.
>> I'm not
>> aware of any other hard rules, but the policies page on techbase
>> gives more
>> info: http://techbase.kde.org/Policies (Note: not all applies to an
>> app like
>> krusader).
>>
>> * control
>> You remain in control. If you choose to have Krusader released with
>> regular
>> KDE releases, rules for that apply. Basically, you can decide how
>> you want to
>> have your release cycle, commit policies etc. Sometimes, people will
>> commit
>> into your code, in almost all cases, those are trivial fixes then. If
>> something that might raise objections go in, the committer should
>> (as usual in
>> KDE) contact the developers before committing. Everybody with a KDE
>> SVN
>> account has commit rights though. Basically, you can have Krusader
>> in KDE's
>> SVN and be as independent as you want.
>>
>> * advantages:
>> - less infrastructure maintainance
>> - more likely participation of developers that have a KDE SVN
>> account already
>> - code review, a lot of people follow commits and review patches (no
>> promise,
>>  it's just more likely due to increased visibility)
>> - can be released alongside KDE (whereever it ends up, even extragear)
>> - integration of SVN with bugtracker (Krusader is already using
>> bugs.kde.org,
>>  right?)
>> - translation done be KDE translation teams (manpower, consistency
>> across
>>  desktop)
>> - shows stronger KDE ties, taking a bit more advantage of KDE's brand
>>
>> * disadvantages
>> - possibly losing history
>> - migration effort
>>
>> I for one would be happy to welcome the Krusader team in KDE's SVN.
>> If there
>> are any questi

Re: Extragear KDE 4 stable branch

2008-08-04 Thread Funda Wang
2008/8/4 Tom Albers <[EMAIL PROTECTED]>:
> Op maandag 04 augustus 2008 00:04 schreef u:
>> Today i've been discussing with KTorrent maintainer the need for a KDE 4
>> extragear stable branch.
>>
>> And the outcome is that we need it.
>
>> That is why i'm asking to create a branches/stable/extragear-kde4/ where we
>> can put things in the same way we do with trunk/extragear so we can point the
>> translation scripts from the stable branch to that location.
>
> You probably expected this question, I'm going to ask anyway... ;-)
>
> What's wrong with /branches/stables/extragear/ ?
I think it will only contain really stable releases, i.e., those kde3 releases.

>
> Toma
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>
>
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team