headers
Aaron J. Seigo | 2 Jan 02:06
Picon
Favicon

Re: [PATCH] Making Soprano optional (again) in kdelibs

On December 30, 2009, Dror Levin wrote:
> Our problem is not with e.g. kmail using akonadi+mysql, but with kdelibs
> now *requiring* soprano+viruoso, even for people who only install it to
> get k3b running.

and the overhead of that is? i'm counting 5MB on disk here and two extra 
packages. seeing as without a functioning nepomuk, we end up with hobbled 
applications that seems a worthwhile trade off.

if the issue is that k3b doesn't use any of the libraries that link against / 
require soprano/virtuoso, then perhaps kdelibs could be broken out better in 
the packaging?

--

-- 
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 Development Frameworks
Permalink | Reply | 2 comments |
headers
Albert Astals Cid | 2 Jan 02:17
Picon
Favicon
Gravatar

Re: [PATCH] Making Soprano optional (again) in kdelibs

A Dissabte, 2 de gener de 2010, Aaron J. Seigo va escriure:
> On December 30, 2009, Dror Levin wrote:
> > Our problem is not with e.g. kmail using akonadi+mysql, but with kdelibs
> > now *requiring* soprano+viruoso, even for people who only install it to
> > get k3b running.
> 
> and the overhead of that is? i'm counting 5MB on disk here and two extra
> packages. seeing as without a functioning nepomuk, we end up with hobbled
> applications that seems a worthwhile trade off.
> 
> if the issue is that k3b doesn't use any of the libraries that link against
>  / require soprano/virtuoso, then perhaps kdelibs could be broken out
>  better in the packaging?
> 

IMHO asking the packagers to split kdelibs is too much, if we want a split 
kdelibs is something we should do.

Albert
Permalink | Reply | 1 comment |
headers
Dmitry Suzdalev | 1 Jan 18:16
Picon
Gravatar

Re: KDE/kdebase/runtime/platforms/win

Hi John, others!

On Friday 01 January 2010 00:59:01 John Layt wrote:
> I would note in my defence that I have been sticking to only the simplest
> of fixes and avoiding anything that might affect functionality.  What
> actually broke, I'm guessing the includes?
Apart from win compilation I guess you broke nothing :)

Let me repeat myself: I really think that this is a great thing you did with 
fixing krazy issues, my conserns were only about touching some core 
functionality while approaching the release.

And about "minor fixes" argumentation: I just really had several experiences 
when "totally tiny and trivial, can't EVER break anything" commits were 
introducing a weirdest bugs in a release. This comes mostly from my commercial 
software development background where such issues introduce a real PITA for 
all departments - that's why I have such reaction :) Maybe in KDE SC case it's 
not that hard, but still....

Well, it seems this time it went well - or I guess someone would already 
complain :)

> If they were
> interested, then they would have fixed them already :-)  The major stuff I
> leave for them to fix themselves, but few do.
Agreed. krazy fixes often are out of attention of the maintainers, so it's 
really good that someone keeps an eye on them, thanks :)

> December 16th, 2009: Tag KDE SC 4.4 Beta 2
> "... Only urgent fixes, such as those fixing compilation errors, should be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aaron J. Seigo | 3 Jan 02:54
Picon
Favicon

Re: [PATCH] Making Soprano optional (again) in kdelibs

On January 1, 2010, Albert Astals Cid wrote:
> IMHO asking the packagers to split kdelibs is too much, if we want a split
> kdelibs is something we should do.

i don't think we want to split up kdelibs as that just makes development 
itself more annoying/difficult. it seems more like something that some 
packagers want to limit the size of dependencies. we could perhaps offer 
guidelines or even something in the build system that makes it more evident 
what the library layering is in kdelibs, though. i mean, you can certainly put 
libplasma in its own package without problem if you wanted to. doesn't require 
changes in kdelibs (other than touching plasma/CMakeLists.tx), but beyond that 
i think this is really a packaging decision issue.

--

-- 
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 Development Frameworks
Permalink | Reply | 0 comments |
headers
Dirk Mueller | 6 Jan 17:33
Picon
Favicon

Re: 4.3.5?

On Sunday 27 December 2009, Allen Winter wrote:

> > > I am not sure people backported commits as all I personnally heard was
> > > that 4.3 was stopped.
> > Correct.
> should probably wait for "official Release Team" announcements in the
> future. I think we've been pretty good about making announcements.  If
> not, we should fix that.

