I'd like to get kde-config.xml and kde-split-ebuilds.xml moved from doc/en to the KDE project space so that we can take care of those two guides ourselves.
Providing us with a link to their new location would be kinda useful
(In reply to comment #1) > Providing us with a link to their new location would be kinda useful I'm sorry, I forgot that part, indeed. :) http://www.gentoo.org/proj/en/desktop/kde/kde-split-ebuilds.xml http://www.gentoo.org/proj/en/desktop/kde/kde-config.xml Those will be their new locations.
We shouldn't move kde-config.xml; it is properly part of the rest of our desktop installation guides. All the other DE and WM guides are part of /doc/en/; KDE should be no exception. If you have changes to make (which almost never happens), you can continue to submit patches etc. to the GDP.
(In reply to comment #3) > We shouldn't move kde-config.xml; it is properly part of the rest of our > desktop installation guides. All the other DE and WM guides are part of > /doc/en/; KDE should be no exception. As long as the document is valid and linked from our indices, it doesn't really matter who maintains it (and thus whether it's available under /doc/ or /proj/). While I don't like the idea of moving, either, the decision is up to the package maintainers, so if they wish to maintain the document themselves, they're free to do so. Anyway, we all have commit access to /proj/en/kde/, so we can always revert their nasty commits :p
First of all, I'd merge kdesplit-ebuilds into kde-config. We don't need a separate doc for that, especially that soon we will have only split ebuilds in the tree anyway (Wolf, please confirm!). Second, kde-config fits nicely with other desktop environment docs we have (gnome, fluxbox, xfce) and is very popular where it is. That's why I vote against moving it to proj/. You guys can just drop your desired fixes as a patch to this bug and we will merge it with that doc. We should be snatching best docs from proj/ to doc/ to stabilise and improve them there. Not the other way round. :-)
(In reply to comment #5) > First of all, I'd merge kdesplit-ebuilds into kde-config. We don't need a > separate doc for that, especially that soon we will have only split ebuilds in > the tree anyway (Wolf, please confirm!). Well, we'll keep KDE 3.5 in the tree for quite some time yet. Therefore, there will be monolithic ebuilds, too, for that time. (It's "Wulf", though. ;-) ) > Second, kde-config fits nicely with other desktop environment docs we have > (gnome, fluxbox, xfce) and is very popular where it is. That's why I vote > against moving it to proj/. I really want that thing in proj because I've had less than optimal experiences with some members of the docs-team (sorry, didn't want to bring that up at all) and it makes sense to have people who know about the stuff that it's about to work on the stuff. > You guys can just drop your desired fixes as a patch to this bug and we will > merge it with that doc. I tried to get a patch in for bug 125126 and it was rejected because of users mixing stable and testing. Which is unfortunate but reality. > We should be snatching best docs from proj/ to doc/ to stabilise and improve > them there. Not the other way round. :-) Not without the consent of the respective project. And the KDE project whose lead I am wants the docs about their stuff in their project space so I'd really like to ask you to do that. I think it's really up to me in the end, I'd say.
(In reply to comment #5) > Second, kde-config fits nicely with other desktop environment docs we have > (gnome, fluxbox, xfce) and is very popular where it is. Its url starting with /doc/en/ did not make it more popular, did it? > We should be snatching best docs from proj/ to doc/ to stabilise and improve > them there. Not the other way round. :-) Docs should be where they can be best improved, wherever that may be. (In reply to comment #3) > If you have changes to make (which almost never happens) Maybe that's *the* problem. AFAIAC, it's good riddance.
Thanks! (In reply to comment #7) > Docs should be where they can be best improved, wherever that may be. In this case, I think it's best in proj because we can all commit there.
In light of recent events (wth did happen?), could you guys please confirm this request? Thanks a lot.
(In reply to comment #9) > In light of recent events (wth did happen?), could you guys please confirm this > request? > Thanks a lot. We prefer to keep it where we have commit access, so we can work on it, thank you.
Thanks for your confirmation.
