Re: KDE/4.8.x is gone
El Dilluns, 2 de juliol de 2012, a les 22:29:59, Vishesh Handa va escriure: > On Mon, Jul 2, 2012 at 10:06 PM, todd rme wrote: > > On Mon, Jul 2, 2012 at 6:01 PM, Albert Astals Cid wrote: > > > After talking with David and Vishesh we decided to kill the KDE/4.8.x > > > and > > > bring its "improvements" to work with the old sopranos to KDE/4.8 > > > > > > So in summary: > > > KDE/4.9 is where 4.9 bugfixing happens, needs soprano 2.8 > > > KDE/4.8 is where 4.8 bugfixing happens (and if we ever release a 4.8.5 > > > > will > > > > > be tagged from here), needs stable soprano 2.7 (will crash with soprano > > > > > >= > > > > > > 2.7.56) > > > > > > Cheers, > > > > > > Albert > > > > So KDE 4.8 will not work with soprano 2.8? > > It will :) Oh, right, my e-mail may have been wrong about the crashiness of KDE/4.8 with "newer" sopranos, Vishesh knows more than me. Sorry if the summary was wrong. Cheers, Albert > > > -Todd
Re: Using userbase for manuals
On Sunday 01 July 2012 Jul, Anne Wilson wrote: > I'm not subscribed to this list, so please cc me in any replies. Sort of proves my point that Mirko is right and that we need a KDE-wide mailing list for all contributors. <...> > Boud - I'm not arguing, but is email notification essential? Maybe it > is, but it's possible to craft an RSS/Atom feed for Recent Changes > affecting your pages. Would that help? Oh, that would work as well. I get forum updates in akregator, and that's fine. I just need all changes to a certain "project" pushed to me, because I simply don't have the time to check manually what is changed. <...> > Something I'd really like to see is applications having links to > UserBase and forum.kde.org (maybe to a specific sub-forum) in the Help > menu. Perhaps that's what Christoph had in mind. Good point about the link to the forum. I definitely want that! -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Using userbase for manuals
On Sunday 01 July 2012 Jul, Yuri Chornoivan wrote: > Hi, > > Just a minor remarks on using UserBase for documentation. > > 1. It does not matter where you *do not* write your documentation. > > New Krita manual was started 5-01-2010 [1]. For now, it is not ready even > at 1/10 level. The activity is extremely low. The content is badly > formatted and hardly useful. Yet, it is 100% more than the effort that was expended on the 2.0 docbook manual. The reasons I never got further were: * no time * I hate writing wiki markup * no time The reason no users took up the effort were: * I mistakenly tried to keep the manual writing to myself, because I thought I could do the job and create a nice, uniform, consistent manual, just like the Krita 1.6 manual, which people have told me was about the best manual of any KDE app. That didn't work out. But without the wiki link, the user currently working on the manual would ever have offered his help. > The projection can be made (by exploring similar wiki documentation > projects, like Fedora, openSUSE, Mandriva, and Debian/Ubuntu) that when it > will be ready it becomes obsolete for the current version. That holds for all manuals... > > Example of the manual that once was written and now partially outdated is > Amarok Manual [2]. > > 2. Simple conversion docbook to wiki does not make manual useful. > > Example: Kexi handbook [3] was roughly converted to wiki with broken > formatting, lost of index, and no substantial changes. Thanks to Burkhard > it was polished (as a docbook) and converted back thanks to Claus > Christensen. > > 3. Manuals can live without wiki conversion. > > Examples: Calligra Stage [4] and Calligra Sheets [5] manuals were never > converted to wiki. For whatever reason, they are now in much more helpful > state than Words and Krita docs (not saying that they have offline > versions). That's because those applications didn't change so much; it had nothing to do with the conversion to wiki or not, but more with the applications not changing enough to outdate the manual. Because the 1.x krita manual was so good, it was impossible to update it for 2.0; there was too much that was irrelevant, and it needed to be rewritten completely. > > 4. Proper formatting allows very easy conversion from wiki XML to docbook. > > Once well-formatted, wiki pages can be converted into offline form > (docbook, PDF, or EPUB) in almost no time[6]. > > Examples: > Amarok, Kexi, Kdenlive, KrossWordPuzzle, part of KMail offline manuals are > converted (and slightly fixed) UserBase manuals. > > Just for curiosity, you can compare the level of the translation covering > for these docs in kde-i18n Subversion [7] and on UserBase. > > Conclusion > > I know that it is hard for developers to keep backward compatibility. But > please do not cease to maintain DocBook compatibility in KDE 5. If you do, > you will likely lost most of your docs and most of your documentation > translators. > > I am far from making decision for developers, but it is always good to > have some plan with real results. Just moving docs in hope that after that > someone definitely write them is counterproductive. > > Just my 2 cents. > > Best regards, > Yuri > KDE Ukrainian team coordinator > > [1] http://userbase.kde.org/User:Boudewijn/Krita/Manual > [2] http://userbase.kde.org/Amarok/Manual > [3] http://userbase.kde.org/Kexi/Handbook > [4] http://docs.kde.org/development/en/calligra/stage/index.html > [5] http://docs.kde.org/development/en/calligra/sheets/index.html > [6] http://userbase.kde.org/How_To_Convert_a_UserBase_Manual_to_Docbook > [7] http://l10n.kde.org/stats/doc/trunk-kde4/team/ > > -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: KDE/4.8.x is gone
On Mon, Jul 2, 2012 at 10:06 PM, todd rme wrote: > On Mon, Jul 2, 2012 at 6:01 PM, Albert Astals Cid wrote: > > After talking with David and Vishesh we decided to kill the KDE/4.8.x and > > bring its "improvements" to work with the old sopranos to KDE/4.8 > > > > So in summary: > > KDE/4.9 is where 4.9 bugfixing happens, needs soprano 2.8 > > KDE/4.8 is where 4.8 bugfixing happens (and if we ever release a 4.8.5 > will > > be tagged from here), needs stable soprano 2.7 (will crash with soprano > >= > > 2.7.56) > > > > Cheers, > > Albert > > So KDE 4.8 will not work with soprano 2.8? > It will :) > > -Todd > -- Vishesh Handa
Re: KDE/4.8.x is gone
On Mon, Jul 2, 2012 at 6:01 PM, Albert Astals Cid wrote: > After talking with David and Vishesh we decided to kill the KDE/4.8.x and > bring its "improvements" to work with the old sopranos to KDE/4.8 > > So in summary: > KDE/4.9 is where 4.9 bugfixing happens, needs soprano 2.8 > KDE/4.8 is where 4.8 bugfixing happens (and if we ever release a 4.8.5 will > be tagged from here), needs stable soprano 2.7 (will crash with soprano >= > 2.7.56) > > Cheers, > Albert So KDE 4.8 will not work with soprano 2.8? -Todd
KDE/4.8.x is gone
After talking with David and Vishesh we decided to kill the KDE/4.8.x and bring its "improvements" to work with the old sopranos to KDE/4.8 So in summary: KDE/4.9 is where 4.9 bugfixing happens, needs soprano 2.8 KDE/4.8 is where 4.8 bugfixing happens (and if we ever release a 4.8.5 will be tagged from here), needs stable soprano 2.7 (will crash with soprano >= 2.7.56) Cheers, Albert
Re: About Writing Documentation in KDE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/12 11:56, Yuri Chornoivan wrote: > Mon, 02 Jul 2012 12:00:05 +0300 було написано Anne Wilson > : > > The better availability, fast editing capabilities, good > translation support of current UserBase have not produce many high > quality handbooks yet. Some sort of recipes, good tutorials, but > there are only a few handbooks... All converted docbooks have > links to corresponding UserBase pages, so there is nothing to > prevent users from fixing them. > > Hence, we have to admit that the main problem is the lack of KDE > documenters themselves, not the format or the place where the docs > are stored. > Totally agreed. In the past many people told us that docbook was the main reason they didn't write manuals. Having provided an alternative we find that still many people don't write it. Recently it has been said that, when tried, the UserBase method is found to be easier, but it's not well-known, so many don't try it. The only answer to that, that I can see, is to talk about it here and elsewhere :-) > Now, we can live with both systems. If developers want their > documentation to be based on UserBase pages, it's OK. If they want > to have tutorials (videos, screencastings) on UserBase, it's OK > too. Do not want to have UserBase handbook? Even this is OK. ;) > Again, I agree. In fact the decision is likely to be dictated by the potential user-base of the application in question. What I do want to see, though, is cross-linking between different sources of help. > > And as a final note, some KDE application have copyrights of 2005 > year and that does not prevent them to work properly (as in 2005) > if they were written by talented KDE developers. ;) > I quoted the 2005 date as an example of the fact that few applications are still in a KDE 3 incarnation, and it's hard to believe that the change to KDE 4 brought no change to the application :-) I won't waste my time or yours checking for individual examples - the principle is what matters in this discussion. Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/xkWcACgkQj93fyh4cnBc3IQCgg9n/EqWV1ldX0T/sjdrxOVYA XoMAn0Wn15lfqtS1rOeDEKMur58EAu1l =+AYS -END PGP SIGNATURE-
Re: About Writing Documentation in KDE
Mon, 02 Jul 2012 12:00:05 +0300 було написано Anne Wilson : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/12 09:00, Albert Astals Cid wrote: El Dilluns, 2 de juliol de 2012, a les 01:45:14, Dominik Haumann va escriure: Hi everyone, so let's sum up and get back to arguments. 1. Versioning for our KDE SC Releases It was mentioned that a wiki automatically provides versioning. However, what is completely not covered, yet, is the fact that we have different KDE SC releases. There is not 'branching' support for the wikis, so you have to create different wiki pages, copying the entire content for each release. Contrary, this is completely covered by maintaining the documentation in the respective modules. This is also the reason why we have documentation freezes (even one of the last freezes [2]). 2. Documentation Team We have a documentation team, even for each of our supported languages. They coordinate on kde-i18n-doc [1], and Burkhard offered support several times, saying that if you do not want to write docbook, the documentation team will do the markup, they even write the documentation for you to some extent. 3. Consistency The documentation team makes sure the documentation sticks to the documentation guidelines for consistency (example: folder vs. directory). This was mentioned in the past several times on the mailing lists. Again, a statement of the documentation team is very important here. 4. Getting Help Please ask the documentation team for their opinion, before raising critics the way it currently works. Maybe it works for a lot of other projects perfectly fine. In the thread it was mentioned, that some people do not even know where the documentation resides (maybe this is due to the partial transition to git). A simple solution is to ask the documentation team (or Burkhard) where to find the documentation. I'm pretty sure the documentation team has really valuable information. Please do not ignore them. 5. A Simple Solution: Possibility of a Combination If docbook really does not work for your project, it's fine to have an additional entry in the Help menu that links to the "Community Documentation" on UserBase. There is room for both, docbook and the wiki. 6. Respect [4]: Akademy Award In 2010, Burkhard Lück got the Akademy Award for his fantastic work on improving the state of the KDE documentation [3], supported by the entire KDE community. Now, two years later, this thread on kcd acts as if the documentation completely sucks. Guys, it does not. Really. Please think about this for a minute... (see 5.) That's all. 7. The one that does the work decides I also want to note that developers that do not write documentation in docbook and that do not translate manuals are suggesting to switch to wiki (even if they agree they won't write documentation anyway) while people doing documentation and translation of manuals (Yuri, Burkhard, Chusslove) say the current workflow is good. Seems like the "The one that does the work decides" is being ingored. This is not in any way dissing the work of those that put in much effort but - If the current system is so good, can someone please explain to me why distros ship with docbook help pages that were written years ago and not updated since? Anne The current system has many shortcomings that were pointed out by many people in this thread. But these shortcomings are not the reason to fight current offline system. The better availability, fast editing capabilities, good translation support of current UserBase have not produce many high quality handbooks yet. Some sort of recipes, good tutorials, but there are only a few handbooks... All converted docbooks have links to corresponding UserBase pages, so there is nothing to prevent users from fixing them. Hence, we have to admit that the main problem is the lack of KDE documenters themselves, not the format or the place where the docs are stored. Now, we can live with both systems. If developers want their documentation to be based on UserBase pages, it's OK. If they want to have tutorials (videos, screencastings) on UserBase, it's OK too. Do not want to have UserBase handbook? Even this is OK. ;) What is the reason to push documentation where it slowly dies without any attention (like rekonq docs, for example)? Let developers to decide themselves what is better: fixed handbook in their repo, contacts with Documentation team and link to index.html in .desktop file or link to http://userbase.kde.org/Special:MyLanguage/APP_NAME/Handbook (to have localization support, not just like it was done in Krita) and self-written or user-written documentation. If some user havs a concern about current state of offline documentation, there is a link to complain at the bottom of each of its pages. If some users file a bug about lack of offline copy or offline translation we can provide them if UserBa
Re: About Writing Documentation in KDE
> El Dilluns, 2 de juliol de 2012, a les 10:00:05, Anne Wilson va > escriure: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > - -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 02/07/12 09:00, Albert Astals Cid wrote: > > > El Dilluns, 2 de juliol de 2012, a les 01:45:14, Dominik Haumann > > > va > > > > > > escriure: > > >> Hi everyone, > > >> > > >> so let's sum up and get back to arguments. > > >> > > >> 1. Versioning for our KDE SC Releases It was mentioned that a > > >> wiki automatically provides versioning. However, what is > > >> completely not covered, yet, is the fact that we have different > > >> KDE SC releases. There is not 'branching' support for the wikis, > > >> > > >> so you have to create different wiki pages, copying the entire > > >> > > >> content for each release. > > >> > > >> Contrary, this is completely covered by maintaining the > > >> documentation in the respective modules. This is also the reason > > >> > > >> why we have documentation freezes (even one of the last freezes > > >> [2]). > > >> > > >> 2. Documentation Team We have a documentation team, even for > > >> each > > >> of our supported languages. They coordinate on kde-i18n-doc [1], > > >> and Burkhard offered support several times, saying that if you > > >> do > > >> not want to write docbook, the documentation team will do the > > >> markup, they even write the documentation for you to some > > >> extent. > > >> > > >> 3. Consistency The documentation team makes sure the > > >> documentation sticks to the documentation guidelines for > > >> consistency (example: folder vs. directory). This was mentioned > > >> in the past several times on the mailing lists. Again, a > > >> statement of the documentation team is very important here. > > >> > > >> 4. Getting Help Please ask the documentation team for their > > >> opinion, before raising critics the way it currently works. > > >> Maybe > > >> it works for a lot of other projects perfectly fine. In the > > >> thread it was mentioned, that some people do not even know where > > >> the documentation resides (maybe this is due to the partial > > >> transition to git). A simple solution is to ask the > > >> documentation > > >> team (or Burkhard) where to find the documentation. I'm pretty > > >> sure the documentation team has really valuable information. > > >> Please do not ignore them. > > >> > > >> 5. A Simple Solution: Possibility of a Combination If docbook > > >> really does not work for your project, it's fine to have an > > >> additional entry in the Help menu that links to the "Community > > >> Documentation" on UserBase. There is room for both, docbook and > > >> the wiki. > > >> > > >> 6. Respect [4]: Akademy Award In 2010, Burkhard Lück got the > > >> Akademy Award for his fantastic work on improving the state of > > >> the KDE documentation [3], supported by the entire KDE > > >> community. > > >> Now, two years later, this thread on kcd acts as if the > > >> documentation completely sucks. Guys, it does not. Really. > > >> Please > > >> think about this for a minute... (see 5.) > > >> > > >> That's all. > > > > > > 7. The one that does the work decides I also want to note that > > > developers that do not write documentation in docbook and that do > > > not translate manuals are suggesting to switch to wiki (even if > > > they agree they won't write documentation anyway) while people > > > doing documentation and translation of manuals (Yuri, Burkhard, > > > Chusslove) say the current workflow is good. Seems like the "The > > > one that does the work decides" is being ingored. > > > > This is not in any way dissing the work of those that put in much > > effort but - > > > > If the current system is so good, can someone please explain to me > > why > > distros ship with docbook help pages that were written years ago > > and > > not updated since? > > Maybe they don't need to be updated? > http://techbase.kde.org/Projects/Documentation/KDE4_%28health_table%29 > looks quite green to me Yeah, and, just as an other example, look at the state for Kate docs: State of manual: The manual is really nice, Burkhard and Hollingsworth really keep the manual up-to-date and complete. Thanks to the brilliant work of our translators, we even get this translated! Thanks to all for that massive work State of wiki: Look at http://userbase.kde.org/Kate The user base page about Kate is just a small skeleton, even no german translation is around. But, I agree, that it might be nice to have some predefined link in the menu to go to the matching userbase page for the app, if available, in the right language, to allow the user to discover this additional information more easily Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken
Re: Review Request: Move KdepimLibs dependency to DrKonqi
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105402/#review15306 --- This review has been submitted with commit e6d030f33a366b1d0099f71601eb9c623957d9c2 by Michael Palimaka to branch KDE/4.9. - Commit Hook On July 1, 2012, 4:23 p.m., Michael Palimaka wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105402/ > --- > > (Updated July 1, 2012, 4:23 p.m.) > > > Review request for KDE Runtime and George Kiagiadakis. > > > Description > --- > > This patch moves the dependency on KdepimLibs to /drkonqi, since that's the > program requiring it. > > This is done to assist downstream packaging. > > > Diffs > - > > CMakeLists.txt 5091890a0768fd553f972a9b113f7f826d63f356 > drkonqi/CMakeLists.txt 102185ac52f558fba78cf2da80a1e8a0fe870e18 > > Diff: http://git.reviewboard.kde.org/r/105402/diff/ > > > Testing > --- > > > Thanks, > > Michael Palimaka > >
Re: About Writing Documentation in KDE
El Dilluns, 2 de juliol de 2012, a les 10:00:05, Anne Wilson va escriure: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > - -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/07/12 09:00, Albert Astals Cid wrote: > > El Dilluns, 2 de juliol de 2012, a les 01:45:14, Dominik Haumann va > > > > escriure: > >> Hi everyone, > >> > >> so let's sum up and get back to arguments. > >> > >> 1. Versioning for our KDE SC Releases It was mentioned that a > >> wiki automatically provides versioning. However, what is > >> completely not covered, yet, is the fact that we have different > >> KDE SC releases. There is not 'branching' support for the wikis, > >> > >> so you have to create different wiki pages, copying the entire > >> > >> content for each release. > >> > >> Contrary, this is completely covered by maintaining the > >> documentation in the respective modules. This is also the reason > >> > >> why we have documentation freezes (even one of the last freezes > >> [2]). > >> > >> 2. Documentation Team We have a documentation team, even for each > >> of our supported languages. They coordinate on kde-i18n-doc [1], > >> and Burkhard offered support several times, saying that if you do > >> not want to write docbook, the documentation team will do the > >> markup, they even write the documentation for you to some > >> extent. > >> > >> 3. Consistency The documentation team makes sure the > >> documentation sticks to the documentation guidelines for > >> consistency (example: folder vs. directory). This was mentioned > >> in the past several times on the mailing lists. Again, a > >> statement of the documentation team is very important here. > >> > >> 4. Getting Help Please ask the documentation team for their > >> opinion, before raising critics the way it currently works. Maybe > >> it works for a lot of other projects perfectly fine. In the > >> thread it was mentioned, that some people do not even know where > >> the documentation resides (maybe this is due to the partial > >> transition to git). A simple solution is to ask the documentation > >> team (or Burkhard) where to find the documentation. I'm pretty > >> sure the documentation team has really valuable information. > >> Please do not ignore them. > >> > >> 5. A Simple Solution: Possibility of a Combination If docbook > >> really does not work for your project, it's fine to have an > >> additional entry in the Help menu that links to the "Community > >> Documentation" on UserBase. There is room for both, docbook and > >> the wiki. > >> > >> 6. Respect [4]: Akademy Award In 2010, Burkhard Lück got the > >> Akademy Award for his fantastic work on improving the state of > >> the KDE documentation [3], supported by the entire KDE community. > >> Now, two years later, this thread on kcd acts as if the > >> documentation completely sucks. Guys, it does not. Really. Please > >> think about this for a minute... (see 5.) > >> > >> That's all. > > > > 7. The one that does the work decides I also want to note that > > developers that do not write documentation in docbook and that do > > not translate manuals are suggesting to switch to wiki (even if > > they agree they won't write documentation anyway) while people > > doing documentation and translation of manuals (Yuri, Burkhard, > > Chusslove) say the current workflow is good. Seems like the "The > > one that does the work decides" is being ingored. > > This is not in any way dissing the work of those that put in much > effort but - > > If the current system is so good, can someone please explain to me why > distros ship with docbook help pages that were written years ago and > not updated since? Maybe they don't need to be updated? http://techbase.kde.org/Projects/Documentation/KDE4_%28health_table%29 looks quite green to me Cheers, Albert > > Anne > > - -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk/xYsQACgkQj93fyh4cnBfP1gCfbC0VcQPgK5yfwnjeNNw78yFG > GV8An06jkszrvKXT2Bvrcx9BSyHdQ0jg > =b094 > - -END PGP SIGNATURE- > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk/xYxMACgkQj93fyh4cnBf1XwCgiObTExc3vZ/kbGdGuE3COU8g > BV0An3OTxK1+ktasLoKbiyFw9lXtTbdk > =fHkk > -END PGP SIGNATURE-
Re: Review Request: Move KdepimLibs dependency to DrKonqi
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105402/#review15304 --- This review has been submitted with commit e2061f512ce1f422290d755827400d2cbbf0ad0f by Michael Palimaka to branch master. - Commit Hook On July 1, 2012, 4:23 p.m., Michael Palimaka wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105402/ > --- > > (Updated July 1, 2012, 4:23 p.m.) > > > Review request for KDE Runtime and George Kiagiadakis. > > > Description > --- > > This patch moves the dependency on KdepimLibs to /drkonqi, since that's the > program requiring it. > > This is done to assist downstream packaging. > > > Diffs > - > > CMakeLists.txt 5091890a0768fd553f972a9b113f7f826d63f356 > drkonqi/CMakeLists.txt 102185ac52f558fba78cf2da80a1e8a0fe870e18 > > Diff: http://git.reviewboard.kde.org/r/105402/diff/ > > > Testing > --- > > > Thanks, > > Michael Palimaka > >
Re: About Writing Documentation in KDE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/12 09:00, Albert Astals Cid wrote: > El Dilluns, 2 de juliol de 2012, a les 01:45:14, Dominik Haumann va > escriure: >> Hi everyone, >> >> so let's sum up and get back to arguments. >> >> 1. Versioning for our KDE SC Releases It was mentioned that a >> wiki automatically provides versioning. However, what is >> completely not covered, yet, is the fact that we have different >> KDE SC releases. There is not 'branching' support for the wikis, >> so you have to create different wiki pages, copying the entire >> content for each release. >> >> Contrary, this is completely covered by maintaining the >> documentation in the respective modules. This is also the reason >> why we have documentation freezes (even one of the last freezes >> [2]). >> >> 2. Documentation Team We have a documentation team, even for each >> of our supported languages. They coordinate on kde-i18n-doc [1], >> and Burkhard offered support several times, saying that if you do >> not want to write docbook, the documentation team will do the >> markup, they even write the documentation for you to some >> extent. >> >> 3. Consistency The documentation team makes sure the >> documentation sticks to the documentation guidelines for >> consistency (example: folder vs. directory). This was mentioned >> in the past several times on the mailing lists. Again, a >> statement of the documentation team is very important here. >> >> 4. Getting Help Please ask the documentation team for their >> opinion, before raising critics the way it currently works. Maybe >> it works for a lot of other projects perfectly fine. In the >> thread it was mentioned, that some people do not even know where >> the documentation resides (maybe this is due to the partial >> transition to git). A simple solution is to ask the documentation >> team (or Burkhard) where to find the documentation. I'm pretty >> sure the documentation team has really valuable information. >> Please do not ignore them. >> >> 5. A Simple Solution: Possibility of a Combination If docbook >> really does not work for your project, it's fine to have an >> additional entry in the Help menu that links to the "Community >> Documentation" on UserBase. There is room for both, docbook and >> the wiki. >> >> 6. Respect [4]: Akademy Award In 2010, Burkhard Lück got the >> Akademy Award for his fantastic work on improving the state of >> the KDE documentation [3], supported by the entire KDE community. >> Now, two years later, this thread on kcd acts as if the >> documentation completely sucks. Guys, it does not. Really. Please >> think about this for a minute... (see 5.) >> >> That's all. > > 7. The one that does the work decides I also want to note that > developers that do not write documentation in docbook and that do > not translate manuals are suggesting to switch to wiki (even if > they agree they won't write documentation anyway) while people > doing documentation and translation of manuals (Yuri, Burkhard, > Chusslove) say the current workflow is good. Seems like the "The > one that does the work decides" is being ingored. > This is not in any way dissing the work of those that put in much effort but - If the current system is so good, can someone please explain to me why distros ship with docbook help pages that were written years ago and not updated since? Anne - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/xYsQACgkQj93fyh4cnBfP1gCfbC0VcQPgK5yfwnjeNNw78yFG GV8An06jkszrvKXT2Bvrcx9BSyHdQ0jg =b094 - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/xYxMACgkQj93fyh4cnBf1XwCgiObTExc3vZ/kbGdGuE3COU8g BV0An3OTxK1+ktasLoKbiyFw9lXtTbdk =fHkk -END PGP SIGNATURE-
Re: Review Request: Move KdepimLibs dependency to DrKonqi
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105402/#review15303 --- Ship it! Looks harmless, go ahead - George Kiagiadakis On July 1, 2012, 4:23 p.m., Michael Palimaka wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105402/ > --- > > (Updated July 1, 2012, 4:23 p.m.) > > > Review request for KDE Runtime and George Kiagiadakis. > > > Description > --- > > This patch moves the dependency on KdepimLibs to /drkonqi, since that's the > program requiring it. > > This is done to assist downstream packaging. > > > Diffs > - > > CMakeLists.txt 5091890a0768fd553f972a9b113f7f826d63f356 > drkonqi/CMakeLists.txt 102185ac52f558fba78cf2da80a1e8a0fe870e18 > > Diff: http://git.reviewboard.kde.org/r/105402/diff/ > > > Testing > --- > > > Thanks, > > Michael Palimaka > >
Re: Compiler version
> > Debian Stable (Squeeze) is also 4.5 by default. > > Debian Stable (Squeeze) is 4.4.5 by default, with GCC 4.3.5 being > provided too. Yes, that is the reason I excluded Debian from the distros to watch in this case. Debian stable will not ship 4.10 in any form, and from my experience, people who use debian on the desktop, and care about having latest kde packages, use testing or sid. (myself included) Cheerio -- I don't really trust a sane person. -- Lyle Alzado
Re: About Writing Documentation in KDE (was: Using userbase for manuals)
El Dilluns, 2 de juliol de 2012, a les 01:45:14, Dominik Haumann va escriure: > Hi everyone, > > so let's sum up and get back to arguments. > > 1. Versioning for our KDE SC Releases > It was mentioned that a wiki automatically provides versioning. However, > what is completely not covered, yet, is the fact that we have different KDE > SC releases. There is not 'branching' support for the wikis, so you have to > create different wiki pages, copying the entire content for each release. > > Contrary, this is completely covered by maintaining the documentation in the > respective modules. This is also the reason why we have documentation > freezes (even one of the last freezes [2]). > > 2. Documentation Team > We have a documentation team, even for each of our supported languages. They > coordinate on kde-i18n-doc [1], and Burkhard offered support several times, > saying that if you do not want to write docbook, the documentation team > will do the markup, they even write the documentation for you to some > extent. > > 3. Consistency > The documentation team makes sure the documentation sticks to the > documentation guidelines for consistency (example: folder vs. directory). > This was mentioned in the past several times on the mailing lists. Again, a > statement of the documentation team is very important here. > > 4. Getting Help > Please ask the documentation team for their opinion, before raising critics > the way it currently works. Maybe it works for a lot of other projects > perfectly fine. In the thread it was mentioned, that some people do not even > know where the documentation resides (maybe this is due to the partial > transition to git). A simple solution is to ask the documentation team (or > Burkhard) where to find the documentation. > I'm pretty sure the documentation team has really valuable information. > Please do not ignore them. > > 5. A Simple Solution: Possibility of a Combination > If docbook really does not work for your project, it's fine to have an > additional entry in the Help menu that links to the "Community > Documentation" on UserBase. > There is room for both, docbook and the wiki. > > 6. Respect [4]: Akademy Award > In 2010, Burkhard Lück got the Akademy Award for his fantastic work on > improving the state of the KDE documentation [3], supported by the entire > KDE community. Now, two years later, this thread on kcd acts as if the > documentation completely sucks. Guys, it does not. Really. Please think > about this for a minute... (see 5.) > > That's all. 7. The one that does the work decides I also want to note that developers that do not write documentation in docbook and that do not translate manuals are suggesting to switch to wiki (even if they agree they won't write documentation anyway) while people doing documentation and translation of manuals (Yuri, Burkhard, Chusslove) say the current workflow is good. Seems like the "The one that does the work decides" is being ingored. Cheers, Albert > > Thanks, > Dominik > > [1] https://mail.kde.org/mailman/listinfo/kde-i18n-doc/ > [2] > http://techbase.kde.org/Schedules/KDE4/4.8_Release_Schedule#Monday.2C_Decem > ber_19.2C_2011:_KDE_SC_4.8_Documentation_Freeze [3] > http://dot.kde.org/2010/07/05/akademy-day-2 > [4] http://www.kde.org/code-of-conduct/