So far there was no announcement about stopping 4.3 maintenance, as far as I 
know. 

IMHO a 4.3.5 makes sense, at least from the "fixes are good perspective". I've 
also received requests from the packagers at Redhat who would like to have 
some more fixes than 4.3.4 provides. 

How about announcing tagging to happen by January 21st and release a week 
later?

> Dirk? Sebas??

I'm pro another update. 

Greetings,
Dirk
Permalink | Reply | 2 comments |
headers
Dirk Mueller | 6 Jan 17:54
Picon
Favicon

KDE 4.4 RC1 time


Hi, 

the time for KDE 4.4 RC1 has come (actually it was supposed to be done 
yesterday). 

Are we okay with tagging? Any known blockers?

Thanks,
Dirk
Permalink | Reply | 0 comments |
headers
Sebastian Kügler | 6 Jan 18:51
Picon
Favicon
Gravatar

KDE Feel Good Release Planning

Tacky title notwithstanding, Dirk will tag -rc1 later tonight. We want this to be a 
Feel Good release, and settled with the following (for now, you might want to object, 
in that case: do it now):

- Tagging of rc1 tonight, in the coming hours
- RC1 gets out as soon as it "Feels Good", i.e. builds and is not an obvious lemon
- Branching 4.4/ and re-opening trunk happens when tagging RC2 (19th Jan) (*)

The rest, we want to keep as is laid out in the schedule.

After branching , we would like to stress that your main work branch is 4.4 then, so 
we can iron out a bunch of more kinks and make people even happier about 4.4.1 
(remember, that's what they'll all be using for half a year or more).

As to the later branching, it's a balance between "we want people to actually run and 
polish the release" and "we don't want to hold back to many people by too strict 
commit rules in the freeze". 

If everybody's OK with this, I'll change techbase.

http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule

Cheers,
--

-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Permalink | Reply | 3 comments |
headers
Tom Albers | 6 Jan 18:58
Picon
Favicon

Re: KDE Feel Good Release Planning

Op Wednesday 06 January 2010 18:51 schreef u:
> Tacky title notwithstanding, Dirk will tag -rc1 later tonight. We want this to
> be a 
> Feel Good release, and settled with the following (for now, you might want to
> object, 
> in that case: do it now):
> 
> - Tagging of rc1 tonight, in the coming hours
> - RC1 gets out as soon as it "Feels Good", i.e. builds and is not an obvious
> lemon
> - Branching 4.4/ and re-opening trunk happens when tagging RC2 (19th Jan) (*)
> 
> The rest, we want to keep as is laid out in the schedule.
> 
> After branching , we would like to stress that your main work branch is 4.4
> then, so 
> we can iron out a bunch of more kinks and make people even happier about 4.4.1 
> (remember, that's what they'll all be using for half a year or more).
> 
> As to the later branching, it's a balance between "we want people to actually
> run and 
> polish the release" and "we don't want to hold back to many people by too
> strict 
> commit rules in the freeze". 
> 
> If everybody's OK with this, I'll change techbase.
> 
> http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule
> 
> Cheers,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dirk Mueller | 6 Jan 19:31
Picon
Favicon

KDE 4.4 RC1 (4.3.90) tarballs uploaded


Hi, 

I just finished the first set of 4.3.90 (KDE 4.4 RC1) tarballs and uploaded 
them. kde-l10n still takes a few more hours, I'll upload them later. 

Please let me know of any urgent issues, we'd like to release this asap. 

Greetings,
Dirk
Permalink | Reply | 52 comments |
headers
Dirk Mueller | 6 Jan 20:01
Picon
Favicon

Re: KDE Feel Good Release Planning

On Wednesday 06 January 2010, Tom Albers wrote:

> The schedule says RC1 is branch point, I really don't see any urgent reason
> in this mail to deviate from that. If we want to we can change it for the
> 4.5 schedule of course...

Thinking a bit about it more, reasons for branching earlier: 

a) it was announced that way for months
b) kdepim merge back depends on early branch
c) camp KDE might want trunk to be open again. 

Therefore, I change my opinion and suggest to use the RC1 tag as a branch 
point for 4.4 branch. 

Greetings,
Dirk
Permalink | Reply | 1 comment |

Gmane