Emerge : error while install kdelib on windows with emerge python 33 no module info

[Thomas Friedrichsmeier]

Hi,

On Wednesday 09 January 2013, Laszlo Papp wrote:
> We would need to fix those anyway as that is the last release. There are
> bugs everywhere, and I am sure there will be bugs in 4.9 not even
> considered. Still, I would consider a stable branch for newcomers, and fix
> the problem appearing.

agreed, if there *is* any newcomer friendly stable branch at all. My 
recommendation for 4.9 is simply based on my personal - and thus extremely 
narrow - experience. 4.9 gave me less trouble than 4.8. But yes, almost 
certainly there will be regressions, too.
 
> It is better to have less, but more stable branches now and also in the
> future in my opinion.

I agree. But which branches to focus on? master is a "natural" keep. Besides 
that we'd keep whichever branch(es) is(are) the focus for the next binary 
release(s). I used to assume that's kde-4.9.

But perhaps the real question is: *Is* there a release target/focus at all, 
ATM? (And if so, where would be the canonical place to read up on this?)

As far as kde-4.8 and older is concerned: Surely, having working "archives" 
would be fairly desirable(*). But IMO, that's not a top priority for emerge. 
If you want a stable *release*, you can use the binaries. But the key selling 
point for emerge is that you want to do development (or stand at the bleeding 
edge, watching develoment). For that purpose you're most likely to pick the 
youngest branches.

Regards
Thomas

(*): Talking about archives: Suppose, every time a release has been created, 
self-contained snapshots of the build root would be created (one for each 
arch), archived, and offered for download. I.e. something like what I've 
zipped up for kde 4.9, mingw4, 32bit (http://lists.kde.org/?l=kde-
windows&m=135541718223018&w=2). Interested developers (particularly, but not 
only, third-party devs) could simply download and unpack these, and be sure to 
get a working environment - even years later. I think that would be one great 
way to lower the entry barriers to KDE on Windows development.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20130110/08df06a8/attachment.sig>