Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
+++ This bug was initially created as a clone of Bug #224093 +++ the final version for kde-4.1 is released Reproducible: Always
Please do not file 0'day requests. When the maintainer doesn't react within a week, it's early enough to do so.
(In reply to comment #1) > Please do not file 0'day requests. When the maintainer doesn't react within a > week, it's early enough to do so. > sorry, but i was used to kde being in portage hard masked even in the beta an alpha stages, among other things, this was why i had chosen Gentoo: i am an early-adopter.
ebuilds for kde 4.1.0 already avalieble in overlay kdesvn-portage and they works =)
(In reply to comment #3) > ebuilds for kde 4.1.0 already avalieble in overlay kdesvn-portage > and they works =) > That overlay does not seem to be available via layman. Could you give more information (I'm sorry, but I am relatively new to overlays).
The overlay is still available... is your list of overlays sync'd? BEC-324 ~ # layman -f -a kdesvn-portage * Running command "/usr/bin/git clone "git://dev.gentooexperimental.org/kde-overlay.git/" "/usr/local/portage/layman/kdesvn-portage""... Initialized empty Git repository in /usr/local/portage/layman/kdesvn-portage/.git/ remote: Counting objects: 41828, done. remote: Compressing objects: 100% (24183/24183), done. remote: Total 41828 (delta 27448), reused 28991 (delta 16971) Receiving objects: 100% (41828/41828), 6.82 MiB | 575 KiB/s, done. Resolving deltas: 100% (27448/27448), done. Checking out files: 100% (1658/1658), done. * Successfully added overlay "kdesvn-portage".
(In reply to comment #5) > The overlay is still available... is your list of overlays sync'd? > > BEC-324 ~ # layman -f -a kdesvn-portage > * Running command "/usr/bin/git clone > "git://dev.gentooexperimental.org/kde-overlay.git/" > "/usr/local/portage/layman/kdesvn-portage""... > Initialized empty Git repository in > /usr/local/portage/layman/kdesvn-portage/.git/ > remote: Counting objects: 41828, done. > remote: Compressing objects: 100% (24183/24183), done. > remote: Total 41828 (delta 27448), reused 28991 (delta 16971) > Receiving objects: 100% (41828/41828), 6.82 MiB | 575 KiB/s, done. > Resolving deltas: 100% (27448/27448), done. > Checking out files: 100% (1658/1658), done. > * Successfully added overlay "kdesvn-portage". > Ah, I see. My bad, I said it didn't appear to be available as it didn't show up on layman -L. I'll add it now, thanks.
You probably just needed to run layman -f to syncronize your list of available overlays. Since layman is made to work with portage and not the other way around, nothing in layman will automatically syncronize when you 'emerge --sync' fyi. You'll also need to "layman -S" to update your layman overlays, or "layman -s kdesvn-portage" to sync that specific overlay. -- Matt
(In reply to comment #7) > You probably just needed to run layman -f to syncronize your list of available > overlays. > > Since layman is made to work with portage and not the other way around, nothing > in layman will automatically syncronize when you 'emerge --sync' fyi. > > You'll also need to "layman -S" to update your layman overlays, or "layman -s > kdesvn-portage" to sync that specific overlay. > > -- > Matt > Ran layman -f and still doesn't show up on list, but i did manage to add it anyway....weird
(In reply to comment #8) > > Ran layman -f and still doesn't show up on list, but i did manage to add it > anyway....weird It seems to be a git repository, do you have git installed?
(In reply to comment #9) > (In reply to comment #8) > > > > Ran layman -f and still doesn't show up on list, but i did manage to add it > > anyway....weird > > It seems to be a git repository, do you have git installed? > Uh, sorry, you wrote that you were able to add it.. I misread it and thought you still had problems :)
is there any roadmap to have it in official portage ?
(In reply to comment #10) > Uh, sorry, you wrote that you were able to add it.. I misread it and thought > you still had problems :) > It's all good, most of us are probably just as busy :) (In reply to comment #11) > is there any roadmap to have it in official portage ? That's something I'd like to know as well.
(In reply to comment #12) > (In reply to comment #10) > (In reply to comment #11) > > is there any roadmap to have it in official portage ? > That's something I'd like to know as well. Yes, as soon as we are able to.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #10) > > (In reply to comment #11) > > > is there any roadmap to have it in official portage ? > > That's something I'd like to know as well. > > Yes, as soon as we are able to. > What means? Is there shortage of needed Portage features or a shortage of manpower?
IMHO I think that EAPI 2.0 should be out before we could have KDE4.1 in portage [see genkdesvn webpage and why they switched to paludis].
(In reply to comment #15) > IMHO I think that EAPI 2.0 should be out before we could have KDE4.1 in portage > [see genkdesvn webpage and why they switched to paludis]. > IMHO its already works with portage and EAPI=1 see kdesvn-portage overlay =) and #gentoo-kde4-live on freenode =)
As we need to unmask qt:4 before we add kde-4.1.0 and we might opt to wait for 3.5.10 before putting the ebuilds in the tree, we're talking about using EAPI-2.
(In reply to comment #17) > As we need to unmask qt:4 before we add kde-4.1.0 and we might opt to wait for > 3.5.10 before putting the ebuilds in the tree, we're talking about using > EAPI-2. > Why not add kde 4.1.0 masked in portage and wait untill 4.1.1 will be released to migrate it to EAPI=2? There is no EAPI=2 avalieble only drafts 2_pre1 for portage-2.2rc6
(In reply to comment #18) > (In reply to comment #17) > > As we need to unmask qt:4 before we add kde-4.1.0 and we might opt to wait for > > 3.5.10 before putting the ebuilds in the tree, we're talking about using > > EAPI-2. > > > > Why not add kde 4.1.0 masked in portage and wait untill 4.1.1 will be released > to migrate it to EAPI=2? There is no EAPI=2 avalieble only drafts 2_pre1 for > portage-2.2rc6 > As the KDE project itself recommends users from 4.0.x to upgrade to 4.1.x I would strongly vote for this option. If it is not too much work to make it available masked I think it should be the way to go. Why wait for no reason if it is mostly "already done"?
totally agree, 4.0 didn't hit the portage for a stability reason, and this was really wise, now 4.1 is complet with kdepim and needs users to use, enjoy, and report new issues. and seems much more mature...
(In reply to comment #20) > totally agree, 4.0 didn't hit the portage for a stability reason, and this was > really wise, now 4.1 is complet with kdepim and needs users to use, enjoy, and > report new issues. > > and seems much more mature... > in kdesvn-portage overlay only kde-accsessibility missng for 4.1 for some reason but it's simple to make ebuilds for this part from -9999 ones
right...at the moment i'm waiting the official inclusion...i want to put in my celeron 650mhz machine and it will take a week to compile all....
Users of our company are waiting for KDE 4.1 to be available through portage instead of layman (even masked as KDE 4.0 is). SVN and git are blocked by corporate proxies which prevent us to upgrade. We can only get new ebuilds through emerge-webrsync :(
Agree with putting KDE 4.1.0 _AT LEAST_ masked in portage and then maybe unmask it in the future or directly unmask 4.1.1 when it'll be added.
(In reply to comment #24) > Agree with putting KDE 4.1.0 _AT LEAST_ masked in portage and then maybe unmask > it in the future or directly unmask 4.1.1 when it'll be added. > BTW I add missing accessibility apps to kdescn-portage overlay =)
I can't understand why not to put kdesvn-portage's version of kde 4.1 to portage. Even masked. 4.1 is better in all ways then 4.0.x
I would agree, I would love to see this added to portage official, even if it is masked, makes managing it so much easier than via a -9999 labeled overlay
To manage a trunk installation with paludis and genkdesvn repository is just easy. Anyway, we'll need to wait to EAPI=2 in order to have ebuilds for KDE4.1 (if they are slighty modifications of the trunk ones) in tree. Just give a look on any ebuild in that repository, or read: http://genkdesvn.mailstation.de/ru/news/polnyi-tekst-novosti/article/split-live-kde4-ebuilds-released.html?tx_ttnews[backPid]=36&cHash=9d8f1883d9 As they said, they improved kdebuild-1 EAPI too much for actual portage's implementation.
(In reply to comment #28) > To manage a trunk installation with paludis and genkdesvn repository is just > easy. > Anyway, we'll need to wait to EAPI=2 in order to have ebuilds for KDE4.1 (if > they are slighty modifications of the trunk ones) in tree. Just give a look on > any ebuild in that repository, or read: > http://genkdesvn.mailstation.de/ru/news/polnyi-tekst-novosti/article/split-live-kde4-ebuilds-released.html?tx_ttnews[backPid]=36&cHash=9d8f1883d9 > > As they said, they improved kdebuild-1 EAPI too much for actual portage's > implementation. > but we dont need paludis =) so why we must wait while ebuilds for portage *ALREADY* avalieble in kdesvn-portage overlay? Looks like a political issue not technical one :-/
I vote for adding ebuilds from kdesvn-portage overlay to official tree
I'd agree that 4.1 should be added to the live portage tree. It should be masked, but it should be there. Its a highly recomended upgrade from 4.0, and I can't think of a single reason why a person would not want to upgrade from 4.0 to 4.1. I won;t say that I believe the ebuilds from the kdesvn-portage should be used... I;m not qualified to make that judgement call on their quality, but they do seem to be working for most. Regardless of how it gets to portage... it should be there.. and it should be there relativly soon IMHO.
(In reply to comment #28) > To manage a trunk installation with paludis and genkdesvn repository is just > easy. > Anyway, we'll need to wait to EAPI=2 in order to have ebuilds for KDE4.1 (if > they are slighty modifications of the trunk ones) in tree. Just give a look on > any ebuild in that repository, or read: > http://genkdesvn.mailstation.de/ru/news/polnyi-tekst-novosti/article/split-live-kde4-ebuilds-released.html?tx_ttnews[backPid]=36&cHash=9d8f1883d9 > > As they said, they improved kdebuild-1 EAPI too much for actual portage's > implementation. > And now, please, read *very* carefully link, that you have provided. I will quote some for you: "(Please remember that you'll have to use Paludis from now on to use the *live* ebuilds from the overlay until Portage and/or pkgcore implement support for the greatly enhanced kdebuild-1 EAPI.)" Please, note "*live*", which is especially bolded. We are not speaking about "*live*" ebuilds, we are speaking about normal ebuilds, that *already works* with EAPI=1. When EAPI=2 will be released, ebuild's can be upgraded, but we must not wait untill some feature release, while this feature unneeded. Otherwise, we can wait for EAPI=3, EAPI=100, EAPI=12264...
yes, that's why i don't understand why you pasted that link, it's OT. 4.1 ebuilds are ready in the overlay. what's needed i just to merged them in official portage tree. all EAPI and live, paludis stuff is...other stuff. 4.1.0 is there. if for 4.1.1 any change to eclass is wanted....ok....different story.
mm.. may I dare say. Whatever the reasons are... gentoo users want kde 4.1, and they want it now.. they dont care about technical details. Until now, kde ebuilds were released almost at the same time as kde itself. I thought the problems were lack of developer time (it's summer time, vacation, and such), but it seems to be quite different here. users expect kde 4.1 in standard, vanilla (means : not paludis, note that i have nothing against paludis, i have never tried it), usual gentoo. PLEASE.
see what I don't understand is why this wasn't ready to go? it's not like we didn't know kde-4.1 was coming... and people would want it... and it was the 'user release' and people use gentoo because they want bleeding edge. regardless of what ebuilds that are being used this should be in tree now. Gentoo's falling behind and this is only somewhat of a time issues because there was a month to start prepping ebuilds. if we'd had pre-release beta's it would probably have been easy just to bump them to final.
(In reply to comment #34) > mm.. may I dare say. Whatever the reasons are... gentoo users want kde 4.1, and > they want it now.. they dont care about technical details. [...] This is not the right way to say it - we are all still users of an open source project - which means expecially for Gentoo: a) We should (to some extend) care about technical issues b) We shouldn't just say "We want it - now! We are the users ..." etc. bla bla The discussion about kde-4.1.x EAPI and similar topics are pointed out as part of this bug report but more "I vote for that" and speculations about "why it isn't there already" are not needed IMHO. I haven't read any "official" reply that might point out open issues or if help is required thought ... I want 4.1 too and I'm not interested in overlays because this means I have to recompile it when it's in the official tree ... but let the KDE team time to sort things out.
I really don't see why this version bump is such an issue for people. Yeah, I'd like to see KDE 4.1 in the official portage tree rather today than tomorrow, but then again, it's not too hard to install the kdesvn-portage overlay via layman, isn't it? And if the maintainers want to do the ebuilds "right" with paulis (or whatever), then let them. Gentoo is IMHO not about "0-day version bumps", it's about choices. And as long as I can choose to roll my own ebuilds and custom overlays, it's fine.
(In reply to comment #36) > I haven't read any "official" reply that might point out open issues or if help > is required thought ... I want 4.1 too and I'm not interested in overlays > because this means I have to recompile it when it's in the official tree ... > but let the KDE team time to sort things out. I was thinking exactly the same. An overlay for such a huge package isn't an option (at least for me), just think about the recompilation time when it hits the official tree because of eg different use-flags or another kind of slot-scheme. And the huge lack of missing communication. 4.1 has been available for eight days now and nobody officially (at least not visible from the user point AND the bugs' status is still new, not assigned) stated anything. Is the KDE-Team at the GUADEC in Istanbul? Are they on holidays? Or is there already WIP? Do they need help? It's the lack of information that makes this so annoying... btw, if it's really only a technical issue, then it should get hardmasked in the main portage tree. It's not like it is the first programm with technical issues around here....^^
This bug should be used to track the bump to kde-4.1.0 and not as another place to fuel any conspiracy theories. There's also no need and no point for user votes on how the kde team should act. For all those anxious to see the work of the kde team, you can track our work on http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary PS - Yes, it's possible to get ebuilds for kde-4.1 from the kde4-overlay, but the kde team needs to do its testing and its doing it on this overlay.
(In reply to comment #39) I agree that many comments should have been made in the forum or on the IRC. > There's also no need and no point for user votes on how the kde team should > act. Maybe not but you can see that this is - by far - the "most wanted" bug on Gentoo's bugzilla. I think that everyone in the Gentoo KDE team agrees with me that KDE4.1 has more right to exist in the official tree than KDE4.0 (which even has the official Gentoo KDE 4.0 Guide).
(In reply to comment #39) > PS - Yes, it's possible to get ebuilds for kde-4.1 from the kde4-overlay, but > the kde team needs to do its testing and its doing it on this overlay. Is there such a thing as 'kde4' overlay or do you mean the 'kde' overlay ?
kde 4.1 was available on debian testing at least from august 4th. It really feels strange to read this. Times change.
(In reply to comment #39) > This bug should be used to track the bump to kde-4.1.0 and not as another place > to fuel any conspiracy theories. > There's also no need and no point for user votes on how the kde team should > act. > > For all those anxious to see the work of the kde team, you can track our work > on http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary > > PS - Yes, it's possible to get ebuilds for kde-4.1 from the kde4-overlay, but > the kde team needs to do its testing and its doing it on this overlay. > So... Kde-team not accepting contributed by users work. They want to do everything by their own hands. Ok, there is nothing bad with it... But let's look for shortlog of kde *overlay*: http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=shortlog Let's see... 2days ago there was initial commit of kde-4.1 tree, actually after 7 days after release of kde-4.1 itself... And, there is no kde-4.1_rc/alpha/beta releases. They was never officially noticed (while kdesvn-portage, which is *portage* compartible version of kdesvn overlay, was releasing every rc/alpha/beta etc). So, this is nothing strange, that kdesvn-portage team was ready within 1 ("one") day after final release - they simply was well-prepaired for this. And now, reaction time of official KDE-team is 5 days, let's take this as normal. But after 2 days it's released only 1, 2... 20 ("twenty"!) packages from all of kde-4.1 packages. And there is only 1 ("one") active mantainer. So, we have quite an interesting situation: 1) We have kdesvn-portage overlay, with working, portage compartible, ebuilds for *all* packages. 2) We have official kde overlay with 20 packages. 3) We have 1 official mantainer, that was sleeping somewhere while kdesvn-portage team was working on alpha/beta/rc releases. 4) We have some... strange... explanations that we must wait for EAPI=2, some abstract ideas, that ebuilds depends on paludis, showing that actually developers even not look at them. 5) And we have a fact, that debian released kde-4.1 packages officially before Gentoo So, now _I_ see, that all talks about EAPI and other stuff is only tricks to have more time to make official ebuilds. It looks like a propritary position. Why not just take overlay ebuilds, place it in portage in hardmasked state ("masked for testing" - quite a heavly used explanation for hardmask). and _than_ make whatever you want - rewrite them all from scratch, or test them and unmask later. For now you just dropping all user-contributed work for _unknown for community_ reason. And now you saying that we are "fuel conspiracy theories". Actually, we are *NOT* fuel "conspiracy theories", but *YOU* do this. If you have any *TECHNICAL* explanation why kdesvn-portage ebuilds must not go in portage (while actually all packages was already tested for working by users), and _then_ be tested. We are users, yes. And we want kde-4.1 NOW, yes. And we GIVE you working realisation. You can accept it or drop it, but you must EXPLAIN your desision, because you pointing youself as _open_source distro, not proprietary. Otherwise, community will build it's own "conspiracy theories" and consecuenses may be much worse than just theories.
Full ack here! gentoo had to release things faster or gentoo will lose their users ... I hope there will ((hard)masked) kde 4.1 packages in portage soon.
P.S. Please, understand me correctly. I don't want to say, that you must drop all and do it, I understand that everybody here is volunteers. But you was choosen as more clever, more able user from community, and community trust you to do this work. If you not able to do what you have choosen for and don't want to accept what community give to you - go back and give others to do this.
ehi ehi ehi. what's this now? i want to tell you: i am in the list of people really really pissed off of lack kde 4.1 in portage. BUT. what u wrote is way too much. firstly don't say anything personal like "sleeping", "go back" and so on. Maybe everyone is on holiday or busy with the job. Feel free to join gentoo dev, it's free and you can join. I'm an old date gentoo user and i follow bugzilla continusly there are some of my bugs opened since 2 year and maintener is "sleeping" like u say. And i see that, in my opinion, community and devs are every day more different and far. but this is nothing relatedto this bug, you can discuss in forums on ml. do you think any comment like this is going to speed up 4.1 inclusion? totally not, just flaming. I think they understood we have ready ebuilds, lots of ppl waiting for them and some would like to know details and reason (me in these lists). But I don't think your post will help anyhow.
yes, I agree that communication really seems to be the very problem here.. i dont know about paludis or the different overlays, and dont want to know about it. I just use vanilla gentoo. Is that true that some overlays have working ebuilds and they are not imported ? then why ? any official statement about it ?
(In reply to comment #43) (snip lots of flames, attacks and ignorance based comments) I lack the words to reply and will keep the feelings to myself.
(In reply to comment #43) > So... Kde-team not accepting contributed by users work. They want to do > everything by their own hands. Ok, there is nothing bad with it... Every contribution from users have to be checked. That has nothing to do with the KDE team, it is true for everything contributed to Gentoo. > But let's look for shortlog of kde *overlay*: > http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=shortlog > > Let's see... 2days ago there was initial commit of kde-4.1 tree, actually after > 7 days after release of kde-4.1 itself... And, there is no > kde-4.1_rc/alpha/beta releases. They was never officially noticed (while > kdesvn-portage, which is *portage* compartible version of kdesvn overlay, was > releasing every rc/alpha/beta etc). So, this is nothing strange, that > kdesvn-portage team was ready within 1 ("one") day after final release - they > simply was well-prepaired for this. Please stop the mocking. > So, we have quite an interesting situation: > 1) We have kdesvn-portage overlay, with working, portage compartible, ebuilds > for *all* packages. > 2) We have official kde overlay with 20 packages. > 3) We have 1 official mantainer, that was sleeping somewhere while > kdesvn-portage team was working on alpha/beta/rc releases. > 4) We have some... strange... explanations that we must wait for EAPI=2, some > abstract ideas, that ebuilds depends on paludis, showing that actually > developers even not look at them. > 5) And we have a fact, that debian released kde-4.1 packages officially before > Gentoo Again, stop the mocking. > Why not just take overlay ebuilds, place it in portage in hardmasked state > ("masked for testing" - quite a heavly used explanation for hardmask). and > _than_ make whatever you want - rewrite them all from scratch, or test them and > unmask later. For now you just dropping all user-contributed work for _unknown > for community_ reason. Why would it make anything better, if the KDE team would just copy the kdesvn-overlay ebuilds and hard mask them? If you feel fine using those and trust the maintainers enough, then you could as well use them in the overlay. So that wouldn't improve the situation at all. Plus... See, it's not that easy to take those ebuilds. They are from an untrusted (saying nothing against the maintainers, but they are not gentoo developers, nor do the KDE people know about their ebuild creating skills) source, which means, that every ebuild *has to be checked*. Now if you would have ever done a KDE bump and know enough about the eclass/ebuild structure of KDE4, then you would know, that that basically is the same amount of work as creating them from scratch. (A little bit less, but it won't really speed up anything.) And no, these checks can not be dropped. > And now you saying that we are "fuel conspiracy theories". Actually, we are > *NOT* fuel "conspiracy theories", but *YOU* do this. I'm saying, that you should calm down and mock somewhere else. What you are doing here won't help anyone. > If you have any *TECHNICAL* explanation why kdesvn-portage ebuilds must not go > in portage (while actually all packages was already tested for working by > users), and _then_ be tested. See above. These ebuilds have to be expected to contain major mistakes (quality assurance means to expect the worst). I didn't really have a look at the ebuilds, so no, I can't tell you if it is only one or maybe 200 mistakes. But one is definitely there: kalzium/kalzium-4.1.0.ebuild: if use solver && ! built_with_use dev-lang/ocaml ocamlopt && ! built_with_use dev-ml/facile ocamlopt ; then There might be more, I don't know, since I didn't check them, so the rest might be ok. But that is exactly the big unknown thing that would have to be sorted out and which would cause just as much work as creating the ebuilds. > We are users, yes. And we want kde-4.1 NOW, yes. And we GIVE you working > realisation. You can accept it or drop it, but you must EXPLAIN your desision, > because you pointing youself as _open_source distro, not proprietary. > Otherwise, community will build it's own "conspiracy theories" and consecuenses > may be much worse than just theories. What on earth has that to do with an open vs. a proprietary distribution? (In reply to comment #45) > P.S. Please, understand me correctly. I don't want to say, that you must drop > all and do it, I understand that everybody here is volunteers. But you was > choosen as more clever, more able user from community, and community trust you > to do this work. If you not able to do what you have choosen for and don't want > to accept what community give to you - go back and give others to do this. > Nobody is chosen to be a Gentoo developer. You don't have to be clever to be a Gentoo developer. You just have to pass a test and convince your mentor that you understood how to do things.
I would also like to point out that jmbsvicetto has been cooperating with the kdesvn-portage maintainers and helped improving our overlay, in particular improving and QA'ing the 4.1.0 ebuilds, for a while now, so accusations that he had been sleeping or whatever are misplaced and unfair. <Sput>
(In reply to comment #49) > Nobody is chosen to be a Gentoo developer. > You don't have to be clever to be a Gentoo developer. You just have to pass a > test and convince your mentor that you understood how to do things. I know this is a little bit offtopic, but let me make a point. I'd love to help, but I consider the test and "convincing a mentor" to be a quite childisch way to recruit help from the community. I'd be willing to do these steps when applying for a paid job - but *not* for a open-source community. It would be a good idea if gentoo would reconsider this policy - I've seen shortage or manpower in a lot of projects (for example, in some java packages) and it's not very helpful to make people whilling to help pass a job-interview.
But there no any good reason why kde-team doesnt prepere ebuilds for kde-4.1.0 while it was done in kdesvn-portage overlay... There were prereleases for kde 4.1 (4.0.80-4.0.99) and all of this prereleases was in kdesvn-portage. So why kde-team doesn't do their work in right time? PS i dont think that whole kde-team has thiir vocation from may till kde-4.1 release. i just cant believe that =)
(In reply to comment #49) Thanks for the explanation. I think that was the one thing really needed for people, like me, who are heavily waiting for kde-4.1 in portage. The second being an estimate release date, iy you can give one. Now there's one thing to consider, though. More than a week was not a delay the kde team get us used to, so i guess we might consider the following cases : - this is special due to the particular changes between 4.0 and 4.1. Following changes will be much simpler, thus quicker - this is due to manpower shortage, and could become more frequent in the future In the second case, i think recruitment should be done in the gentoo kde team so that we'll get back to the very quick release time we used to have. So that subsequent releases will get released as quickly as the gentoo kde team get us used to.
(In reply to comment #49) > (In reply to comment #43) > See above. These ebuilds have to be expected to contain major mistakes (quality > assurance means to expect the worst). > I didn't really have a look at the ebuilds, so no, I can't tell you if it is > only one or maybe 200 mistakes. But one is definitely there: > kalzium/kalzium-4.1.0.ebuild: if use solver && ! built_with_use > dev-lang/ocaml ocamlopt && ! built_with_use dev-ml/facile ocamlopt ; then > > There might be more, I don't know, since I didn't check them, so the rest might > be ok. ok look at kalzium ebuilds in official portage tree and you'll see the same constriction (both for 3.5.x and 4.0.x) ebuilds in kdesvn-portage overlay has almoust the same quality as in portage ones =)
(In reply to comment #54) > (In reply to comment #49) > > (In reply to comment #43) > > See above. These ebuilds have to be expected to contain major mistakes (quality > > assurance means to expect the worst). > > I didn't really have a look at the ebuilds, so no, I can't tell you if it is > > only one or maybe 200 mistakes. But one is definitely there: > > kalzium/kalzium-4.1.0.ebuild: if use solver && ! built_with_use > > dev-lang/ocaml ocamlopt && ! built_with_use dev-ml/facile ocamlopt ; then > > > > There might be more, I don't know, since I didn't check them, so the rest might > > be ok. > > ok look at kalzium ebuilds in official portage tree and you'll see the same > constriction (both for 3.5.x and 4.0.x) No, not at all. > ebuilds in kdesvn-portage overlay has almoust the same quality as in portage > ones =) That's a big claim. But I don't want to concentrate on one specific issue. I just had a look and found one, because anyone would have asked anyway. Of course they can now fix that, but that is really not the point. The point was to make it clear, that you can't just copy the stuff without checking. I hope that got through. :) (In reply to comment #53) > (In reply to comment #49) > > Thanks for the explanation. I think that was the one thing really needed for > people, like me, who are heavily waiting for kde-4.1 in portage. The second > being an estimate release date, iy you can give one. > > Now there's one thing to consider, though. More than a week was not a delay the > kde team get us used to, so i guess we might consider the following cases : > - this is special due to the particular changes between 4.0 and 4.1. Following > changes will be much simpler, thus quicker > - this is due to manpower shortage, and could become more frequent in the > future > > In the second case, i think recruitment should be done in the gentoo kde team > so that we'll get back to the very quick release time we used to have. So that > subsequent releases will get released as quickly as the gentoo kde team get us > used to. > Well, I am really the wrong person to speak to. I neither use Gentoo nor do I work on the KDE stuff anymore. I just wanted to point out a few things, that people who were never involved in creating ebuilds (with eapi 1 or kdebuild-1) for KDE, are likely to get wrong.
(In reply to comment #49) Currently manpower appears to be wasted. It can't be the right thing to have developers split up into two classes ('real' gentoo devs and devs from the community) and then have both devs doing the same work twice. Even if reviewing the kde4.1-ebuilds from the overlay takes as long as creating own ebuild, it might be worth the efford. Because in the end, those overlay-developers might become 'real' gentoo developers and support the kde-team in the future.
Stop komplaining you kidiots (kids + idiots = kidiots in kde) It will be koming to portage soon. I am sure gentoo team is doing their best. even if not, I am pretty happy with what I get. Great kommunity!
I'm waiting for KDE 4.1 as well - the one thing that bothers me actually is not resources or availability, but lack of information. Whenever there has been a previous KDE release, the ebuilds have been in the tree, usually before the release even. There's been good, informative announcements about what's going on - hell, there was even newsletter about KDE 4.0. With 4.1 it's been...zippo. Nothing. Even this bug report contains nothing. The big sticky thread in the forums (http://forums.gentoo.org/viewtopic-t-639443.html) contains nothing. So would it be too much to ask to have a nice post on forums, or even at gentoo.org's front page that KDE 4.1 will be out in the tree 1/2/3/4 weeks from now, and if it's >1 weeks, what are the reasons. Right now it feels that KDE team is in some ivory tower with very little communication about what's the actual STATUS of the project. So, you need EAPI=2. When's that going to happen? As in, date?
One thing a lot of commenters don't seem to have understood here: The kdesvn-portage overlay has not been created from scratch, and what will end up as 4.1.0 in the tree isn't either. The kdesvn-portage overlay was forked from genkdesvn when that decided to switch to Paludis. It is based in part on genkdesvn and on the existing 4.0.x ebuilds in the tree. It has been made portage-compatible, tracks progress, changes and additions upstream and has seen continuous improvements over time, as it received more testing from the community. This does not change the fact that it wasn't created from scratch; also it should make clear that its structure, eclasses and general ebuild format are pretty close to what is needed in portage. jmbsvicetto has during the past few weeks been helping getting the 4.1.0 ebuilds from kdesvn-portage in shape. So he hasn't been and still isn't reinventing the wheel. I assume what's going into his overlay currently (which will eventually end up in the portage tree) are more or less our ebuilds, probably with additional bugfixes and improvements where they pop up, but by no means he is doing all the work the overlay did yet again. He also tracks the overlay's development, being in #gentoo-kde4-live, and he even has commit access to our overlay. I would expect that this cooperation will continue in the future, with kdesvn-portage being the experimental stage tracking mostly live upstream development (and probably continuing to provide snapshots too) and (parts of) the KDE team improving on that work to get stable releases into portage. If there is a split into two classes, it's not between the KDE team and overlay maintainers, but between the people supporting only Paludis and those who want to continue to support portage as well. If the former group wants to explore the extra features Paludis has, that's fine as trying out new things never hurts (plus things that turn out to be real useful in Paludis have inspired and will inspire Portage development as well, so everybody benefits). I personally would wish that the two groups cooperated more closely (by exchanging experience, bugfixes, etc.) rather than wasting their time over political issues, but oh well. Still, I wouldn't call the time going into the development of the two overlays a waste of manpower, since the two groups have different goals and you can't try something completely new and at the same time stay compatible to the existing stuff without doing some things twice. Maybe at some point, both sides will be able to get over their personal issues and political arguments, and actually benefit from each other. Yes, I am an optimist. As for now, you have several options: - Use the 4.1.0 (or the live ebuilds) from kdesvn-portage and help by giving feedback, which will most probably help jmbsvicetto with his work as well - Use what is already there from jmbsvicetto's own overlay, giving him feedback directly - Wait until 4.1.0 has been prepped and tested and goes into the portage tree Flaming jmbsvicetto for being lazy, uncooperative, suffering from the NIH syndrome and whatnot is not an option, since it's not justified at all, and certainly doesn't help with his motivation (hence, it certainly does not speed up inclusion of 4.1.0 in the portage tree). Flaming the Paludis-only supporting members of the KDE herd will not help with 4.1.0 inclusion either, since those guys certainly will not suddenly reverse their opinion and go back to Portage. If anything, this increases the time that is needlessly wasted over political issues. Let them work on their own project, and support the ones willing to help with Gentoo/Portage instead. Whining over the lack of manpower of the KDE herd is also not helping. Become a developer and help them instead, or help the kdesvn-overlay which certainly eases the KDE herd's workload by fixing and testing things. By all means, stop the endless flaming in this thread. We all want to have 4.1.0 in the portage tree ASAP, we all know that, the KDE herd knows that as well, so reiterating this won't help anybody. All you do in here currently is demotivating the developers and slowing down the process even more. <Sput>
I'd like to try out KDE 4.1, from portage, that's why I reported this "bug". But please don't be in such a hurry, it won't solve all your problems. Is it better than 4.0? Yes. Is it what you're waiting for, the KDE4 ? No. So calm down, please! according kedevelop-devel: 2008/8/7 Alexander Dymo <dymo@ukrpost.ua>: > I completely agree here. The situation now is a bit different than it was > several years ago where KDevelop 3.0 (and 3.1) supported KDE 3.0, 3.1 and 3.2. > First, KDE 4.0 and 4.1 releases are not good (comparing with 3.0 and 3.1 of > course). Only 4.2 promises to be the the first usable one. > Second, the new 6 month schedule makes it less important to support older > versions. > _______________________________________________ > KDevelop-devel mailing list > KDevelop-devel@kdevelop.org > https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
And once again the sentence that you should think about before you start arguing with the gentoo kde team: "Only 4.2 promises to be the the first usable one."
(In reply to comment #60) > Is it better than 4.0? Yes. > Is it what you're waiting for, the KDE4 ? No. > So calm down, please! Why are you try to decide what will be better for me? I know many people who use another distros and they are as a users think that kde4.1 is ready to be used. All of us want to have a kde-4.1 in the official tree, sometimes just because other (suse, bubuntu etc) have it. To KDE-Team. For now all that I want to know is an expectation date for the first ebuilds drop. If you have not enough resources, give masked ebuilds to the community, and we will test it.
:) I didn't decided anything. I just informed you about the facts, that KDE4.1 worths the _waiting_, but nothing more. I was hopeing that you are going to be happy to hear some news, till the kde team does his work. If you're reading the kdevelop-devel list too, and you're aware these facts already, just ignore my comment at all, as you're ignored that i asked you to calm down.
Other distros doing things differently. Ubuntu has Canonical behind it. Maybe thats why Ubuntu had working Kopete/MSN and Konqueror/SSL in 4.0.x and Gentoo didn't. At least for me. P.S.: the above are my opinions strictly
Everyone, After waiting awhile with no avail for kde 4.1 to be in the main repository, I switched to paludis. Before today, I had heard of it, but didn't want to do it because I thought of gentoo as portage / emerge territory, and the image of other package managers in my mind conjured up ideas of dpgk (apt-get) and rpm. (I like apt-get, but I like portage better) I like use flags, I like compiling, I like the gentoo way, and the gentoo way was emerge. BUT, you're not going to believe me, I installed paludis, and it is the gentoo way - but 10 times better. The layout of the configuration files make much more sense, the idea of a repository and sets are so much better, and the syntax to paludis is just better (it takes 5 mins of getting used to). Its basically like portage, without bugs, prettier, and faster. Seriously, I must sound like a n00b, and I've used gentoo for some years now, but paludis is wonderful. Were all about choices in this community, and paludis is the best choice :P Portage is great, but its been around for a while and I would immagine that the developers of it did not anticipate all this complexity we have now (portage 2.2 just got the concept of a set). So adding it on was difficult and led to bugs (as the paludis people say). But starting from what we know of gentoo now, paludis has been designed to take all that into account.
paludis with its own fromat kdebuild-1 adn some other incompatible stuff like config system is like a bicycle on square wheels and caterpillars =) Some individums use this bicycle on some other distros like exherbo. and looks like that most part of gentoo-kde-team migrates to exherbo and paludis. So they want support regular portage users anymore. =(
I don´t think that this Bug entry is the right platform to discuss pro & contra of portage or paludis. As long as you can use the overlay for KDE 4.1 everything is fine. This is the idea behind overlays that everyone can use them to geht his desired version of KDE or other programs and the official teams have time enough for importing anything into the official tree. Users firewalled or proxied in companies may have problems with overlay but actually it would be possible to mirror the overlay by snaphoting it and host it internal. Many ways lead to Rome :)
1) Building from overlay, if you counts your time - is a bad idea. KDE is too big, to be rebuilded twicely flawlessly. 2) KDE4.1 much better than KDE4.0 and users, who want to use kde-4 (for many reasons, and first of them - perfomance), want to switch to KDE4.1 asap. 3) If generally idea of rewriting from scratch is a good idea - it makes code cleaner and, maybe, better, it takes it's time. In current situation, IMHO, it is too late to rewriting or major testing. Even more - if current kde-team developer was involved in kdesvn-portage work, he can trust them. So, only primitive chech for things like 'rm -Rf /', written by some evil forces, of course, is needed. 4) There is no officially published reason for using EAPI=2. 5) And there is absolutlly no reason for... tricking community, talking about paludis/EAPI/QA and other things. This is why my previous post was agressive. 6) If all kde-team developers really goes to paludis/exherbo/etc... what they are doing in gentoo/portage team? Actually, only developer working on such big problem as kde... Maybe it will be wiser to invite kdesvn-portage members as regular gentoo developers - they already prove themselfs as capable and adequate developers, releasing kde-4.1 and all pre-releases just in time. For me: there is no fail of developers, they could have their own private reasons why this work was not done at time. But now you can't just come and work as planned before. Now is too late, and kde-team, imho, must release kde-4.1 ebuilds copied from kdesvn-portage in hardmasked state (with proper reason in package.mask), and then, if they want, they could rewrite or redesign the whole system and eclasses for EAPI=2/3/15 or whatsoever, but _then_, when people who wants kde-4.1 now will be happy with hardmasked release (if they installed hardmasked 4.0 - there will be no problem about hardmasked 4.1). Others will silently wait for kde-4.1 (or kde-4.2) in unmasked state. But this others will know, that kde-4.1 is in official tree and availible.
First of all: things needs to be written good from start: writting some code which just works and to be later modified leads to disaster in big projects and more bugs than needed (In reply to comment #68) > 5) And there is absolutlly no reason for... tricking community, talking about > paludis/EAPI/QA and other things. This is why my previous post was agressive. There is no reason? You want an explanation or you just want, "kde 4.1 won't be available at the moment"? The KDE herd is not guilty of retarding KDE 4.1 just because they thought to use a feature not available currently at portage (use dependencies for example) to simplify code would be better... Of course, I am not a developer, but what makes more sense: using use dependencies and things not implemented in EAPI1 with only *ONE* compilation, or having a nasty/working/buggy/unstable buildsystem (which reinvent the wheel trying to provide those needed use dependencies and so on) which could lead user to recompile several times after some update or even to have unexpected bugs? Anyway, gentoo is *ABOUT CHOICES* (http://www.gentoo.org/foundation/en/) and ***NOT*** as much say, a bleeding edge distro!! So maybe it's worth the waiting. This will be my last message here as I don't want to start any war, so I will remain CCed to be informed when KDE4.1 is available, but I won't write more, and I beg more than one, to do the same...
Ok. If kde-team want put existing kde ebuilds to portage may be kde-team can provide some *GOOD REASONS* (tm) why they want do it? Reason like they want EAPI=2 isn't good =) PS Looks like there only one dev in kde-team that works with portage and gentoo (jmbsvicetto) others were switced to paludis and exherbo. So in curent state there no kde team at all =( So may be we must fill gentoo devrel bug about kde-team?
(In reply to comment #69) > There is no reason? You want an explanation or you just want, "kde 4.1 won't be > available at the moment"? At least. Bad truth always better than good lie. But it will be much better to have complete explanation why kde-team doing their work in such way and not in another. > The KDE herd is not guilty of retarding KDE 4.1 just because they thought to > use a feature not available currently at portage (use dependencies for example) > to simplify code would be better... > Of course, I am not a developer, but what makes more sense: using use > dependencies and things not implemented in EAPI1 with only *ONE* compilation, > or having a nasty/working/buggy/unstable buildsystem (which reinvent the wheel > trying to provide those needed use dependencies and so on) which could lead > user to recompile several times after some update or even to have unexpected > bugs? Update for EAPI=2 could be done for 4.2.0, which is intended to be "first usable". So 4.1.0 can also be permanently hardmasked (or rewriten from scratch when EAPI release will be done). Doing such big work as kde ebuilds basing on _beta_ release of some feature quite silly - it may lead to much more useless work of rewriting if something will change. > Anyway, gentoo is *ABOUT CHOICES* (http://www.gentoo.org/foundation/en/) and > ***NOT*** as much say, a bleeding edge distro!! So maybe it's worth the > waiting. There is no matter what official description says. Only users expectations from distro matters. If users see Gentoo as bleeding edge distro - it must be bleeding age, or users will switch to another distro. > This will be my last message here as I don't want to start any war, so I will > remain CCed to be informed when KDE4.1 is available, but I won't write more, > and I beg more than one, to do the same... > So you think, that only active developer in kde-team is ok? If yes - be ready to wait much more than even mounth - there is ~270 packages in kde4.1 and current 'add-speed' is about 6 packages per day. (In reply to comment #70) > > So may be we must fill gentoo devrel bug about kde-team? > Actually, this seems to be only way. All non-portage (and non-gentoo) developers must release their places in kde-team to make recruiting of new members availible.
I'd be happy to help the KDE team if they wrote out specific needs. I'm happy to run ebuilds on my AMD64 system or run an x86 version in VMWare. They just need to ask for help!
(In reply to comment #70) > So may be we must fill gentoo devrel bug about kde-team? On what grounds? Is "not bumping ebuilds fast enough" a reason for disciplinary action?
Do I get this right?! "KDE4.1 sucks, we're going to wait for 4.2" - Again?! So the KDE-Team is just going to do nothing but waiting for 4.2, hoping to sit this out without getting fired? I wasn't exactly 'amused' when they did this with 4.0. But now, knowing that there was plenty of time to come up with something, I'm quite pissed. Even though there is very little information from official side, imho this turns out to be some religious/political issue. Get over it!!! KDE is far to important to fool users like this. I totally agree with Night Nord: This is exactly the kind of annoyance forcing people to switch to another distro.
(In reply to comment #74) > But now, knowing that there was plenty of time to come up with something, I'm > quite [XXX] Nah, one has to take into account that it wasn't until 01/26/08 that KDE disclosed the official release date of KDE 4.1.0 ( http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Release_Schedule&direction=next&oldid=18538 ). A mere 6 months to react... and they even hit that date spot on...
(In reply to comment #73) > (In reply to comment #70) > > So may be we must fill gentoo devrel bug about kde-team? > > On what grounds? Is "not bumping ebuilds fast enough" a reason for > disciplinary action? Actually - yes. KDE _team_ was created to be sure that new releases will be "ebuilded" in time (and will be unified, clear and better). To make this possible - they have to predict future releases and prepare their overlays for new releases - as kdesvn-portage team does. To make _this_ (preparation) possible - it is a _team_ - not single developer - to be sure, that at least one-two active developers will be prepairing. For now we have only active developer and quite a number of actually retired developers - this is not a team at all. Summary: kde-team does not exists. There is only one mantainer, who not able (for simple reasons) to complete work proposed for whole team in time. Devrel bug NOT means, that kde-team failed - it just not exist. This bug must inform devrel team about this problems, to make them investigate current KDE-team status, exculde from it developers gone to paludis/exherbo (if they want - they could create their own team) and recruite new developers. To be short: we don't need to have "disciplinary action" against kde-team or it's members - it must be just cleaned-up and reorganised. Devrel bug - important and necessary action. But it will help for future releases. For this release only way is just to import kdesvn-portage ebuild's in hardmasked state. P.S. Recruiting (imho) must be done from kdesvn-portage team (with simplified and _faster_ testing procedure) and from existing Gentoo developers - just to make this process as fast as possible.
(In reply to comment #76) > This bug must inform devrel team about this problems, to make them > investigate current KDE-team status, exculde from it developers gone to > paludis/exherbo (if they want - they could create their own team) Why? Why aren't Paludis users or Exherbo developers allowed to be in the KDE team? Members of both DevRel and the Council have stated quite explicitly that Gentoo developers are allowed to work on non-Gentoo projects (and I'd be extremely shocked if Gentoo thought it had the right to demand otherwise).
2008/8/9 <bugzilla-daemon@gentoo.org>: > For this release only way is just to import kdesvn-portage ebuild's > in hardmasked state. > I don't need this. If someone want to use that, use it from kdesvn-portage, not much harder than using hardmasked packages. I'd like to wait for perfectly portage compatible ebuilds rewritten in the official gentoo way, takeing that muck time it takes.
(In reply to comment #77) > Why? Why aren't Paludis users or Exherbo developers allowed to be in the KDE > team? Members of both DevRel and the Council have stated quite explicitly that > Gentoo developers are allowed to work on non-Gentoo projects (and I'd be > extremely shocked if Gentoo thought it had the right to demand otherwise). You're missing the point here. Of course developers are allowed to work on any project they want, *but* a line has to be drawn if they refuse to create ebuilds which work on gentoo/portage - it's like M$ developer refusing to develop for Windows (and preferring Linux). Another thing I've learned during my professional life: a user has got *zero* tolerance for this kind of holy war (paludis vs. portage) - he doesn't give a shit about it at all, he's extremely annoyed to see that other distributions has got 4.1 ready and there's no real explanation why it's not available on gentoo (and BTW, http://kde.gentoo.org/ doesn't say anything at all about 4.1). I *strongly* urge all KDE developers to reconsider their position - even if paludis is better than emerge (actually, I don't think so - I've tried paludis before and found in wanting) most gentoo users are using portage - and trying to force to user to change his tools isn't the linux way.
(In reply to comment #79) > You're missing the point here. Of course developers are allowed to work on any > project they want, *but* a line has to be drawn if they refuse to create > ebuilds which work on gentoo/portage - it's like M$ developer refusing to > develop for Windows (and preferring Linux). > I *strongly* urge all KDE developers to reconsider their position - even if > paludis is better than emerge (actually, I don't think so - I've tried paludis > before and found in wanting) most gentoo users are using portage - and trying > to force to user to change his tools isn't the linux way. In fact, no-one is refusing to do anything (except the users and to be patient), nor is anyone trying to force anyone to do anything (except the users and for the KDE team to put ebuilds in the tree RIGHT NOW).
(In reply to comment #76) > Devrel bug - important and necessary action. But it will help for future > releases. For this release only way is just to import kdesvn-portage ebuild's > in hardmasked state. As a former developer I can tell you that devrel does not exist either. There is no mechanism or procedure to escalate issues in Gentoo community. This is the reason I left. What we see in this issue is another example of Gentoo lack of leadership. Gentoo does not really exist, if it had it would have goals. One goal can be notrequire people to use any other package manager than the official one, or provide tear one packages after X weeks upstream release (system, kernel, X, gnome, kde). Just for the record, I tried to use paludis for a while and although it has some interesting features especially in the way it can manage overlay settings, it lack some compatibility with portage (gcc-4.3 was the last issue I had before switching back to portage). It also does not support cross toolchains, as this part is unmaintained. It does not support digesting ebuilds, nor disest check (major security issue). It does not support binary packages (quickpkg) as its author knows more than anyone of how to manage complex network. I had to tweak it so I could simulate ebuild phases, as its author forces developer to use blackbox QA only. I also found that its hooks interface is inconsistence. It also does not support external USE flags specification, this is required for many packages that have stages. I had to tweak some more hooks in order to allow this. If an ebuild is changed in overlay it does not sync the changes, and always use the installed ebuild as a reference, causing a lot of issues with dependency change. Its query and user interface are much more complex than portage, it is very difficult for users (even my-self) to work with it. EAPI should also include the user interface. And above all, it looks like it has a single know-all do-all maintainer that maybe cooperate with exherbo developers but I could not see a cooperation with anyone else. There are more issues, I am back in portage now. Gentoo could have been great, if it had some leadership, some vision procedures and regulations.
(In reply to comment #80) > In fact, no-one is refusing to do anything (except the users and to be > patient), nor is anyone trying to force anyone to do anything (except the users > and for the KDE team to put ebuilds in the tree RIGHT NOW). Well, I guess the users would be much more patient if there would be a simple answer to a perfectly reasonable request: approximately when can we expect to have KDE 4.1? In a week, in a month, in a year? This question has been asked before, unfortunately there hasn't been any answer except some dark hints about some "political" struggles between the developers. There also have been hints about developers refusing to build ebuilds for portage. This is no way to run a railroad :-/
Can we please keep bugzilla for technical discussion about fixing bugs? There are better placing for rants and flamewars than here: forums, mailing lists, IRC.
(In reply to comment #77) > Why? Why aren't Paludis users or Exherbo developers allowed to be in the KDE > team? Members of both DevRel and the Council have stated quite explicitly that > Gentoo developers are allowed to work on non-Gentoo projects (and I'd be > extremely shocked if Gentoo thought it had the right to demand otherwise). > Nobody restricts their work on non-Gentoo projects. But if they do their non-Gentoo projects _instead_ of Gentoo projects - they must be called as something else then "gentoo developers". KDE-team's primary goal - Gentoo/portage ebuilds. If they want thay could _also_ support Exherbo/paludis, but not instead of portage. (In reply to comment #81) > (In reply to comment #76) > As a former developer I can tell you that devrel does not exist either. There > is no mechanism or procedure to escalate issues in Gentoo community. This is > the reason I left. So it's time to act - if there is no devrel (but, I think/hope, you quite pesimistic, and really problems much smaller) - we must create it. > What we see in this issue is another example of Gentoo lack of leadership. > Gentoo does not really exist, if it had it would have goals. One goal can be > notrequire people to use any other package manager than the official one, or > provide tear one packages after X weeks upstream release (system, kernel, X, > gnome, kde). > "[paludis is Prime Evil]" Actually - there is no place for portage vs. paludis holywar. If someone likes it - it could use it, but compartiblity or ebuilds' availibility - is their own problem (or problem of Exherbo). But developers, who was proposed to be portage ebuild-makers, _must not_ prefer paludis _in their development_, while they called gentoo-developers (and not exherbo/paludis ones). Portage support must be always a primary goal for them. > Gentoo could have been great, if it had some leadership, some vision procedures and regulations. Actually Gentoo has regulations. But Gentoo is quite like Russia - there is strict regulations, but noone follows them. This must be stopped. Why not start from "betrayers" in kde-team? (In reply to comment #83) > Can we please keep bugzilla for technical discussion about fixing bugs? There > are better placing for rants and flamewars than here: forums, mailing lists, > IRC. > If you not noticed - we trying to get this "technical discussion" from developers. But they prefers to be silent...
(In reply to comment #84) > Nobody restricts their work on non-Gentoo projects. But if they do their > non-Gentoo projects _instead_ of Gentoo projects - they must be called as > something else then "gentoo developers". And what makes you think they're doing that? > KDE-team's primary goal - Gentoo/portage ebuilds. No. Just as Gentoo has no right to demand to be their /only/ priority, it also has no right to demand to be their main priority. > Actually - there is no place for portage vs. paludis holywar. If someone likes > it - it could use it, but compartiblity or ebuilds' availibility - is their own > problem (or problem of Exherbo). Really, WTF does Exherbo have to do with any of this? > But developers, who was proposed to be portage ebuild-makers, _must not_ > prefer paludis _in their development_, while they called gentoo-developers > (and not exherbo/paludis ones). So you're telling the developers what to think now?
when you will understand that this threads are just bugzilla spamming and *totally* useless we'll have kde .41 in portage. sto here guys, this is not gonna change anything. just keep technical
We are using bugzilla in favour of the forum for this discussion because we expect the kde-team to take part in it. Again, the very least they are expected to do is to come up with some sort of timeline and information about progress that has been made e.g. "Yep, we're coding all night, give us another week or two." or "We're just waiting for KDE4.2, cause 4.1 still sucks". If they are not even capable to do that, they really should be replaced - just for the lack of communication skills of course. You got upset users out there guys, so wake up please!!!
(In reply to comment #84) > If you not noticed - we trying to get this "technical discussion" from > developers. But they prefers to be silent... > Maybe they prefer to code instead of wasting time and motivation having to reply to these type of comments. (In reply to N comments) Alright, it seems most people can't take a hint. I have personally refused to reply to this bug in hope to avoid escalating it and to lose my calm with so many bickering, flaming, trolling and ignorance. Let me just give a quick reply to a few issues: 1. 4.0/4.1/4.2 - Yes, the Gentoo KDE team said that 4.0 wouldn't be ready for "the masses" - that hasn't prevented us from having masked ebuilds in the tree. No, we're not saying 4.1 is bad, nor are we ignoring it and waiting for 4.2. 2. When? - When it's ready. Instead of conjuring so many theories, you can all check the progress in http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary - you can even clone that overlay if you want. It may be going on a slow pace, but I think it's steady. 3. You're late and so have no other option that to have genkdesvn-portage ebuilds masked in tree now - sorry, that's not how we work. Yes, we're late, but "life happens". This is not a "political" issue, it's a QA issue. It's up to the kde team to support the ebuilds, so it should be expected that we take the time to work on them. No, this is not NIH syndrome. In my case, I take all sources of ebuilds into account when adding a package - be it 4.0.X ebuilds, genkdesvn kdebuild-1s or genkdesvn-portage 4.1.0 ebuilds. 4. You're late because of a paludis/exherbo maquiavelic scheme - No, that's not true and that's a very unfair comment directed to some KDE members that have done a *superb* job for the last year or so. Instead of attacking those members, most users should be thanking them as the quality of the ebuilds in the tree is in no small part due to them. 5. Ok, but then really what is the problem? Why did this happen - The problem is that by a set of events, including the removal of the KDE team lead, the motivation of many members of the team slowly eroded to a point where we hit a standstill. To make things worse, the holidays / summer vacations have left most of us with very little time to devote to KDE. So it really is first and foremost a "lack of man power" issue - not enough people and or not enough time / motivation on the existing members.
(In reply to comment #88) > 5. Ok, but then really what is the problem? Why did this happen - The problem > is that by a set of events, including the removal of the KDE team lead, the > motivation of many members of the team slowly eroded to a point where we hit a > standstill. To make things worse, the holidays / summer vacations have left THANK YOU for finally getting some answers - if only information this detailed had come up like 2 weeks ago we would have avoided quite a lot of the ranting. (Still no estimated time though - oh well, I guess it'll be ready by the time 4.1.1 hits). (Wish these problems would have been announced earlier - like, say, a May-June announcement at gentoo.org "KDE Team needs help due to upcoming 4.1 release" - you would have probably gotten the manpower. Start doing some PR, people!)
(In reply to comment #88) > > 5. Ok, but then really what is the problem? Why did this happen - The problem > is that by a set of events, including the removal of the KDE team lead, the > motivation of many members of the team slowly eroded to a point where we hit a > standstill. To make things worse, the holidays / summer vacations have left > most of us with very little time to devote to KDE. So it really is first and > foremost a "lack of man power" issue - not enough people and or not enough time > / motivation on the existing members. > Thank you soooo much for this answer, as it is the first one directly addressing the _main_ problem from a (I dare to say _the_) person involved. I really hope that that one gets solved as well... And for the record and all the other users around here: Adding manpower to a late project makes it later.
(In reply to comment #85) At least. Thank you for explanations. They shows that your only suggestion - calm down and wait for unknown time. Looks like that devrel bug still needed - to solve problems your told, or maybe you have another way of solving it?
(In reply to comment #88) I also would like to thank you for finally shedding some light on the problem. Had you guys said this last week or something we could have avoided all this mess. I still thing you should post what is going on with KDE 4.1 on the gentoo.org front page as there are a lot of people who are curious as to what is going on and may not have read this bug post (as this isn't the place for this type of announcement).
I'm the former lead of the Gentoo KDE team. I've brought two top-notch Gentoo devs on board and we've assured that KDE in Gentoo was as good as it gets. Unfortunately, my vision of a technically sound, reliable and correct Gentoo which was reflected in our ebuilds, was put off by the DevRel lead (musikc) in an overnight coup which she pulled through supported by the Gentoo Council. They favour a "fun" Gentoo over one that has the packages people want, they favour a strict policy of "we love each other and disagreement leads directly to hell" and I didn't always fit into that picture. You can see this in bug 168573, btw. Those devs I brought in, Ingmar and zlin, as well as others have similar opinions and, thus, been inactive till they retired a few days ago which happened to be after my appeal against my forced retirement was rejected by the Gentoo Council. *This* is the reason why there are no 4.1 packages in the tree yet. Nothing technical, but purely political stuff. Feel free to complain to devrel@gentoo.org and council@gentoo.org. They caused this.
I expect this bug to be closed soon. But this freak show has been going on for 3.5 months? And people were expecting kde 4.1 in the tree without its lead even in the picture! WOW! How can you fire philantrop? Instead of working out the differences with key players, just fire them. Instead of disabling access to the tree, just forcefully remove the devs. Good going Gentoo council! Put your egos ahead of Gentoo and go ahead & kill it! This puts Alon's comments in perspective. There is no management here. No accountability!
An comment for what happened in Gentoo comunity. The "monitor" of Linux community are end users. I was sad when i herd today from my friend that after reading http://openkazan.info/apt-build_ubuntu_debian (who dont know Russian - there is described the way to rebuild ubuntu using local compiler) and truing to compile full Ubuntu in gentoo way he succeded, Firstly i was interested in fact that he showed me that it is possible to compile soft under ubuntu for your hardware. But after he told me the thing that rapidly made me sad - he told that he will switch to Ubuntu after... the only thing that isnt there is Use-Flags, but on the other hand Ubuntu is more up-todate in software, for what he went to gentoo long ago, the more thing is the fact that he brought me to linux... I am sad for the Gentoo status, but i am still in it and i want to participate in it future development... but i am still a learning programmer at the moment i study qt, but if i will be unable to learn the future technology. at the moment there is no way to do it in official gentoo, this is the way you FORCE the possible future devs to switch to other distributions. Linux distribution is like a nation... if one generation of devs will be lost, distribution will die.. if no action will be taked in the nearest future many people will change their text in field "Distribution" i have already talked with people switched to FreeBSD(by the way, they already have got KDE4.1) they are thinking gentoo is dead. I am talking not just about kde team, but about all infrastructure... why is openoffice easily bilt under 64 bits in FreeBSD and isnt in Gentoo... and there are more problems... why such an upstream distribution officially has no free java - iced tea, while Fedora is usining it as the default more than a year... Action has to be taken.. or Gentoo with it potenzial will become history. There are a lot of people in gentoo who want to help... Then why Can't we exclude ex-devs that haven't done anithing like last 2 month write an invitation for new devs where mention projects that need help... There are a lot of people(at least at gentoo.ru and linuxforum.ru who patch soft theirself, in linux.org.ru there was even news that someone made patch to compile openoffice in amd64)who will be glad to help, Just write a letter describing the status of thing. You can get help only after you ask for it. - Remember it. Ask for it, community at least at the moment exists... and i believe we will help, until it will be to late and community will d disappear.
Philantrop's wording implies that my actions have or would put off making Gentoo technically sound, reliable, and correct. I respectfully disagree as the departure, voluntarily or otherwise, of one or even ten developers is quite unlikely to make Gentoo technically unsound, unreliable, or incorrect. We are a community, not a project steered by any one individual. The actions of Developer Relations, be it the Lead or the team as a whole, are validated by Council who grants Dev Rel our rights, though our actions can be appealed to Council. Philantrop appealed his removal and Council reviewed the appeal and declined it. As the developer community voted for the Council which made this decision I believe Gentoo is moving in the desired direction. The departure of a developer may cause strain at times but I do believe in Gentoo and have faith that we will continue to grow as a project and to develop talent to facilitate that growth.
(In reply to comment #95) http://devrel.gentoo.org/staffing-needs Please look there, we have had a list there for years now listing all of the groups that are asking for help. Perhaps we should better advertise it, and I'd love to hear ways in which you think we could better accomplish this. Writing emails to groups asking for help doesn't seem to be the best way to accomplish though, since it would appear to be spam. Though perhaps on a quarterly basis we could send something to gentoo-dev-announce@. This is taking the bug quite off topic now though, so lets please bring this discussion elsewhere. Thanks, Mark
kde is not in that list, why?
(In reply to comment #96) > Philantrop's wording implies that my actions have or would put off making > Gentoo technically sound, reliable, and correct. I respectfully disagree as the > departure, voluntarily or otherwise, of one or even ten developers is quite > unlikely to make Gentoo technically unsound, unreliable, or incorrect. We are a > community, not a project steered by any one individual. > > The actions of Developer Relations, be it the Lead or the team as a whole, are > validated by Council who grants Dev Rel our rights, though our actions can be > appealed to Council. Philantrop appealed his removal and Council reviewed the > appeal and declined it. As the developer community voted for the Council which > made this decision I believe Gentoo is moving in the desired direction. > > The departure of a developer may cause strain at times but I do believe in > Gentoo and have faith that we will continue to grow as a project and to develop > talent to facilitate that growth. > What a great speech. Actually, your place in devrel well-taken. But there is one small problem in your speech - it's too official and has no argumentation (except one - "We was choosen, so we are right"). This is political speech, not "normal-human-readable". I never trust such kind of talks. It seems that all sides lie. 1) Bug which was referenced as reason is closed for view even for developers (bug #168573 comment #16) - so you actually hiding something from community (and from developers). 2) Referenced txt-file irc-log shows that Philantrop starts some king of irc-war, which also isn't corrent - but he says nothing about that. 3) Referenced irc-log of meeting when this decision was taken shows that only (public) reason for this kind of action was _fear_ of _possible_ intentional tree corruption. 4) I have no doubt that you have mechanisms of rolling back any bad changes and forbiding/premoderating commits from suspicious developers. Your reaction on _known for us_ Philantrop actions isnt' adequate, in such view. Taking in account your style of talking to community I probably belive more to him. If your fear of corruption was really seriously argumented by some facts - please public this facts (open a hidden bug, at least). Council desision also makes no sense is they was using some closed to community information (imho). Top level of judgement is community - if users will disagree with such council direction they will just switch out.
(In reply to comment #95) > An comment for what happened in Gentoo comunity. > ..... also more comment... you are wrong wile criticizing exherbo and paludis devs and users... instead it will be the right way to ask why they did so - answer it is fact that their innovations wheren't realized in portage and gentoo, and they at the beginning were trying to improve those... but their new thinking was stoped by those who developed gentoo long ago... but at the moment who aren't writing code... for example paludis is an replacement for portage... rewriting it at C, which is making it a lot more fast... devs are trying to make it fully compateble with portage and after they tried to add new features... but to bring them they need a GLEP, they composed it... but the GLEP system is DEAD - the list "Accepted but not implemented gleps (Accepted)" proves it GLEP 20 http://www.gentoo.org/proj/en/glep/glep-0020.html Last-Modified: 2004/11/11 21:35:53 Accepted but not implemented... it gives my brain what to think about Those devs aren't betrayers... they are just those who met the wall in their way... there had 2 things to do - to retire or to start their own project - they did the right thing... The problem is in managing... no one is trying to help devs implement new, even if it is not braking old things.... For example - you think that kde team switched to paludis just because they had nothing to do? the reason was in fact that for building kde4 the best way changes had to be done to portage... but to make them there is to hard... there were 3 ways 1. do dirty bad working ebuild. 2. stop development 3. switch to another software manager. they did the right thing... on my opinion those who want to try such an again partly in develop thing like kde 4.1 should also try paludis... by the way... for example i will show you my critics of portage... most of you know such things as layman, eix used by most gentoo users and devs they were tested thought years, BUT still there aren't a part of portage... they are even other packages... paludis DOES include normal search thing and he manages overlays by its own... at the moment there are a bit of things that aren't implemented in paludis, that is in portage, BUT how old is paludis... for its age it is developing rapidly... and it has got a lot of features emerge has not... for me existing of such a thing as paludis proves that portage is in past... either Gentoo-oldstyle devs will begin to hear the new ones... and paludis will have road to make gleps... (at the moment portage uses monopoly, on my opinion they aren't accepting gleps like 49 or 50 just because he just wont meet Compatibility with other... monopoly...) so portage in state as it is now will be in past, or it will die... like the heart of man, that had great respect in past, while dying (In reply to comment #97) > (In reply to comment #95) > > http://devrel.gentoo.org/staffing-needs > > Please look there, we have had a list there for years now listing all of the > groups that are asking for help. Perhaps we should better advertise it, and > I'd love to hear ways in which you think we could better accomplish this. > Writing emails to groups asking for help doesn't seem to be the best way to > accomplish though, since it would appear to be spam. Though perhaps on a > quarterly basis we could send something to gentoo-dev-announce@. This is > taking the bug quite off topic now though, so lets please bring this discussion > elsewhere. > > Thanks, > > Mark > i have never seen this page before... i am sure most of those who can provide held didn't either(as i see kde devs also have no knowledge about it)
(In reply to comment #97) > (In reply to comment #95) > > http://devrel.gentoo.org/staffing-needs > > Please look there, we have had a list there for years now listing all of the > groups that are asking for help. Perhaps we should better advertise it, and > I'd love to hear ways in which you think we could better accomplish this. > Writing emails to groups asking for help doesn't seem to be the best way to > accomplish though, since it would appear to be spam. Though perhaps on a > quarterly basis we could send something to gentoo-dev-announce@. This is > taking the bug quite off topic now though, so lets please bring this discussion > elsewhere. > > Thanks, > > Mark > Well, yes, offtopic it may seem to you, but it's quite on it I think. To make it short: Political issues kde devs left. Not enough devs for kde4.1 in portage. => a political issue why there's no kde4.1 in portage. But I don't want to stick on that one any longer as some already have explained the issue quite well. You wrote that you'd love to hear ways how to advertise that page better (for the record, it's the first time I hear from it). Well, take a look archlinux.org (scroll down ;) ), that's a way to recruit new devs for example. Or use the forums to search. Or find them on the forums or here at the bugzilla... Make the whole recruitment process more open and you'll get a lot more users willing to help.
(In reply to comment #100) > paludis is an replacement for portage... rewriting it at C, which is making it > a lot more fast... devs are trying to make it fully compateble with portage and > after they tried to add new features... Well, here you're wrong. I used paludis before (when trying out kde 4.1 from svn) and I found it - compared to portage - horribly slow, especially inquisitio - emerge -s was *much, much* faster. The programming language is only one (small!) factor in the speed of programs. Besides the slow speed (and a couple of bugs) of paludis, I didn't like it for two reasons: 1.) The latin names. They sound cute (paludis, inquisitio, reconcilio) but are horrible difficult to remember (even though I did take latin classes at school) if you're not a linguist. Oh well, latin is more über-geek than plain english, i guess 2.) The command line switches are *very* difficult to remember. So, IMHO: paludis ist extremely unpleasant to use from a user's perspective. > were 3 ways > 1. do dirty bad working ebuild. > 2. stop development > 3. switch to another software manager. > they did the right thing... Nope. Well, of course, they've got a right to leave - but *any* project (even large one) has got it's quirks - they have to live with it. Every project I've been involved hat some design flaws and there always was a better, cleaner way to do it - but on the other hand, a complete redesign won't do any good, so you have to live with it. Take a look at Wikipedia: the software plus license isn't very good. There are much better ways to do it, but: wikipedia is a huge success, and rebuilding it from scratch would be insanity. > at the moment there are a bit of things that aren't implemented in paludis, > that is in portage, BUT how old is paludis... for its age it is developing > rapidly... and it has got a lot of features emerge has not... So you're telling that we should switch to pre-alpha software just because paludis is cool? No thanks. Another word about exherbo: yesterday I've taken a look at exherbo and was less than impressed: apparently most postings on exerbo.org are snide remarks against gentoo (this reminds me of an obscure german fork of Wikipedia - Wikiweise). Well, if the developers of exherbo would spend there time developing exherbo instead of taunting gentoo, maybe exherbo would be an alternative (but than again: stupid latin names which no one can remember), but right now I'm quite apalled. They apparently need to adjust there attidude.
(In reply to comment #102) > Another word about exherbo: yesterday I've taken a look at exherbo and was less > than impressed: apparently most postings on exerbo.org are snide remarks > against gentoo (this reminds me of an obscure german fork of Wikipedia - > Wikiweise). Well, if the developers of exherbo would spend there time > developing exherbo instead of taunting gentoo, maybe exherbo would be an > alternative (but than again: stupid latin names which no one can remember), but > right now I'm quite apalled. They apparently need to adjust there attidude. Please stop spreading FUD about other distributions on Gentoo's bugzilla.
(In reply to comment #102) > > Well, here you're wrong. I used paludis before (when trying out kde 4.1 from > svn) and I found it - compared to portage - horribly slow, especially > inquisitio - emerge -s was *much, much* faster. > you told the reason why it wasn't faster.... how can you cache svn? - no way. Running "paludis -ip world" is a lot faster than "emerge -uva world" or "emerge -uvaDN world" (In reply to comment #102) > 1.) The latin names. They sound cute (paludis, inquisitio, reconcilio) but are > horrible difficult to remember (even though I did take latin classes at school) > if you're not a linguist. Oh well, latin is more über-geek than plain english, > i guess > 2.) The command line switches are *very* difficult to remember. > > So, IMHO: paludis ist extremely unpleasant to use from a user's perspective. its true... > > > were 3 ways > > 1. do dirty bad working ebuild. > > 2. stop development > > 3. switch to another software manager. > > they did the right thing... > > Nope. Well, of course, they've got a right to leave - but *any* project (even > large one) has got it's quirks - they have to live with it. Every project I've > been involved hat some design flaws and there always was a better, cleaner way > to do it - but on the other hand, a complete redesign won't do any good, so you > have to live with it. If you are right then why are we using linux kenrel witch was a complete redesign? Kde(official) in new version uses another build system - and making best ebuilds instead of making a dirty hack to make it work as before is normal, at least here.Kde is too meaningful project to make it hacky-way. Nobody is talking about redesing - paludis uses the same official ebuild tree and is compatible(at most - the only problems are dirty ebuilds that used portage hacks... instead of entering new functions to it. (In reply to comment #102) > So you're telling that we should switch to pre-alpha software just because > paludis is cool? No thanks. Firstly it isnt alpha at least look at http://forums.gentoo.org/viewtopic-t-537510-postdays-0-postorder-asc-start-300.html it is used. Some people use it more than a year http://www.davidgrant.ca/switched_from_portage_to_paludis so it is at least beta about exherbo - i haven't told that you have to switch to it, or even look at it - i told about thinking about *WHY* developers maked their own way instead of developing what they wanted in gentoo? There whould be reasons,and they are listed on page... but in aggressive way, but still focus in the soul and you will understand. I would propose to switch to exherebo - i would use it. I use Gentoo, cause i like its idea. its Gentoo bugsilla i am speaking about not today exherebo devs, but about previos. lets clean it and close exherebo theme... it wasn my main idea it was an argument
(In reply to comment #102) > alternative (but than again: stupid latin names which no one can remember), but > right now I'm quite apalled. They apparently need to adjust there attidude. > right on about the latin crap and attitude adjustment. Being rude is cool with the folks from exherboo!(In reply to comment #103) > (In reply to comment #102) > > Another word about exherbo: yesterday I've taken a look at exherbo and was less > > than impressed: apparently most postings on exerbo.org are snide remarks > > against gentoo (this reminds me of an obscure german fork of Wikipedia - > > Wikiweise). Well, if the developers of exherbo would spend there time > > developing exherbo instead of taunting gentoo, maybe exherbo would be an > > alternative (but than again: stupid latin names which no one can remember), but > > right now I'm quite apalled. They apparently need to adjust there attidude. > > Please stop spreading FUD about other distributions on Gentoo's bugzilla. > I think exherbo stands for FUD in latin....;-) looking at the website, if all the distros disappeared from the land, even then I won't try it. And yes, I agree with Mark about guys over there needing attitude adjustment.
(In reply to comment #105) > (In reply to comment #103) > I think exherbo stands for FUD in latin....;-) Did you not read the comment you're replying to? This is not the appropriate place to attack other distributions (neither is anywhere else, really, but especially not here). > And yes, I agree with Mark about guys over there needing attitude adjustment. Exactly what "attitude" do you think is wrong? The attitude of not liking to be attacked and blamed for all Gentoo's problems on Gentoo's bugzilla?
(In reply to comment #104) > > you told the reason why it wasn't faster.... how can you cache svn? - no way. > Running "paludis -ip world" is a lot faster than "emerge -uva world" or "emerge > -uvaDN world" Thats strange because =) portage can use live ebuilds and search in overlays with live ebuilds and portage make it fast =) So what the diffrence between live svn ebuilds and other kind of ebuilds for searching? > Kde(official) in new version uses another build system - and making best > ebuilds instead of making a dirty hack to make it work as before is normal, at > least here.Kde is too meaningful project to make it hacky-way. > Nobody is talking about redesing - paludis uses the same official ebuild tree > and is compatible(at most - the only problems are dirty ebuilds that used > portage hacks... instead of entering new functions to it. > portage already has new functionality for kde ebuilds in kdesvn-portage while paludis use its own bicicle named kdebuild-1 and kdebuild-scm 2 darkdimius if you dont know something dont speak about it as you do it on LOR openoffice sucsessfuly works in gentoo on amd64 at least since 2.0 so you are wrong
(In reply to comment #107) > Thats strange because =) portage can use live ebuilds and search in overlays > with live ebuilds and portage make it fast =) So what the diffrence between > live svn ebuilds and other kind of ebuilds for searching? at least on my machine last version of paludis works faster then last(stable) portage > portage already has new functionality for kde ebuilds in kdesvn-portage then why those ebuilds aren't in portage? > openoffice sucsessfuly works in gentoo on amd64 at least since 2.0 so you are > wrong i will check, it would be great to stop using it in binary(in true i havent chacked it for long, while steal in past the first version i tried to compile (in 2.*) also failed...so i hovent tried using it from portage).
Please, take discussions about package managers to the forums. This is a development discussion channel, not a random chat one.
(In reply to comment #100) > were 3 ways > 1. do dirty bad working ebuild. > 2. stop development > 3. switch to another software manager. > they did the right thing... The "right thing" from a user's pov would be 1 (until nagging portage devs about new features brings the desired result). One of the more important reasons for using Gentoo is indeed that it is/was bleeding edge. Bleeding edge means versionless distro thus extra work for changing/reviewing config files all the time, broken stuff (remember expat?) etc. It would be far less of a hassle to use a version-based distro like Ubuntu or Suse. So where's the benefit from using a versionless distro when it's no longer bleeding edge? I can understand that portage developers don't implement every new feature-request nex day and that changes to portage might take some time. Having bugs in portage is probably the worst thing that could happen. User's might not be amused having to reinstall Gentoo due to some bug in portage. Sometimes there is no other way but to use dirty hacks - that's life. So please move those packages from the overlay to the main tree. Mask them, if you think they are low-quality.
(In reply to comment #107) > portage already has new functionality for kde ebuilds in kdesvn-portage That overlay didn't use any "new functionality" last time I checked, certainly not any that was available in Portage when the KDE team decided to switch to kdebuild. > while paludis use its own bicicle named kdebuild-1 kdebuild-1 is not "Paludis's own". The maintainers of the other package managers were invited to support it, and if they chose not to, that's their problem. > and kdebuild-scm There's no such thing as kdebuild-scm. > if you dont know something dont speak about it *cough*
(In reply to comment #111) > > That overlay didn't use any "new functionality" last time I checked, certainly > not any that was available in Portage when the KDE team decided to switch to > kdebuild. kdesvn-portage was based on genkdesvn overlay *after* they switched to paludis > > kdebuild-1 is not "Paludis's own". The maintainers of the other package > managers were invited to support it, and if they chose not to, that's their > problem. and what other than paludis package managers supports this ebuild like fromat? its supported only by paludis. and most of regular users dont want to switch to another package manager just to install new kde versions
(In reply to comment #112) > (In reply to comment #111) > > > > That overlay didn't use any "new functionality" last time I checked, certainly > > not any that was available in Portage when the KDE team decided to switch to > > kdebuild. > > kdesvn-portage was based on genkdesvn overlay *after* they switched to paludis WTF are you talking about? That doesn't in any way contradict what I said. > > kdebuild-1 is not "Paludis's own". The maintainers of the other package > > managers were invited to support it, and if they chose not to, that's their > > problem. > > and what other than paludis package managers supports this ebuild like fromat? > its supported only by paludis. Clearly you didn't read what you replied to. As I said, the format is not Paludis-specific. If the maintainers of other package managers don't want to support it, that's entirely their decision.
*sigh* This is a warning to all parties here.. no one exempt from it, and no you are not special in any way. I would suggest that everyone consider where this has gone from being a question about where 4.1.0 is which was answered 100 replies ago to such topics as paludis etc. Avoid the off topic, and trolling comments. Gentoo tries to be a standard that allows everyone to make use of what they want to be it one of the three current package managers to any of the various forms of tar implementations. The KDE team is working on KDE and it will be in the tree when they feel it is ready to be in the tree. That is the answer you get and the answer you must accept. If you think you can do better then follow up to the suggestion about becoming a developer and learning what it is like from the other side of the fence. Its not greener on this side as much as you might think so. Stuff like this actually delays the release of a product to the main tree because the volunteer's who donate their time and blood see everyone complaining when they are working hard on something for themselves, but for everyone else as well. Its never as simple as a bump of version 3.x to 4.x like it is for many smaller packages.
(In reply to comment #114) > Stuff like this actually delays the release of a product to the main tree > because the volunteer's who donate their time and blood see everyone > complaining when they are working hard on something for themselves, but for > everyone else as well. Its never as simple as a bump of version 3.x to 4.x like > it is for many smaller packages. There is two unanswered questions on current bug topic: 1) Why not just import overlay ebuilds? We have answer 'sorry, that's not how we work. Yes, we're late, but "life happens"' ( Comment #88 From Jorge Manuel B. S. Vicetto ). Actually - that's not how we work, imho, very bad explanation. kdesvn-portage developers intends that QA of their ebuilds at least on the same level as for kde-3.5.9. Even if complete a full check of kdesvn-portage overlay (but there is rumor that Jorge Manuel B. S. Vicetto was helping kdesvn-portage team himself, so why he can't trust this people?) must be done - checking one ebuild is much faster that reading/understanding three ebuilds (as someone says in this topic) and writing your own based on them. ANDyYou already have users tests - this ebuilds are working, they not break anything, they makes exactly what users want. All other QA checks needed for compartiblity or just good style of coding could be done, imho, later. Or there is something wrong with my logic? Please, explain your decision in detail. 2) _Why_ all this happens? What exactly covers under this "live happens"? Rumor says that there is no kde-team lead, but why? Why he was so strangely forcily retired without and info due to [closed bug]? Why all this are hidden from community? (Yes, this is one questions, but very complex =)) P.S. Actually kde-4.1 bug problem is not a problem of lacking kde-4.1 in tree, There is a problem of lacking information. You see - this "mess" of posts shows to community very intresting, but strange things. For now it looks like that problems are much more deeper that we thought before... For me, question 2 is much more interesting that 1 (while i'm not using kde at all, but quite suprised by this situation =)).
(In reply to comment #115) > 2) _Why_ all this happens? What exactly covers under this "live happens"? Rumor > says that there is no kde-team lead, but why? Why he was so strangely forcily > retired without and info due to [closed bug]? Why all this are hidden from > community? (Yes, this is one questions, but very complex =)) > > P.S. Actually kde-4.1 bug problem is not a problem of lacking kde-4.1 in tree, > There is a problem of lacking information. You see - this "mess" of posts shows > to community very intresting, but strange things. For now it looks like that > problems are much more deeper that we thought before... For me, question 2 is > much more interesting that 1 (while i'm not using kde at all, but quite > suprised by this situation =)). > Night Nord: I couldn't discovered it, either reading the "evidences thrown against Philantrop in bug #168573, nor in replies given by devrel and council when I wrote a mail to complain about that. It seems that now gentoo is all political and users are nothing for them. Who would like to become Gentoo developer (or contribute) nowadays if just by disagreeing in something makes a FORCED RETIREMENT of yourself? This is the ROOT problem why KDE 4.1 isn't in tree today.
> It seems that now gentoo is all political and users are nothing for them. This is contrary to what was said in reply to your email. Gentoo users are important to all of us, let us not forget that each Gentoo developer is also a Gentoo user. Also remember that each Gentoo developer is a person who is giving his time to work on Gentoo at the sacrifice of time that could be spent at work, with his family, or even just with friends. We're human too and though many of us willingly give so much to Gentoo, we cannot give everything to Gentoo and may take a bit of time now and then to complete something. > Who would like to become Gentoo > developer (or contribute) nowadays if just by disagreeing in something makes a > FORCED RETIREMENT of yourself? No developer has ever been forcibly retired merely due to disagreeing with someone else. Developers have been forcibly retired due to inactivity and policy violation, never because someone simply dislikes them or disagrees with them. Gentoo recruits new developers regularly so clearly not every one out there is so afraid. Check out http://www.gentoo.org/news/en/gmn/ to learn more about our developer status on who is coming, going, and moving around within Gentoo. > This is the ROOT problem why KDE 4.1 isn't in tree today. Instead of speculating why something isnt available or to your liking, why not leave it to the KDE team to speak as to why something isnt there yet? Also give them credit for actively recruiting someone who has done extensive KDE work and greatly desires to help. Simply put, this bug is about implementing 4.1 and they are working to get it to you.
(In reply to comment #117) > > It seems that now gentoo is all political and users are nothing for them. > This is contrary to what was said in reply to your email. Gentoo users are > important to all of us, let us not forget that each Gentoo developer is also a > Gentoo user. > Also remember that each Gentoo developer is a person who is giving his time to > work on Gentoo at the sacrifice of time that could be spent at work, with his > family, or even just with friends. We're human too and though many of us > willingly give so much to Gentoo, we cannot give everything to Gentoo and may > take a bit of time now and then to complete something. This is not true. I retiered from Gentoo because of this exact reason. Most developers especially the laud and rude ones perceive Gentoo as a project for the developers community, users are not relevant. I could not make any progress as any depended issues were not resolved in sane time, and the fact that a developer reports an issue did not make any difference. Had users were important, you would have had escalation process for bugs opened more than X weeks. You would have a technical authority (not political council) that developers could appeal to resolve technical issues. You would be confirm to standard, such as HFS, and most importantly you would be polite to users and fellow developers. As end result you end up with specific class of people as developers, most rude and laud. The silent developers who care and do the work, just leave Gentoo (Review the last two years history). Gentoo community cannot mature this way. Come on... were you a user, how would you have feel if you got no response for a simple question?
(In reply to comment #117) You _not_ answered about main question directed to your department - why was retired exact developer nick-named Philantrop, aka lead of kde-team? All your politically-correct words are empty and useless.
> You _not_ answered about main question directed to your department - why was > retired exact developer nick-named Philantrop, aka lead of kde-team? Not the right bug for this line of discussion but I'll answer briefly: Refer to bug #168573. Summary: his repeated inappropriate retaliation bans, his persistent derogatory comments about others, and his threats of legal action against individual Gentoo developers if they did not conform to his requests. > All your politically-correct words are empty and useless. I never stated that everyone would be 100% satisfied with everything I said nor with my choice of words, silly me for trying to be professional and not personal, and if you dont like my choice in words then perhaps you should reconsider asking me to respond.
(In reply to comment #120) > > You _not_ answered about main question directed to your department - why was > > retired exact developer nick-named Philantrop, aka lead of kde-team? > Not the right bug for this line of discussion but I'll answer briefly: Refer to > bug #168573. > Summary: his repeated inappropriate retaliation bans(1), his persistent derogatory comments about others(2), and his threats of legal action against individual Gentoo developers if they did not conform to his requests(3). (1): One in his channel could do whatever he/she wants, even banning people you dislike (is it now this a delictive action?) (2): As comment 118 said: there are PLENTY of gentoo-devs that sound really rude (I will not mention here any name) and not for this reason all of them got forced retirements. (3): Threat or advise? What kind of requests? This is still very subjetive And finally again as I said: I really can't see any real reason for that kind of action in bug #168573 (and since I am not the only one person thinking that, don't you think it is for some reason? (and some other kde herd members voluntarily retired because of that action taken agains Philantrop)). So, if you want evidences here you have: - Users wanting to know more and don't understanding it even after reading bug #168573. - Users switching to other distros for other similar causes not solved (not related to philantrop) caused by developers who didn't got retired. - Several Gentoo developers supporting Philantrop by voluntary retire. - Number of comments of this bug thread. If you (plural) really think about your users, just think it has consequences for Gentoo's Face. Finally, three things more: 1.- Yes, I think your language is correct, but exempt of solid evidences. 2.- In response to: > This is the ROOT problem why KDE 4.1 isn't in tree today. Instead of speculating why something isnt available or to your liking, why not leave it to the KDE team to speak as to why something isnt there yet? Also give them credit for actively recruiting someone who has done extensive KDE work and greatly desires to help. Just read comment #93, I'm not speculating anything. 3.- Comment #22 of bug #168573: We already NEED EAPI2, at least USE DEPENDENCIES. See date of bug #2272 which is really needed and it is still in pre1 stage... So what's the problem here?
(In reply to comment #121) > - Several Gentoo developers supporting Philantrop by voluntary retire. It's not even about supporting Wulf. It's about how I might as well be next, given how he got no warnings, no solid explanations and it happened over night. Why put any further effort into a distribution that will treat its contributors of very good work for well over a year like that?
This is really getting most embarrassing for Gentoo. Despite the fact that this bug has by far most votes and more than 2 weeks have passed: nothing happend! I wonder how long it takes until some news portal like slashdot picks this up - would make a nice story for sure. If I was a developer, I would spend all my time on getting kde4.1 into the tree as quickly as possible. Perhaps the results are some considered "dirty" ebuilds that work for 99% of the users only. Anyway, we have it, too (like all the other distros). Users can try it, contribute to closing bugs instead of spending their time writing flame-posts and of course it buys some time for resolving political and coding-style issues.
I'm through commenting on this bug regarding philantrop's retirement. I appreciate that stormbyte and others may not understand or want to accept the reasoning despite attempts to explain just as I appreciate that others feel the exact opposite. Philantrop has made no visible changes (his comments on this bug are no exception) and the majority of dev rel and council agree with the decision so there is nothing to reconsider at this time. Best of luck to the KDE team and I'm sure the users and developers alike are looking forward to 4.1 whenever you guys can get it out to them. :)
(In reply to comment #123) > This is really getting most embarrassing for Gentoo. Despite the fact that this > bug has by far most votes and more than 2 weeks have passed: nothing happend! Nothing has happened? How many times have we replied trying to explain what happened and what we are going to do? More importantly, http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary <- this happened. I can assure all of you that are so eager to have kde-4.1 around, that if it were not for the many hours I had to spend around this bug in the last days, I would personally have bumped more packages than what I've been able to do. PS - Please stop arguing that we (KDE team) have refused to provide any information. You might not like what we've said, but we have certainly addressed this bug.
Hi, I have been reading the post, I have to say I understand all sides one way or another. but what I always say for the last two years is why if developers are so worked out will not allow for us with the qualifications to help? I try once. and I got told to submit and monitor bugs. I am a IT professional that works more than 80 hours a week, as a hobby I create a lot of ebuilds for my company(yes we use Gentoo in most of our 100 servers) so this time that I spend doing my hobby I can dedicate to building gentoo ebuilds for gentoo. but I just do not have time and I bet many more to spend 4-5 months on bugzilla just to get a status. so my though is that maybe there is not such a real need for developers. so I ask again why we cannot help? Is or I help or I do, not that's why I have a resume to show if needed to be to probe my tech skills, so awesome for the developers and the community but negative for the bureaucracy to "help" mostly when we are not to the level of Debian or Ubuntu to be able to turn people down.
This is the last warning to bring this topic directly back to the question about 4.1 and 4.1 only, or actions based on the COC will be applied to those who deviate from that discussion. > (1): One in his channel could do whatever he/she wants, even banning people you > dislike (is it now this a delictive action?) The channel in question #Gentoo-kde is a Gentoo channel. It falls under the rules and regulations of policies that guide the IRC channels for Gentoo. He violated them by banning people without probably cause. He showed no remorse as well. I talked to him about it and tried to act as a mediator, but that failed and further action was required. > (2): As comment 118 said: there are PLENTY of gentoo-devs that sound really > rude (I will not mention here any name) and not for this reason all of them got > forced retirements. Alonbl was a developer, who left of his own accord due to a difference in opinion with the larger group of people. I again tried to work with him and it was a failing of my part to come to an understanding that was acceptable for alonbl to stay on as a dev. It was his choice, but that particular incident was related to the fact that we as an organization don't follow the FHS standards to the letter, we've not for years (decided to follow upstream more then that particular standard). While we stay with it fairly well, we don't always follow it. The upstream in the case (which was a Gentoo hosted project) made a change to relieve one problem but it didn't fully apply to the standard and wasn't adequate. While I respect him as a developer within and outside of Gentoo, there was no way to reach a mutually beneficial decision in the case. > (3): Threat or advise? What kind of requests? This is still very subjetive > And finally again as I said: I really can't see any real reason for that kind > of action in bug #168573 (and since I am not the only one person thinking that, > don't you think it is for some reason? (and some other kde herd members > voluntarily retired because of that action taken agains Philantrop)). The other members made a choice, we are always sad to see a developer retire, and wish them continued good luck in future endeavors. As a member of devrel, I stand behind the decision that was made in the case. Council also agreed with that decision during the appeal. The matter is closed and continuing to talk about it is serving no purpose. > - Users switching to other distros for other similar causes not solved (not > related to philantrop) caused by developers who didn't got retired. Users are free to go where they wish to. We are an entirely voluntary organization. There is no real profits for any member of the teams here. What they receive is the knowledge, and joy of giving back to something that they get use/joy out of using. > - Several Gentoo developers supporting Philantrop by voluntary retire. That's speculation at best. They left of their own accord and I'm sure there was more then that one possible reason why they chose to retire. We choose to respect their decision in the case, which by the way I've noticed a distinct lact of respect towards others on this bug. > - Number of comments of this bug thread This bug quickly drifted from 4.1 into other topics, if people could manage to stay on topic without drifting, it'd be a far shorter bug. > > Just read comment #93, I'm not speculating anything. #93 is a personal opinion of one person. I could say that its because of a recent full moon and that 3/4 of the kde turned into werewolves. Point being that it shouldn't be taken as the absolutely single point of truth for all the matters. Also, as has been mentioned numerous times now there is an entire team of people working on KDE. It doesn't rely on any one single person as its the work of many individuals that make the release of KDE a success. Both upstream and downstream. Please keep this in mind and realize while the removal/leaving of one or more people will hurt a team, the team is still there and will still release and produce a wonderful product. > 3.- Comment #22 of bug #168573: > We already NEED EAPI2, at least USE DEPENDENCIES. See date of bug #2272 which > is really needed and it is still in pre1 stage... So what's the problem here? We've been without EAPI2 for 9 years. I don't think being without it for another few months will really hurt things. Please have some perspective on the matter.
(In reply to comment #127) > Alonbl was a developer, who left of his own accord due to a difference in > opinion with the larger group of people. I again tried to work with him and it > was a failing of my part to come to an understanding that was acceptable for > alonbl to stay on as a dev. It was his choice, but that particular incident was > related to the fact that we as an organization don't follow the FHS standards > to the letter, we've not for years (decided to follow upstream more then that > particular standard). While we stay with it fairly well, we don't always follow > it. The upstream in the case (which was a Gentoo hosted project) made a change > to relieve one problem but it didn't fully apply to the standard and wasn't > adequate. Please, there are few more reasons why I retired, examples: bug#220111 - Own gentoo users does not use Gentoo correctly (DISTDIR), then they fixed it but are the *FIRST* package that don't use /var/cache correctly. As genkernel is upstream and downstream no sane developer can fix the issue. Just read releng comments! bug#182065, bug#177626 - Gentoo developers ignoring users' splash issues. Developer that care fixes this and then see what happening. Just read releng comments! bug#156431, bug#156445 - Users are not able to use software suspend (hibernation) with house project (genkernel), as genkernel is upstream and downstream, no sane developer may add a patch to the ebuild to make the life of the user easier. bug#195666 - Installcd lsusb feature was removed, read releng rude comments!!! After all devrel justifications for their action, I am glad that the last installcd have lsusb again... Don't acknowledge you were wrong... devrel - Devrel process is extremely stupid, as it just echo each party claims. This does not resolve anything where the problem is technical... Provide linux hibernation to users or not, use /var/cache for persistent data first violation of this in Gentoo or not. Alarm if a bug is ignored more than X months etc... All actions that needed to be done and nobody doing them. releng - I found out that without cooperation with these guys, I cannot provide the users the service they need. As devrel found nothing wrong with above examples, I had no reason to be a developer responsible (as a community) for the low service we provide. If a fellow gentoo developer cannot discuss technical issues with releng or basesystem (Which are actually the Gentoo distribution) there is no reason to be part of the community.
After couple of hours of reading this bug report, I have to say one thing. Many users are waiting for KDE 4.1 and the are really angry if it is not there even after two weeks after 0-day. If the KDE team is not able to say when they provide ebuilds for KDE 4.1, it would helps a lot if they create a status matrix of all packages and mark each of them as DONE, TESTING and TODO. There could user see what's the status of the KDE 4.1 ebuild and when it will be approximately in the Portage Tree. Similar thing is done for instance in Nouveau project (http://nouveau.freedesktop.org/wiki/FeatureMatrix).
(In reply to comment #123) > If I was a developer, I would spend all my time on getting kde4.1 into the tree > as quickly as possible. So why aren't you? This is a community distribution and therefore relies on the workforce of the community. Its too easy to lean back, dividing in the community into users and developers and yelling to the latter "Do it for me, do it for me. Do it yesterday." Interestingly, the whining also goes just the other way, saying developers divide the community because of holding infromation back. Sooner or later someone comes with the invalid claim it'd be too hard to become a Gentoo developer. It's not. You know what I did, after reading some comments in the corresponding Gentoo forums thread!? I took a break from Gentoo as a whole for a number of days, because the behaviour of a subset of this community saddens me. I won't pretend I read all the comments here, but I tell you something: This has to stop. This is a bug tracker, not a chat. It's not possible to work with this bug, so bug 234773 tracks KDE 4.1 now.
closed
(In reply to comment #130) > (In reply to comment #123) > > If I was a developer, I would spend all my time on getting kde4.1 into the tree > > as quickly as possible. > > So why aren't you? This is a community distribution and therefore relies on the > workforce of the community. Its too easy to lean back, dividing in the > community into users and developers and yelling to the latter "Do it for me, do > it for me. Do it yesterday." Interestingly, the whining also goes just the > other way, saying developers divide the community because of holding > infromation back. Sooner or later someone comes with the invalid claim it'd be > too hard to become a Gentoo developer. It's not. > > You know what I did, after reading some comments in the corresponding Gentoo > forums thread!? I took a break from Gentoo as a whole for a number of days, > because the behaviour of a subset of this community saddens me. > > > I won't pretend I read all the comments here, but I tell you something: This > has to stop. This is a bug tracker, not a chat. > > > It's not possible to work with this bug, so bug 234773 tracks KDE 4.1 now. > hmm I have try to help many times, and most of my friends here in Boston or Spain, and we NEVER got a email back in reply to any team from the looking for help page, one time like 4 years a go someone told us in IRC to fix bugs and one day we could help... none of us all working full time have the time to spend 6-12 months kissing eass first so we can help a "community" project like gentoo.. if is really open for the community to help.. probe it. put a request form that people actually gets reply back and a transparent selection were everyone can see, everything should be transparent and democratically done.. we are a community but looks to me more like something else, is a shame that there are good developers and engineers that I know that can't help just because we are not 15 year old with all the time in the world to kiss ass someone before actually spending some hours a week really helping..
I know that it is the wrong place, but...Thank you very much! Great work!
