Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sun, 4 Apr 2010 03:20:53 +0200 Ben de Groot yng...@gentoo.org wrote: GuideXML documents are often experienced as an unnecessary barrier. I think you should clearly state again that this is not gonna replace GuideXML, just migrate a few use cases where a wiki fits better. This is what you aim for, right? No, he's definitely out to kill GuideXML. Just give him time. A wiki can fulfill several purposes for us: 1. Easy collaboration among devs, for brainstorming, developing new documentation, assembling upcoming meeting agendas, and so on [for which there currently is not really any obvious place] This is not *impossible* with our current setup; it can still be done in a few different ways: 1) project spaces in /proj/$LANG/foobar/ -- how hard is it to commit to CVS when going through document drafts? 2) devspaces -- it's easy enough to dump stuff in here for others to refer to However, a wiki *does* make it easier for everyone to jump right in and edit stuff as ideas are passed around, rather than waiting for someone to make changes to something in a devspace. 3. A place to host and maintain our existing documentation [which is currently in GuideXML] Entirely unnecessary duplication of effort. To quote the forum mods, don't cross-post . . . and especially don't do it if you'll be violating a doc license somewhere. It's one of the reasons why we don't use existing unofficial wiki content in our docs. I and the GDP have written about that ad nauseum over the years; just search the list archives. I am not pushing for our existing documentation to be migrated into a wiki at this point. But I think that once the place is there, and it functions well, it would be the obvious next step to do so. As I said before, the barrier to contributing and maintaining documentation is much higher in the case of GuideXML, so it doesn't really make sense to keep that around when we have a better solution. I know there are people who do not agree with me on this last point . . . to say the least. Show me a wiki that has the flexibility of our handbook, which can be a huge printer-friendly all-in-one doc, or an as-you-need-it doc with one page per chapter. Show me a wiki that has built-in intradoc linking to every paragraph, chapter, subchapter, code sample, etc. Show me a wiki that produces such beautiful code samples (with titles). Show me a wiki that can produce the following formatting for ebuilds: http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap2_sect7 . . . or a wiki that makes it super-easy to add all sorts of additional in-line formatting to regular paragraphs, for example all the blue highlighting for code used throughout http://www.gentoo.org/doc/en/xml-guide.xml, or the monospace font used for filesystem paths. Show me a wiki that makes it easy to create tables, for example, compare RadeonProgram from the x.org wiki: http://www.x.org/wiki/RadeonProgram?action=edit ||-2 style=text-align: center; background-color: #66 '''Native''' ||style=text-align: center; background-color: #66 '''R100''' ||style=text-align: center; background-color: #66 '''R200''' ||style=text-align: center; background-color: #66 '''R300''' ||style=text-align: center; background-color: #66 '''R400''' ||style=text-align: center; background-color: #66 '''RS690''' ||style=text-align: center; background-color: #66 '''R500''' ||style=text-align: center; background-color: #66 '''R600''' ||style=text-align: center; background-color: #66 '''R700''' || . . . that's one line of cells. One. Ugly. Compare it to: http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap5_pre1 table tr thFoo/th thBar/th /tr tr tiThis is an example for indentation/ti timore stuff/ti /tr /table Which is easier to read and instantly comprehend? By moving to a wiki, you'll lose a huge percentage of what GuideXML can do, in exchange for quicker and easier editing and creation of docs, though neither of these have been qualified. As some others on this list have mentioned, wiki syntax is downright ugly and simply not as consistent or readable as plain ol' XML or HTML. From what I've seen, the biggest objection to GuideXML is folks don't want to take the time to learn a few tags. Well, you'll have to learn tags and syntax for either system, so pick your poison. I've yet to see a wiki that even has as much sense as HTML, which is pretty low on the totem pole of consistency. I ain't out to stop ya'll from using a wiki. I do agree that they have some advantages. However, I will point out how limited wikis are. They're not a magic bullet that will solve all our problems. signature.asc Description: PGP signature
Re: [gentoo-dev] Is Gentoo dying?
Joshua Saddler wrote lots of: Thanks for sh**ting on my efforts. See, this is not about your personal efforts. I really do appreciate the work and time you invest in improving both the docs and PR. But otoh try to compare what the docs-team and PR did say 5 years ago and what they're doing today (at least what becomes visible for people outside of these projects). 5 years ago we had constantly new docs added, we still had our Gentoo Weekly Newsletter - both just some *examples*. Nothing against you personal efforts, but both (important!) areas could be improved and be made more active again. - Tobias
Re: [gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass
On Sat, 3 Apr 2010 12:33:48 +0200 Torsten Veller ml...@veller.net wrote: perl people use `perldoc` anyway. Yep. Why have a man page for a perl module? OTOH, if there is something that goes in /usr/bin, it should get a man page if there is one. But not for the modules themselves -- that's not needed at all. Just my $0.02. -- |\ /|| | ~ ~ | \/ ||---| `|` ? ||ichael | |iggins\^ / michael.higgins[at]evolone[dot]org
Re: [gentoo-dev] Is Gentoo dying?
On 04/04/2010 04:48 AM, Joshua Saddler wrote: On Sat, 03 Apr 2010 11:16:32 +0200 Tobias Scherbaum dertobi...@gentoo.org wrote: - Our formerly outstanding documentation still is somewhat maintained, but that's it. I haven't seen any new additions (both to our docs, but also to our docs-team) for years. People are constantly asking for a documentation wiki, but ... Thanks for sh**ting on my efforts. There are lots of visible changes, and I make a point of getting the word out when a new guide turns up in /doc/. I blog about the new docs I add, and I spend awhile working with contributors to make sure we get good stuff out there and that it's constantly updated -- the Openbox guide Nate Zachary wrote comes to mind. I'm also always working with developers who are writing docs in their spare time, coaching 'em through the process, assisting with GuideXML, taking patches, *and* creating patches and updates for devs who are posting documents in /proj/ and in their personal devspace. But I guess that doesn't mean anything to you. But isn't there a problem when it's my not our effort? Ideally we would have a couple people like you on board. If we stayed quiet about our perceptions then there was never the opportunity to correct them. I think the thread was done done constructively not destructively. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 4 April 2010 13:01, Joshua Saddler nightmo...@gentoo.org wrote: [...] I am not pushing for our existing documentation to be migrated into a wiki at this point. But I think that once the place is there, and it functions well, it would be the obvious next step to do so. As I said before, the barrier to contributing and maintaining documentation is much higher in the case of GuideXML, so it doesn't really make sense to keep that around when we have a better solution. I know there are people who do not agree with me on this last point [... lots of good reasons to keep the documentation in GuideXML ...] I think the docs team has put in a huge amount of effort for a long time now to make well-formatted, easily readable documentation, and there really isn't a wiki solution out there that is remotely comparable. GuideXML isn't that hard to pick up, and I'm sure the docs team would be happy to help someone who's having trouble figuring out how to do something with it. So I *really* don't see ease-of-use being a good excuse for replacing GuideXML with a wiki. The difference in ease is not that high. [...] I ain't out to stop ya'll from using a wiki. I do agree that they have some advantages. However, I will point out how limited wikis are. They're not a magic bullet that will solve all our problems. Again, I agree. We _should_ have a wiki for easy note-taking, maintaining todo lists, possibly even meeting minutes. But our official documentation should go through sufficient review and formatting to make sure we maintain the quality of documentation that we have had so far. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] Is Gentoo dying?
On 04/04/10 03:48, Joshua Saddler wrote: On Sat, 03 Apr 2010 11:16:32 +0200 Tobias Scherbaum dertobi...@gentoo.org wrote: - Our formerly outstanding documentation still is somewhat maintained, but that's it. I haven't seen any new additions (both to our docs, but also to our docs-team) for years. People are constantly asking for a documentation wiki, but ... Thanks for sh**ting on my efforts. There are lots of visible changes, and I make a point of getting the word out when a new guide turns up in /doc/. I blog about the new docs I add, and I spend awhile working with contributors to make sure we get good stuff out there and that it's constantly updated -- the Openbox guide Nate Zachary wrote comes to mind. I'm also always working with developers who are writing docs in their spare time, coaching 'em through the process, assisting with GuideXML, taking patches, *and* creating patches and updates for devs who are posting documents in /proj/ and in their personal devspace. But I guess that doesn't mean anything to you. Oh yes, and I spend hours each week constantly updating docs based on the inflow of bugs, forum reports, and I constantly re-read each one and improve stuff where I can on-the-fly. Not everything has a bug tracker, but the end result is still a visible difference in the stuff you see on the website. See, that's the problem. *You* are doing a good job. *We* as a team/community/ant colony aren't. The visible rate of change has slowed down, and from your reply I get the feeling that there are also fewer people working on docs than in the past. So how do we improve the situation? What needs to be done so that you could disappear for a month or two without affecting progress because there are enough other motivated people sharing the workload? My long-term goal is still to make me redundant. That way I can take a break whenever I get frustrated and I can focus on new things whenever I find something new and shiny to attract my attention...
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 04/04/10 10:29, Arun Raghavan wrote: We _should_ have a wiki for easy note-taking, maintaining todo lists, possibly even meeting minutes. But our official documentation should go through sufficient review and formatting to make sure we maintain the quality of documentation that we have had so far. I suppose this^^^ is both a good solution and compromise, both to wiki-fans and the doc team. Ben, could you live with that? Anyone else having stomach aches with this? Sebastian
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Joshua Saddler dixit (2010-04-04, 00:31): Show me a wiki that has the flexibility of our handbook, which can be a huge printer-friendly all-in-one doc, or an as-you-need-it doc with one page per chapter. Show me a wiki that has built-in intradoc linking to every paragraph, chapter, subchapter, code sample, etc. Show me a wiki that produces such beautiful code samples (with titles). Show me a wiki that can produce the following formatting for ebuilds: http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap2_sect7 . . . or a wiki that makes it super-easy to add all sorts of additional in-line formatting to regular paragraphs, for example all the blue highlighting for code used throughout http://www.gentoo.org/doc/en/xml-guide.xml, or the monospace font used for filesystem paths. [...] Has anyone considered the immensely powerful twiki? -- [a]
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 04/04/10 10:48, Antoni Grzymala wrote: Has anyone considered the immensely powerful twiki? if the wikis i have worked with twiki was the least fun. it feels strange and it's native syntax sucks big time, to say the least. sebastian
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sun, 4 Apr 2010 00:31:52 -0700, Joshua Saddler
nightmo...@gentoo.org wrote:
No, he's definitely out to kill GuideXML. Just give him time.
At least for official documentation, that should not happen.
(That excludes non-doc parts of the website though imo. GuideXML is a
XML DSL designed for documentation, sadly it sucks for doing
websites.)
A wiki can fulfill several purposes for us:
[...]
However, a wiki *does* make it easier for everyone to jump right in
and edit stuff as ideas are passed around, rather than waiting for
someone to make changes to something in a devspace.
That's why we should want a wiki for general collaboration.
3. A place to host and maintain our existing documentation
[which is currently in GuideXML]
Entirely unnecessary duplication of effort. To quote the forum mods,
don't cross-post . . . and especially don't do it if you'll be
violating a doc license somewhere. It's one of the reasons why we
don't use existing unofficial wiki content in our docs. I and the GDP
have written about that ad nauseum over the years; just search the
list archives.
ack. It should /not/ be a goal of the Wiki to maintain official docs.
[...]
Show me a wiki that produces such beautiful code samples (with
titles).
[...]
. . . or a wiki that makes it super-easy to add all sorts of
additional in-line formatting to regular paragraphs, for example all
the blue highlighting for code used throughout
http://www.gentoo.org/doc/en/xml-guide.xml, or the monospace font
used for filesystem paths.
Let's be honest: Such things can be arranged. Most Wikis have a {{foo}}
- ttfoo/tt syntax already built in.
Show me a wiki that makes it easy to create tables, for example,
compare RadeonProgram from the x.org wiki:
http://www.x.org/wiki/RadeonProgram?action=edit
||-2 style=text-align: center; background-color: #66
'''Native''' ||style=text-align: center; background-color:
#66 '''R100''' ||style=text-align: center; background-color:
#66 '''R200''' ||style=text-align: center; background-color:
#66 '''R300''' ||style=text-align: center; background-color:
#66 '''R400''' ||style=text-align: center; background-color:
#66 '''RS690''' ||style=text-align: center; background-color:
#66 '''R500''' ||style=text-align: center; background-color:
#66 '''R600''' ||style=text-align: center; background-color:
#66 '''R700''' ||
. . . that's one line of cells. One. Ugly. Compare it to:
http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap5_pre1
table
tr
thFoo/th
thBar/th
/tr
tr
tiThis is an example for indentation/ti
timore stuff/ti
/tr
/table
Meep. That's an unfair one.
The guidexml snippet does not contain any styling. (Oh wait, I forgot,
it doesn't even support styling. [another reason why it sucks for
websites])
[...]
I ain't out to stop ya'll from using a wiki. I do agree that they
have some advantages. However, I will point out how limited wikis
are. They're not a magic bullet that will solve all our problems.
Again: Official docs should not be considered as Wiki material indeed.
Of course if someone feels like experimenting with such things in the
Wiki, feel free to. If the experiment should be really successful, the
GDP might reconsider.
But it's still the GDP's sandbox and as long as they're playing in it,
don't take away their toys.
Let's work *together* towards a better Gentoo, so let's consider the
official docs off-limits for the Wiki effort (at least for now) as
there are valid reasons against such a thing.
Alex
--
Alex Legler | Gentoo Security / Ruby
a...@gentoo.org | a...@jabber.ccc.de
signature.asc
Description: PGP signature
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On 04/04/2010 12:35 AM, Gilles Dartiguelongue wrote: Le samedi 03 avril 2010 à 12:50 +0300, Petteri Räty a écrit : I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? You are trying to remove a valid status for a case that has been badly managed ??? Speaking for gnome herd, afaik, all bugs marked LATER are for the simple reason they will be done later and no other status would be fine expect REJECTED maybe, but we don't want to say that to the face of the reported like this do we ? And why not just keep them open as suggested? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sun, 4 Apr 2010 10:48:52 +0200, Antoni Grzymala awa...@chopin.edu.pl wrote: Has anyone considered the immensely powerful twiki? The Webs concept of TWiki is interesting and the table editing nifty, but we would need to assess if it matches our goals. I somehow fear that it outreaches our aims a bit. -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On Sun, Apr 4, 2010 at 2:35 PM, Petteri Räty betelge...@gentoo.org wrote: On 04/04/2010 12:35 AM, Gilles Dartiguelongue wrote: You are trying to remove a valid status for a case that has been badly managed ??? Speaking for gnome herd, afaik, all bugs marked LATER are for the simple reason they will be done later and no other status would be fine expect REJECTED maybe, but we don't want to say that to the face of the reported like this do we ? And why not just keep them open as suggested? Because often there is no reason whatsoever to keep it open. People want a package to be bumped that we *know* has been released, is in the overlay (or will end up there soon), and will go into the tree with GNOME 2.30. I see no reason whatsoever to keep it open. If we start doing that, we'll end up with tons of extra bugs on our hands. We already have pages that have the status of bumped packages,[1] so we know what needs to be done. 1. http://dev.gentoo.org/~nirbheek/gnome/2.30/status.html -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sun, 04 Apr 2010 01:37:03 +0200, Sebastian Pipping sp...@gentoo.org wrote: [...] Here's another idea: The German Wikipedia uses a concept called sighted revisions. If you visit an article without logging in you will see the latest sighted revision, as an identified user you can also view the latest revision. That's an interesting idea, which we should consider. I'm not sure if that a thing to go for. Drawbacks: - More work (whereas we could use more manpower already) We need moderators, that is clear. If they check the content for correctness and remove spam they might just as well click one more checkbox to mark a stable revision. - New bottlenecks That's sorta point #1 rephrased. Couldn't we just make two big namespaces 'devs'-- Developers only 'registered' -- Full edit access to any registered user in the same wiki and have pages be in either namespace, reflecting the namespace in the page name or path somehow? In MediaWiki, that'd be the nil namespace for 'registered', i.e. http://wiki.gentoo.org/wiki/25WaysToBreakYourMachine and $whatever for 'devs': http://wiki.gentoo.org/wiki/Devs:25WaysToBreakYourMachine or http://wiki.gentoo.org/wiki/Devwiki:25WaysToBreakYourMachine For MoinMoin, I'd suggest what they call a wikicluster. users: http://wiki.gentoo.org/gentoowiki/25WaysToBreakYourMachine devs: http://wiki.gentoo.org/devwiki/25WaysToBreakYourMachine I expect that to be - easy to implement For both, yes. - providing a good mix of openness and quality control GuideXML documents are often experienced as an unnecessary barrier. I think you should clearly state again that this is not gonna replace GuideXML, just migrate a few use cases where a wiki fits better. This is what you aim for, right? ! -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On 04/04/2010 12:16 PM, Nirbheek Chauhan wrote: On Sun, Apr 4, 2010 at 2:35 PM, Petteri Räty betelge...@gentoo.org wrote: On 04/04/2010 12:35 AM, Gilles Dartiguelongue wrote: You are trying to remove a valid status for a case that has been badly managed ??? Speaking for gnome herd, afaik, all bugs marked LATER are for the simple reason they will be done later and no other status would be fine expect REJECTED maybe, but we don't want to say that to the face of the reported like this do we ? And why not just keep them open as suggested? Because often there is no reason whatsoever to keep it open. People want a package to be bumped that we *know* has been released, is in the overlay (or will end up there soon), and will go into the tree with GNOME 2.30. I see no reason whatsoever to keep it open. If we start doing that, we'll end up with tons of extra bugs on our hands. There is a valid need for having a new version in tree that users will be searching for in bugzilla. If you want to hide these bugs from your normal listings then the tools for that have been provided in this thread. Regards, Petteri We already have pages that have the status of bumped packages,[1] so we know what needs to be done. You might but not everyone searching for GNOME bugs in bugzilla knows how things are handled. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Handling of keywording bugs with only one arch
On 04/01/2010 11:28 PM, Jeroen Roovers wrote: On Sat, 27 Mar 2010 17:07:26 +0200 Petteri Räty betelge...@gentoo.org wrote: On 03/27/2010 04:51 PM, Alex Alexander wrote: The only reason I don't really like this is because it breaks consistency. We have a ground rule, assign to maintainer, CC arch(es). Why make it more complicated? I have a feeling people will continue CCing arches out of habit. +1. I don't think we should punish people for not doing it this way but consider it the preferred way when doing new bugs. The initial point here was to tell arches that assigning bugs directly to them is not wrong. Not wrong, just annoying for the arch team in question. Before resolving the bug report, you'd reassign to the maintainer and then close it? Why change it around twice, or even once for that matter? I don't think I have ever suggested this or then I have been misunderstood. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 04/04/2010 12:48 AM, Sebastian Pipping wrote: On 04/03/10 21:00, Jesus Rivero (Neurogeek) wrote: Maybe if we could find the way to make the knowledge found in quizzes be more exciting to new devs, then we could still have a strong recruitment process without the burden of completing the quizzes. So, what I propose is to transform the quizzes part of the process into a list of tasks the prospect should complete in order to gain the necessary ability to pass. This ability could be measured in points or just by task completed. Nice idea! This doesn't address them either. But I really don't think this is the main issue that causes the problem :) So I guess these questions could remain in one easy quiz. While you mention the non-technical part: I imagine a gain out of moving that part to the very end of recruiting: to when people know they almost made it. Especially putting up these questions first, turns some people away too: The problem is they get the wrong impression that being will be about these boring things later on, but it isn't. Betelgeuse, what do you think? Mentors can already suggest their students to do them in reverse order. As always patches to separate technical and organizational stuff to their own quizzes are accepted. My time on recruiting is quite maxed out already. Doing this means just not fixing the quizzes but bringing all the recruiting documentation up2date. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Is Gentoo dying?
Patrick Lauer posted on Sun, 04 Apr 2010 10:44:38 +0200 as excerpted: On 04/04/10 03:48, Joshua Saddler wrote: On Sat, 03 Apr 2010 11:16:32 +0200 Tobias Scherbaum dertobi...@gentoo.org wrote: - Our formerly outstanding documentation still is somewhat maintained, but that's it. I haven't seen any new additions (both to our docs, but also to our docs-team) for years. People are constantly asking for a documentation wiki, but ... Thanks for sh**ting on my efforts. There are lots of visible changes, and I make a point of getting the word out when a new guide turns up in /doc/. Oh yes, and I spend hours each week constantly updating docs based on the inflow of bugs, forum reports, and I constantly re-read each one and improve stuff where I can on-the-fly. See, that's the problem. *You* are doing a good job. *We* as a team/community/ant colony aren't. The visible rate of change has slowed down, and from your reply I get the feeling that there are also fewer people working on docs than in the past. So how do we improve the situation? What needs to be done so that you could disappear for a month or two without affecting progress because there are enough other motivated people sharing the workload? My long-term goal is still to make me redundant. That way I can take a break whenever I get frustrated and I can focus on new things whenever I find something new and shiny to attract my attention... Patrick's right, Nightmorph. I believe pretty much everyone here will agree that you carry a pretty heavy load, almost a super-human load for one person. But I've noticed in replies before as well as this one, you do seem to be getting burned out. Which is only to be expected given that you ARE handling docs pretty much by yourself a lot of the time. And I know you've asked for help, and didn't get it, a couple times as well. So you solder on... more and more frustrated and burnt out, but afraid to stop, because after all, all of Gentoo's depending on you, and it /does/ feel good to have users say how well things went, using the docs you've been maintaining... but you're still burning out. The same thing more or less happened to Jakob. There were similar signs of stress, but Gentoo /was/ relying on him, and all the work he did bug- wrangling. Then one day he pretty much dropped off the face of the earth... or so it seemed. It shouldn't have to be that way. You do a great job; a super-human job for one person. But you ARE just one person and unfortunately you AREN'T superhuman! It's catching up with you, and I know I'm not the only one concerned about it. It's unhealthy for both you and Gentoo. So don't take this the wrong way and drive off the folks trying to help. Maybe, just maybe, this time you'll some of the help you asked for a year or whatever it was ago. Meanwhile, some of us really /do/ appreciate all you've done to hold down the fort, so to speak. I'm sure I don't know the half of it when I say it's not been easy, and that I (and apparently others here) /do/ appreciate and recognized the almost super-human job you've been doing, unfortunately, all too often pretty much single handedly. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Is Gentoo dying?
On Sun, 4 Apr 2010 10:22:06 +0200 Tobias Scherbaum dertobi...@gentoo.org wrote: 5 years ago [...] constantly added [...] You need to clarify your metric. How are you defining constant? How often does a new document need to appear? What mostly happens is steady refinement and expansion of our existing docs, occasionally splitting off long portions into their own document, or merging a few back together where appropriate. Stuff that's written fully from scratch is much rarer than you think, and it's been that way for a long time. I'm not saying that's a bad thing; that's just how it is. Two noteworthy exceptions: 2005 and 2006. Those were years when we had all the English speaking GDP members writing. I came on board in 2005 and immediately helped crank out docs and updates, and worked with folks to get new stuff into the tree. 2005 was a good year both for the GDP and for external contributors to help write stuff and add patches, which is why we saw much more diversity in our new docs. Since then, the list of active English writers in the GDP has declined to one and it's been that way for a few years now, so that partly explains the slowdown in docs. Another is that we just aren't getting as many new submissions since the days when (apparently) we had more willing developers to pitch in with the docs. Many of the 2005/2006 guides have had their primary authors/contributors disappear, leaving us without an easy way to keep them up-to-date. The GDP can't maintain a doc if we don't have someone, internal or external, who can devote time to keeping docs up-to-date. Lots of those 2005/2006 additions need serious overhaul, or I'll have to mark 'em deprecated/draft or even remove them entirely. Some of the guides written years ago have been removed from the tree. Part of maintaining documents is not just writing new ones, but treecleaning, if you will, our existing collection. It's not as attention-getting as a totally new guide. I can't promise attention-getting news releases for every doc or website change I make. * * * Here, I'll take 2 hours to go through our complete CVS history for our docs in /doc/en/ and create a list of what was added or removed in the last 5 years. This list doesn't *begin* to include total rewrites or near-total rewrites (such as the printing, gnome, X11 guides) or whether the rewrites were made in just one day or over time as packages and methods have evolved. It doesn't cover the handbooks, nor the handbooks I wrote entirely from scratch in 2006 to cover the new GLI installers (and their subsequent removal after 2008's releases). It also does not include documents that have since been marked draft or deprecated or some other maintainance status besides active. I expect some of the docs on this list to still be in draft or to have moved to it or deprecated, so whether they really count is up to you to decide. If you want to average docs on a monthly or yearly basis . . . you can tweak the numbers all you want. Note, also, that just because you don't see a doc on it in the last 5 years doesn't mean we don't already have a wealth of published info on a subject in our existing documentation. Something that was added in, say, 2002 or 2004 is prolly very complete, and covers lots of stuff you'd normally find in separate articles elsewhere, for example on wikis. I'm not putting much here besides the files added/removed. This is just stuff that's initially added to or removed from CVS. *2010* Nothing totally new added nor anything completely removed. Hey, the year is young. Lots of rewrites though. *2009* Same. Mostly extensive rewrites, most notably the handbooks to take into account the autobuilds. New: bind-guide.xml New: lxde-howto.xml New: openbox.xml Removed: ldapdns-guide.xml (added 2006) Removed: gentoo-sparc-quickinstall.xml (added 2004) *2008* New: multipath.xml New: nagios-guide.xml (draft) New: openrc-migration.xml Removed: apache-developer.xml (added 2005) Removed: apache-troubleshooting.xml (added 2005) Removed: apache-upgrading.xml (added 2005) Removed: kde-config.xml (added 2004) Removed: kde-split-ebuilds (added 2005) *2007* New: gcc-optimization.xml New: pda-guide.xml (draft) New: vpnc-howto.xml New: xen-guide.xml New: xfce-config.xml Removed: colinux-howto.xml (added 2004) Removed: mysql-upgrade-slotted (added 2006, but mysql team reverted SLOTting) Removed: nx-guide.xml (added 2004) Removed: openmosix-howto.xml (added 2003) *2006* New: change-chost.xml New: conky-howto.xml New: cross-compiling-distcc.xml New: gentoo-alpha-faq.xml New: gentoo-x86+raid+lvm2-quickinstall.xml New: info-guide.xml New: jffnms.xml New: kernel-config.xml New: ldapdns-guide.xml (removed 2009) New: liveusb.xml New: man-guide.xml New: portage-utils.xml New: postgres-howto.xml New: vdr-guide.xml New: zsh.xml Removed: java-old.xml (added 2006) Removed: vserver-howto.xml (added 2005) *2005* New: apache-developer.xml (removed 2008)
Re: [gentoo-dev] Re: Is Gentoo dying?
If you want to gauge the feeling in the community there are a couple of threads in the forums. Currently this answer seems to be typical of the general consensus when asked what they could do to help Gentoo/become a developer: http://forums.gentoo.org/viewtopic-p-6230439.html#6230439
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 04/04/10 08:31, Joshua Saddler wrote: lots of stuff about what mediawiki supposedly can't do that is just completely untrue GuideXML may be better for the Handbook use case, with its ability to produce single page and multipage documents, but frankly I think that for the rest of the documentation, most of which only covers 1 or 2 pages, the ease of learning and editing mediawiki formats is far superior. (I wouldn't be surprised if there's a way to reproduce this single-page and multipage ability using inclusion on mediawiki) I keep hearing this line about GuideXML not being hard to learn, but if that's so true, why does Gentoo have so few developers contributing to the documentation? Why does the current system basically rely on a single developer tidying up and completing the documentation? I've tried getting my head around GuideXML a few times and I hate dealing with it. I much prefer to use the Gentoo Wiki, where I can just throw stuff up really quickly using a syntax I use in many other places and is well documented. This line about learning wiki syntax is so old, but here's my reply yet again: GuideXML is a non-tranferrable skill. Nowhere else in the entire world uses it. Even if you haven't edited a wiki anywhere else, chances are you probably will one day, and even if it's not mediawiki it'll probably use syntax that's similar to it in many ways. Syntax highlighting can easily be done with any of a number of plugins. I'm sure ebuild syntax could be added without a massive amount of pain. There are multiple ways to construct tables (wiki style, HTML and probably some others - almost certainly more available via plugins), some easier than others. And you can do styling either inline or in the site-wide stylesheets. Mediawiki has built-in intradoc linking to every heading, and in all the use cases I've seen this level is fine. Intradoc linking to individual letters^Wparas is just frankly way overboard (Does the Gentoo documentation even use it anywhere?). Wiki's may not be a magic bullet that'll solve all of Gentoo's problems, but the current system doesn't seem to be working well, so something needs to change, and I believe that a system that allows more people to contribute more easily, using a syntax that's already widely used so is either already known or an easily transferable skill is not a bad place to start. AllenJB
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 4 April 2010 10:47, Sebastian Pipping sp...@gentoo.org wrote: On 04/04/10 10:29, Arun Raghavan wrote: We _should_ have a wiki for easy note-taking, maintaining todo lists, possibly even meeting minutes I suppose this^^^ is both a good solution and compromise, both to wiki-fans and the doc team. Ben, could you live with that? As I said, the most important thing for me is to have a wiki that will allow developers to quickly whip up pages like Arun is describing here. For example the GSoC ideas page. If that is all we ever do with it, then it is worth having, and I can certainly live with that. This specific need is why I'm making the effort now to get this done. But I am not hiding the fact that I would also like it to serve a wider purpose. But that is a separate discussion. We want the wiki anyway, independently from whether the GDP wants to use it or not. At this point they don't, so GDP-maintained documentation is not included in the scope of the wiki. I do hope that will change in the future. But I can live with it if it doesn't. Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 4 April 2010 10:48, Antoni Grzymala awa...@chopin.edu.pl wrote: Has anyone considered the immensely powerful twiki? No. So tell us why we should. Specifically, how does it compare to MediaWiki in terms of features and performance? Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
RE: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Show me a wiki that produces such beautiful code samples (with titles). Show me a wiki that can produce the following formatting for ebuilds: http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap2_sect7 . . . or a wiki that makes it super-easy to add all sorts of additional in-line formatting to regular paragraphs, for example all the blue highlighting for code used throughout http://www.gentoo.org/doc/en/xml-guide.xml, or the monospace font used for filesystem paths. Show me a wiki that makes it easy to create tables, for example, compare RadeonProgram from the x.org wiki: http://www.x.org/wiki/RadeonProgram?action=edit ||-2 style=text-align: center; background-color: #66 '''Native''' ||style=text-align: center; background-color: #66 '''R100''' ||style=text-align: center; background-color: #66 '''R200''' ||style=text-align: center; background-color: #66 '''R300''' ||style=text-align: center; background-color: #66 '''R400''' ||style=text-align: center; background-color: #66 '''RS690''' ||style=text-align: center; background-color: #66 '''R500''' ||style=text-align: center; background-color: #66 '''R600''' ||style=text-align: center; background-color: #66 '''R700''' || . . . that's one line of cells. One. Ugly. Compare it to: http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap5_pre1 For the record, mediawiki support CSS with the utilization of wiki modeles, so you can do almost anything that you want : http://gentoo-quebec.org/wiki/index.php/Guide_installation_configuration_syst%C3%A8me_de_base Tables, code box etc... My friend Guy coded a lot of wiki modeles and I can almost do anything I want if he coded what I wanted. _ Live connected. Get Hotmail Messenger on your phone. http://go.microsoft.com/?linkid=9724462
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sun, Apr 4, 2010 at 10:31, Joshua Saddler nightmo...@gentoo.org wrote: No, he's definitely out to kill GuideXML. Just give him time. Why the antagonism? Ben isn't out to kill anything, he has no personal vendetta against anything. Actually, nothing here is personal, but you seem offended by some of the things which are being said, and you really shouldn't. A wiki can fulfill several purposes for us: 1. Easy collaboration among devs, for brainstorming, developing new documentation, assembling upcoming meeting agendas, and so on [for which there currently is not really any obvious place] This is not *impossible* with our current setup; it can still be done in a few different ways: 1) project spaces in /proj/$LANG/foobar/ -- how hard is it to commit to CVS when going through document drafts? 2) devspaces -- it's easy enough to dump stuff in here for others to refer to However, a wiki *does* make it easier for everyone to jump right in and edit stuff as ideas are passed around, rather than waiting for someone to make changes to something in a devspace. That's exactly what we're looking for. That's what makes a wiki useful in the first place. 3. A place to host and maintain our existing documentation [which is currently in GuideXML] Entirely unnecessary duplication of effort. To quote the forum mods, don't cross-post . . . and especially don't do it if you'll be violating a doc license somewhere. It's one of the reasons why we don't use existing unofficial wiki content in our docs. I and the GDP have written about that ad nauseum over the years; just search the list archives. I am not pushing for our existing documentation to be migrated into a wiki at this point. But I think that once the place is there, and it functions well, it would be the obvious next step to do so. As I said before, the barrier to contributing and maintaining documentation is much higher in the case of GuideXML, so it doesn't really make sense to keep that around when we have a better solution. I know there are people who do not agree with me on this last point . . . to say the least. [snip] I ain't out to stop ya'll from using a wiki. I do agree that they have some advantages. However, I will point out how limited wikis are. They're not a magic bullet that will solve all our problems. Why would you want to stop us? Have you been to gentoo-wiki.com? There are a lot of *very* useful articles there. With all due respect to the doc team (and I have tremendous respect for them and the splendid documentation they have written for Gentoo), they're limited by manpower, by time, and by scope. They simply can't cover all the things that are interesting and useful for our users. Some examples which can never be covered by the official documentation: 1. Most of the stuff that's on the Documentation, Tips Tricks forum. And all the stuff that's already there can not be updated or changed, and cannot even be found easily, so it's just rotting there. 2. All hardware specific information that's extremely useful to users (information for Macs, all kinds of laptops, netbooks, how to update your BIOS, etc.) 3. HOWTO's and guides for *a lot* of the software on the tree (many kinds of mail servers available, HTTP servers, databases, spam filters, alternative init systems, boot loaders, experimental drivers, etc.). Some of those are covered by official documentation, by it can never cover it all. And I could go on (please do not argue about a specific point where I may not be accurate, that's not the point). Our users want this kind of information available, they want to share the information they learned, they want to improve guides written by other people, build upon work done by others. Gentoo can earn so much from a system that will allow this. Our users want to help us and each other, let's help them to that. Furthermore, when an article on the wiki reaches maturity, it can be included in our official documentation. Stuff can move around between official documentation and wiki. Out of date official documentation can be moved to the wiki where it can be improved instead of rotting. Both can coexist and feed each other, providing more answers overall. A wiki is not a new concept. Users know what they're getting from a wiki. They know it's not official, know it was written by other users, know that not all information is necessarily accurate, up-to-date or relevant. But you can't ignore how useful a wiki is, what new heights we can reach with it. At first, I'd wish for things to be migrated from the unofficial wiki (if the license does not allow for copying, then re-writing it. Our users will do a lot of it, I'm sure). I'd wish to migrate a lot of things from the forums, after getting the authors permission if necessary. Maybe at some point I'd like the devmanual to be moved to the wiki (probably only editable by devs or a certain team, the specifics are not important right now). The
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 04/04/10 15:15, Dror Levin wrote: At first, I'd wish for things to be migrated from the unofficial wiki (if the license does not allow for copying, then re-writing it. Our users will do a lot of it, I'm sure). I'd wish to migrate a lot of things from the forums, after getting the authors permission if necessary. Maybe at some point I'd like the devmanual to be moved to the wiki (probably only editable by devs or a certain team, the specifics are not important right now). The quizzes can be put on the wiki. GLEP summaries in language users understand. Drafts for news items. The list goes on and on. Dror Levin I'd like to ask what you think in launching a site that simply clones an existing site is? Why take all the hard work the editors have put into their articles on the unofficial wiki and duplicate them on another site, creating TWO copies, both of which may be updated with different information. This is completely pointless. And as someone who has contributed a lot to the existing wiki, I don't care if it's official or not, but any site I find copying articles I've contributed to (and certainly the ones I wrote from scratch) will suffer all the wrath and abuse I can bring to it. An official wiki should not be used to duplicate the existing unofficial wiki (and I don't believe this is the intent of the developers who want one). It should be used to provide additional documentation on top of that provided by the existing wiki. AllenJB
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sun, Apr 4, 2010 at 17:33, AllenJB gentoo-li...@allenjb.me.uk wrote: I'd like to ask what you think in launching a site that simply clones an existing site is? Why take all the hard work the editors have put into their articles on the unofficial wiki and duplicate them on another site, creating TWO copies, both of which may be updated with different information. This is completely pointless. And as someone who has contributed a lot to the existing wiki, I don't care if it's official or not, but any site I find copying articles I've contributed to (and certainly the ones I wrote from scratch) will suffer all the wrath and abuse I can bring to it. That's a shame, but as I said, if the license permits it then we'll move the content, if it doesn't then we won't. An official wiki should not be used to duplicate the existing unofficial wiki (and I don't believe this is the intent of the developers who want one). It should be used to provide additional documentation on top of that provided by the existing wiki. Creating just another wiki is what's pointless. What I want is to deprecate all unofficial wikis (there are others besides gentoo-wiki.com) which were created simply because there never was an official one and creating chaos, then centralize everything in one official wiki, and build on top of that. Fix the historic mistake. Concentrating information from the forums and various wikis is just the first step. This should be the goal of all of us, yours as well. Who wants to run around all over the internet trying to find relevant information on various forums, wikis, blogs, etc. when an official wiki can remedy a big part of that, making it easier to find what you're searching for. Instead of being scattered around, we want everything in one place, that's how it can be made even better. Dror Levin
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 04/04/10 15:47, Dror Levin wrote: Creating just another wiki is what's pointless. What I want is to deprecate all unofficial wikis (there are others besides gentoo-wiki.com) which were created simply because there never was an official one and creating chaos, then centralize everything in one official wiki, and build on top of that. Fix the historic mistake. Concentrating information from the forums and various wikis is just the first step. This should be the goal of all of us, yours as well. Who wants to run around all over the internet trying to find relevant information on various forums, wikis, blogs, etc. when an official wiki can remedy a big part of that, making it easier to find what you're searching for. Instead of being scattered around, we want everything in one place, that's how it can be made even better. Dror Levin The unofficial wiki may have been created because there wasn't an official one, but that doesn't mean it's any less of a community in its own right. Starting the official wiki by effectively ripping off others work and attempting to destroy existing user communities is NOT the right way to go about things, in my opinion (and losing the editing history of those articles in the process). You should first try to start your wiki/community and make it a community in its own right, rather than trying to steal/destroy/rip off existing communities. My personal goal is to continue to maintain an existing community full of useful documentation, already concentrated in one place. The unofficial wiki avoids duplication by pointing to existing documentation where ever possible. The search problem is already dealt with by Google, so that's no reason to go about ripping off other peoples work. With your aims in mind, I don't see the point in duplicating existing material, creating TWO places you have to check to see what's been updated. If an official wiki starts up and becomes a major documentation centre for user contributions, then I may consider moving my articles over, but until that time I currently intend to maintain them in place, with their complete history in tact. AllenJB
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
Sebastian Pipping wrote: On 04/03/10 21:00, Jesus Rivero (Neurogeek) wrote: Maybe if we could find the way to make the knowledge found in quizzes be more exciting to new devs, then we could still have a strong recruitment process without the burden of completing the quizzes. So, what I propose is to transform the quizzes part of the process into a list of tasks the prospect should complete in order to gain the necessary ability to pass. This ability could be measured in points or just by task completed. Nice idea! I am a dev in training. My mentors are now looking over my end quiz. I am also an IT professor and teach software engineering. The learning process was somewhat lacking in that I found myself often just searching for answers rather than performing some exercise. It would help if we had exercises where the prospective dev is guided through writing some ebuild and then commits it to some play overlay. He/she can do this over and over until the ebuild works, and then answers quiz questions. I effectively did this - I wrote some helloworld-xxx.tgz tarballs with various issues and then wrote ebuilds to build/install the package, committed them to a git overlay I set up, etc. Also, when I asnwered the quiz questions, I documented the references where I found the answers and I documented a link to my ebuilds on my git repo. The learning flow should go something like this: 1) Read this documentation, eg. http://devmanual.gentoo.org/ section on Eclass Writing and Tool References 2) Write an ebuild/eclass to do something, with skeleton howto steps, eg. name transformation like versionator (don't worry if its already been done) 3) Commit to the play overlay 4) Test the ebuild/eclass 5) Answer ebuild questions 6) Go back to step 1 and address the next issue. -- Anthony G. Basile, Ph.D. Chair of Information Technology D'Youville College Buffalo, NY 14201 USA (716) 829-8197 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 4 April 2010 09:31, Joshua Saddler nightmo...@gentoo.org wrote: On Sun, 4 Apr 2010 03:20:53 +0200 Ben de Groot yng...@gentoo.org wrote: GuideXML documents are often experienced as an unnecessary barrier. I think you should clearly state again that this is not gonna replace GuideXML, just migrate a few use cases where a wiki fits better. This is what you aim for, right? No, he's definitely out to kill GuideXML. Just give him time. Let me start by saying I immensely value the work you do, even tho we disagree on the merits of GuideXML. The GDP is an essential part of what makes Gentoo great, and I am willing to work with you to ensure that our documentation keeps the quality it is known for, and improve it where possible. Even if that means working with an (in my eyes) inferior technical solution. That said, I still hope I can convince you that working with a wiki has benefits over GuideXML and gorg. Some day. A man can hope... A wiki can fulfill several purposes for us: 1. Easy collaboration among devs, for brainstorming, developing new documentation, assembling upcoming meeting agendas, and so on [for which there currently is not really any obvious place] This is not *impossible* with our current setup; it can still be done in a few different ways: 1) project spaces in /proj/$LANG/foobar/ -- how hard is it to commit to CVS when going through document drafts? 2) devspaces -- it's easy enough to dump stuff in here for others to refer to However, a wiki *does* make it easier for everyone to jump right in and edit stuff as ideas are passed around, rather than waiting for someone to make changes to something in a devspace. Nobody said it is impossible. It's just not very practical. And the fact that a growing number of official Gentoo projects are now using external wikis is an indication that we need to provide this ourselves. 3. A place to host and maintain our existing documentation [which is currently in GuideXML] Entirely unnecessary duplication of effort. To quote the forum mods, don't cross-post . . . and especially don't do it if you'll be violating a doc license somewhere. It's one of the reasons why we don't use existing unofficial wiki content in our docs. I and the GDP have written about that ad nauseum over the years; just search the list archives. Obviously we should not do anything that violates licenses, and I don't see anyone promoting that. As far as I can see there is agreement on using the CC-BY-SA license that is used in most of our documentation. This means we can't copy-paste content from the unofficial wiki. But in principle we could move existing official documentation into the wiki. Of course we would prefer to minimize duplication of effort. But having all (or at least most) of our documentation in one place has obvious benefits. So I hope I can convince the GDP to join us. I am not pushing for our existing documentation to be migrated into a wiki at this point. But I think that once the place is there, and it functions well, it would be the obvious next step to do so. As I said before, the barrier to contributing and maintaining documentation is much higher in the case of GuideXML, so it doesn't really make sense to keep that around when we have a better solution. I know there are people who do not agree with me on this last point . . . to say the least. Show me a wiki that has the flexibility of our handbook, which can be a huge printer-friendly all-in-one doc, or an as-you-need-it doc with one page per chapter. As far as I know, we only use this functionality for our handbook. But MediaWiki can do that with what they call transclusion. Show me a wiki that [does a number of things] MediaWiki (like any major wiki) can do all those things. You are basically showing your ignorance of wikis. Your arguments against wikis seem to be based on your false impressions of them, not on actual facts. As has been pointed out, your table example was unfair, as they don't do the same thing. I would frown on such inline styling (that's what stylesheets are for), and there are a number of ways you can markup tables in wikis. One is to allow HTML tags, so it would be very much like GuideXML. Another one, which I prefer personally, is to use reStructuredText, which is even clearer than HTML markup. By moving to a wiki, you'll lose a huge percentage of what GuideXML can do, I don't see that at all. Is there any essential feature of GuideXML that is missing in MediaWiki? (Let's take that wiki implementation as the most likely one we will adopt.) I haven't seen anything yet that is impossible or very difficult to do. Do you really think that GuideXML is so special and advanced that nobody else had the same needs and that major wiki engines do not provide in those needs? in exchange for quicker and easier editing and creation of docs, though neither of these have been qualified. As some others on this list have
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
Am Samstag, den 03.04.2010, 23:05 +0200 schrieb Maciej Mrozowski: On Saturday 03 of April 2010 14:16:14 Fabian Groffen wrote: Shouldn't we fix that buildsystem then? Do you have an example of a package/buildsystem that does that? We already do, the thing is that maybe we don't have to. https://bugs.gentoo.org/show_bug.cgi?id=240323 From top of my head: python having issues with sys-libs/db as well as some packages with readline. It would indeed. Now when I think about it, moving stuff to preserved library dir could be just done - provided it's possible - along with fixing/setting DT_RPATH's in reverse runtime dependencies. This way no system-wide LIBRARY_PATH's would be necessary. Is it possible? Mike? No, unless you somehow make sure you reserve space for this, by e.g. setting a bogus rpath entry at buildtime. If you want to go that route, you probably want to look at the Prefix' binutils-config wrapper that already calls the linker with added rpath arguments. Afterwards you can use chrpath to set it to the correct location. Will get messy with the vdb though, but if Portage's doing it, it can probably be dealt with. Sounds messy indeed, what about hardened/SELinux/AppArmor/whatever - do they allow such DT_RPATH operations? It should be probably also restricted for binary-only packages. On Saturday 03 of April 2010 20:51:43 Tiziano Müller wrote: Don't fix the hack. Remove the preserve libs feature, make the PMs check for rdeps per default before unmerging things. This will only prevent creating orphans of uninstalled libraries, what about upgraded ones when SOVERSION has been bumped (the most common case)? I addressed this in the next phrase. Besides I can already imagine PMS-related discussion regarding make the PMs check for rdeps per default before unmerging things - thx but no thx. This is not related to PMS. Paludis for example does it already with the current EAPIs. Slot libraries where needed, slot dep operators (EAPI 4) will help. Again, you suggest to SLOT every library that happened to bump SOVERSION. It's unrealistic. Besides library should be slotted when it's API changes, for source based distributions it's not needed for ABI changes - let's not confuse those two. Also excessive slotting increases probability of breaking library discovery mechanisms in various build systems (not everyone uses pkg-config). I know that slotting can cause problems. But forcing build systems to use specific versions of libraries is much easier than shadowing libraries present in library search dirs, especially when those libs are not even tracked by the PM. And if that doesn't work out we need a separate var to give the PM a hint when API/ABI breakages happen (such that the PM knows when to re-install the rev deps). It needs PMS amended and thus GLEP. Wrong, we don't have GLEPs for 90% of the PMS changes going into EAPI-3 or 4. Please submit a GLEP item for this if you see it fit. Anyway, as explained in OT, it's not a problem of package manager dependencies system but issue with broken/not smart build systems - no dependency tree magic will solve this issue. It is a problem which can _only_ be solved at the PM level. You have to tell the PM when API breakages happen. Either by slotting the lib or by something else. Using guesswork to determine whether or not a library should be removed may be a temporary solution. Remember: you're partially ignoring a users request since he wanted the package to be removed - and we all know how things like protect the user from himself end up. -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Hm. Can you all just talk to the admin of gentoo-wiki and make it official?
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 4 April 2010 17:36, dev-ran...@mail.ru wrote: Hm. Can you all just talk to the admin of gentoo-wiki and make it official? Been there, done that. He's not interested. -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 4 April 2010 16:33, AllenJB gentoo-li...@allenjb.me.uk wrote: I'd like to ask what you think in launching a site that simply clones an existing site is? Why take all the hard work the editors have put into their articles on the unofficial wiki and duplicate them on another site, creating TWO copies, both of which may be updated with different information. Starting a wiki under the Gentoo umbrella is not about duplicating effort. It is about providing services that we currently don't and for which there is an apparent need. First and foremost it is about providing developers a place for easy (collaborative) editing of documents, so they wouldn't have to resort to either less practical solutions within gentoo.org, or external resources not under gentoo.org. Secondly, this would be a good place to centralize efforts by both users and developers to collaborate on generating, consolidating and maintaining documentation. Currently these are scattered over a number of places, as Dror has mentioned. We do not want to duplicate effort, but work together to bring the various efforts as much as possible into one place, a one-stop shop for all good and relevant information about Gentoo. any site I find copying articles I've contributed to (and certainly the ones I wrote from scratch) will suffer all the wrath and abuse I can bring to it. Then you shouldn't contribute to a wiki that has a license that allows just that. An official wiki should not be used to duplicate the existing unofficial wiki (and I don't believe this is the intent of the developers who want one). Not duplicate, but centralize and facilitate more collaboration. And give it more recognition and better quality control. And host it on the number one community site we have: gentoo.org, with all the infrastructure support that entails. Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 4 April 2010 17:13, AllenJB gentoo-li...@allenjb.me.uk wrote: The unofficial wiki may have been created because there wasn't an official one, but that doesn't mean it's any less of a community in its own right. And that doesn't mean that community wouldn't be interested to work on a new, official wiki that concentrates efforts into one place, under the umbrella of the wider Gentoo community. Starting the official wiki by effectively ripping off others work and attempting to destroy existing user communities is NOT the right way to go about things Nobody is talking about ripping off and destroying, but you. There is no need for such dramatic language. If an official wiki starts up and becomes a major documentation centre for user contributions, That is the intent, and we hope you will work with us to make that happen. Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 4 April 2010 11:43, Petteri Räty betelge...@gentoo.org wrote: Mentors can already suggest their students to do them in reverse order. As always patches to separate technical and organizational stuff to their own quizzes are accepted. My time on recruiting is quite maxed out already. Doing this means just not fixing the quizzes but bringing all the recruiting documentation up2date. We do realize that recruiters are already stretched to their limits. So I propose a few other people form a team to design an improved recruitment process, including any curriculum and documentation materials needed. Obviously this team would confer with recruiters and incorporate their feedback into its work. -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Ben de Groot dixit (2010-04-04, 14:31): On 4 April 2010 10:48, Antoni Grzymala awa...@chopin.edu.pl wrote: Has anyone considered the immensely powerful twiki? No. So tell us why we should. Specifically, how does it compare to MediaWiki in terms of features and performance? I don't have any particular claims on performance at hand. TWiki stores the data in plaintext files which may or may not be beneficial depending on various scenarios, the code is very mature but that of course does not say anything on whether the performance is good or not compared to, say, MediaWiki. Here [1] is a reasonably recent writeup on TWiki's performance. As to the features, I (contrary to sebastian in an earlier answer) quite like the syntax, I think it's a bit more comfortable the MediaWiki in popular scenarios. There's a good ACL system, it's got an integrated ticket system, a mobile-version plugin, and I too think the whole concept of Webs is neat. The search system is extensive and includes regex searching. And yeah, it's not PHP :) (no flame intended™) [1] http://www.twiki.net/blog_2008-03-25.html -- [a]
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
Am Samstag 03 April 2010 12:27:38 schrieb Krzysztof Pawlik: Sounds good, can we at the same time get RESOLVED OBSOLETE (for bugs that are not valid anymore due to changed situation, RESOLVED INVALID isn't applicable in this case as it implies the bug is and was invalid from the begining). +1 for OBSOLETE, that would give a clear response to outdated stable requests etc... -- Dr. Andreas K. Huettel Institute for Experimental and Applied Physics University of Regensburg D-93040 Regensburg Germany tel. +49 151 241 67748 (mobile) e-mail m...@akhuettel.de http://www.akhuettel.de/research/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Is Gentoo a Phoenix?
On Sat, Apr 3, 2010 at 5:33 AM, Richard Freeman ri...@gentoo.org wrote: I think the problem is that our recruitment process uses the ability to answer complex technical and organizational questions as a way to assess maturity. I think that maturity is far more important than technical skill in a distro - a mature person will recognize their own limitations and exercise due diligence when stepping outside of them. Instead of playing 20 questions and going back and forth with recruits, maybe a better approach would be to cut down the questions dramatically (or more clearly put their answers in the documentation), and then use other approaches like references and interviews. A new recruit might be given the names of 5 devs that they will need to interview with for 30-60 minutes by phone or IRC (preference on phone), and they will need to submit references, who will be contacted. When we hire people at work we don't play trivial pursuit with them, we use an interview to get a feel for what they're like and how they handle situations, and we screen resumes and references to determine experience. I'm sure any of the professional linux distros would work in the same way, but perhaps somebody should ask around and see how it is done elsewhere. All ideas regarding improving recruitment are welcome, thanks. However if, during your review, you were not given the impression that your maturity and other social skills were being assessed then you were being blissfully naive. :o) I use tricks like pretending I don't understand that crystal-clear thing you're explaining to gauge your patience and politeness, I drift off to real-life topics to find out who the recruit really is, and lots of others like background searches (also outside of gentoo) and talks with the mentor. On the other hand, in your particular case, I clearly remember the assessment was easy and thus I didn't insist too much. Which is what probably made it more difficult for you to notice. Denis.
Re: [gentoo-dev] Is Gentoo a Phoenix?
esOn Sat, Apr 03, 2010 at 07:33:53AM -0400, Richard Freeman wrote: On 04/03/2010 06:19 AM, Tobias Scherbaum wrote: I really think that the Gentoo recruitment process needs improvement. Right now it seems like a LOT of effort is required both to become a Gentoo dev and to help somebody become a Gentoo dev. That means we have great people, but not many of them. I think the problem is that our recruitment process uses the ability to answer complex technical and organizational questions as a way to assess maturity. I think that maturity is far more important than technical skill in a distro - a mature person will recognize their own limitations and exercise due diligence when stepping outside of them. Instead of playing 20 questions and going back and forth with recruits, maybe a better approach would be to cut down the questions dramatically (or more clearly put their answers in the documentation), and then use other approaches like references and interviews. A new recruit might be given the names of 5 devs that they will need to interview with for 30-60 minutes by phone or IRC (preference on phone), and they will need to submit references, who will be contacted. When we hire people at work we don't play trivial pursuit with them, we use an interview to get a feel for what they're like and how they handle situations, and we screen resumes and references to determine experience. I'm sure any of the professional linux distros would work in the same way, but perhaps somebody should ask around and see how it is done elsewhere. I'm not exactly sure how you'd want the references to work, I mean, as in prior jobs/projects worked on? I know that I'd like to help out with development, but as it stands I don't think I have the necessary skills (various programming language etc), so that is something I'm working on. As a consequence I naturally don't have any references (and might not by the time I feel ready) but that wouldn't necessarily mean that I'm not qualified to be working as a dev. Also one could imagine that a number of other people without references, but the necessary qualifications might think To hell with this, I'll just put my effots somewhere else. Another thing, you write that phone is preferred but I know that I act relaxed in text with new people and as myself. Whereas on the phone I hold back a bit, and don't really act myself. So perhaps the preference should be the manner in which the one being interviewed is more comfortable with and will act more naturally. Anyway these are just my 2 cents. -- Zeerak Waseem pgp95WvDeen2m.pgp Description: PGP signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sun, 4 Apr 2010 17:23:54 +0200
Ben de Groot yng...@gentoo.org wrote:
As has been pointed out, your table example was unfair, as they don't
do the same thing. I would frown on such inline styling (that's what
stylesheets are for), and there are a number of ways you can markup
tables in wikis. One is to allow HTML tags, so it would be very much
like GuideXML. Another one, which I prefer personally, is to use
reStructuredText, which is even clearer than HTML markup.
Having to write a custom stylesheet just to get one wiki page to do what you
want is pretty dumb.
How is it unfair? Because tables really are so much simpler to write in
GuideXML? Here's a more complicated table:
http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap2_sect10
source: http://www.gentoo.org/doc/en/xml-guide.xml?passthru=1
By moving to a wiki, you'll lose a huge percentage of what GuideXML can do,
I don't see that at all. Is there any essential feature of GuideXML
that is missing in MediaWiki? (Let's take that wiki implementation as
the most likely one we will adopt.) I haven't seen anything yet that
is impossible or very difficult to do. Do you really think that
GuideXML is so special and advanced that nobody else had the same
needs and that major wiki engines do not provide in those needs?
Mediawiki mostly involves memorizing how many quote or tick marks you use. This
markup is *completely nonsemantic*. In GuideXML, you know EXACTLY what each tag
means. It's semantic. ul starts an unordered list. ol starts an ordered
list. li is a list item. b for bold text. e for emphasized text, similar
to XHTML's em tag. table to start a table.
Mediawiki requires you to memorize numbers of marks to achieve the same effect:
two ' ' for italic text, three ' ' ' for bold, five ' ' ' ' ' for bold AND
italic.
Now take a look at the section on Mediawiki lists: whitespace becomes part of
your formatting. Lame. At least with GuideXML, you can use whatever whitespace
or linebreaks you want to keep code human-readable, and know that it won't
affect the rendered version.
Oh, *and* you have to prefix Mediawiki list items with ; and : , which is
completely nonsensical and arbitrary. The character doesn't explain what it's
for, unlike semantic XML tags.
Take a good look at the Mediawiki mixture of lists sample:
(I'd provide a direct link, but there's no built-in way to snap to it)
http://www.mediawiki.org/wiki/Help:Formatting
That is just plain ugly. The eye has a hard time unjumbling the ##s and ;:*
crammed together. Also, note another flaw of Mediawiki:
At any time, you can throw in HTML and CSS to do stuff, because apparently
Mediawiki isn't flexible enough on its own to generate your desired rendering.
Having to mix HTML with a totally different wiki syntax is stupid. Having to
learn CSS *on top* of learning wiki syntax (and HTML) just to write a document
is retarded.
You've tried to make the case that learning GuideXML is too hard, but in order
to use Mediawiki you'd need to learn at least 3 languages.
In my earlier email, I shared a code sample of GuideXML tabls. Mediawiki's idea
of tables?
{| to start. |+ for a caption. |- for a row. ! for headers, and | for data. Use
more || symbols for more rows.
Seriously, what part of this is easily understood to be table markup?
*And* you can mash in XHTML attributes to style the text. Big no-no. Leave the
styling to a separate stylesheet, and let the code just be code.
Yeah, since Mediawiki tables can accept straight-up CSS (another skill you had
all better learn if you're going to write valid code, apparently), you *can* do
a bit more color formatting than with our existing XSL rules for GuideXML. I'll
grant you that.
But that's at the price of standardization: since arbitrary tags and markup is
allowed, there's nothing to keep consistency between documents, or even within
the same document. GuideXML at least has a clean, consistent visual
representation. Once you start allowing arbitrary markup, there'll be a million
and one ways of representing the same thing, and that's not good for someone
trying to wade through documents. There *should* be a standard way of
representing information.
And if you really wanted to, you could easily write an extension to
parse GuideXML, so it could be used as wiki markup. So again, the
markup is not really an argument against using a wiki instead of our
current GuideXML+gorg setup.
Except I haven't seen Mediawiki offer anything like our textual color palette
or other code syntax and block-level formatting flexibility.
2. It is a non-transferable skill. You can't use it anywhere else.
And unless you are a regular GuideXML writer, you will have to
look up its particular usage almost every time you do use it.
It's just XML. That's all. If you can write HTML, then you can write XML. XML
is *easier*. It's got far fewer tags, for starters. That means much, much less
to learn.
Oh, and guess what?
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 04/04/2010 20:33, Joshua Saddler wrote: On Sun, 4 Apr 2010 17:23:54 +0200 Ben de Grootyng...@gentoo.org wrote: ... ... GuideXML is only easy if you are used to xml or html. Wikimarkup is only easy if you are used to it as well. The difference is that with mediawiki all you have to do is press a button to get your italics, headers, lists and whatever else - making the chance having documentation written a lot higher.
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sun, Apr 04, 2010 at 04:13:19PM +0100, AllenJB wrote: The unofficial wiki may have been created because there wasn't an official one, but that doesn't mean it's any less of a community in its own right. Starting the official wiki by effectively ripping off others work and attempting to destroy existing user communities is NOT the right way to go about things, in my opinion (and losing the editing history of those articles in the process). You should first try to start your wiki/community and make it a community in its own right, rather than trying to steal/destroy/rip off existing communities. My personal goal is to continue to maintain an existing community full of useful documentation, already concentrated in one place. The unofficial wiki avoids duplication by pointing to existing documentation where ever possible. The search problem is already dealt with by Google, so that's no reason to go about ripping off other peoples work. With your aims in mind, I don't see the point in duplicating existing material, creating TWO places you have to check to see what's been updated. If an official wiki starts up and becomes a major documentation centre for user contributions, then I may consider moving my articles over, but until that time I currently intend to maintain them in place, with their complete history in tact. AllenJB You're absolutely right, it is a seperate community, and reading your replies I can't help but think Is the url really that important?. After all regardless of where the articles that you've written, you still would be the writer. You could still take part in the various discussions that may arise on the articles. The way I see it is that when the official wiki comes up, it will only be a question of time before the pages covered in the unofficial wiki are covered in the official one, particularly if it'll be mainly user-driven and people stop thinking about using the unofficial wiki, as there is a wiki and the answer isn't there. So when they find the answer, they add it. Personally I'd prefer to be part of the change rather than resisting it. I can understand reluctance to join a project you aren't certain will succeed, though. As another note, the license of gentoo-wiki doesn't stop anyone from copying but is incompatible with the license on the docs (was mentioned in a thread recently) so what is in gentoo-wiki won't be copied, but at best/worst rewritten. As an endnote, none of the above is meant as provocative or offensive, so in case it does offend; you have my apologies (it seems like a touchy subject for you so I thought I'd make it clear :-) ) -- Zeerak Waseem pgppEtO006ig3.pgp Description: PGP signature
Re: [gentoo-dev] Is Gentoo dying?
On 2010.04.03 15:59, Tobias Scherbaum wrote: Am Samstag, den 03.04.2010, 15:40 +0100 schrieb Roy Bamford: First, we need some metrics - the first step to controlling anything is to measure it. So, how do you want to measure those metrics? I for one can't think of a useful algorithm which helps to identify understaffed or orphaned areas. Sure, one might take a look at the number of packages compared with open bugs for example - but in the end that still won't give you some useful metrics. It doesn't much matter what we measure as long as it related to what we want to control and that we do not change the metric. That way the metrics remain useful. Open bugs per package and mean age of bugs per package come to mind. Such per package metrics can be aggregated per herd, per project, the whole of Gentoo or whatever. A reducing mean age of bugs and open bugs shows we are moving in the right direction. I'm sure many other metrics are possible. If someone has a feeling somewhere helping hands are missing or an area is orphaned - that's the best metrics we can get. Feelings? The problem with feelings is that they keep changing Let me remind you of this Carl Sagan quote ... I'm often asked the question, Do you think there is extraterrestrial intelligence? I give the standard arguments -- there are a lot of places out there, and use the word *billions*, and so on. And then I say it would be astonishing to me if there weren't extraterrestrial intelligence, but of course there is as yet no compelling evidence for it. And then I'm asked, Yeah, but what do you really think? I say, I just told you what I really think. Yeah, but what's your gut feeling? But I try not to think with my gut. Really, it's okay to reserve judgment until the evidence is in. - Carl Sagan, The Burden Of Skepticism, The Skeptical Inquirer, Vol. 12, Fall 87 The important bit being it's okay to reserve judgment until the evidence is in. - Tobias -- Praxisbuch Nagios http://www.oreilly.de/catalog/pbnagiosger/ https://www.xing.com/profile/Tobias_Scherbaum -- Regards, Roy Bamford (Neddyseagoon) a member of gentoo-ops forum-mods trustees pgpR6I1rn4awc.pgp Description: PGP signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 04/04/10 23:45, Zeerak Mustafa Waseem wrote: On Sun, Apr 04, 2010 at 04:13:19PM +0100, AllenJB wrote: The unofficial wiki may have been created because there wasn't an official one, but that doesn't mean it's any less of a community in its own right. Starting the official wiki by effectively ripping off others work and attempting to destroy existing user communities is NOT the right way to go about things, in my opinion (and losing the editing history of those articles in the process). You should first try to start your wiki/community and make it a community in its own right, rather than trying to steal/destroy/rip off existing communities. My personal goal is to continue to maintain an existing community full of useful documentation, already concentrated in one place. The unofficial wiki avoids duplication by pointing to existing documentation where ever possible. The search problem is already dealt with by Google, so that's no reason to go about ripping off other peoples work. With your aims in mind, I don't see the point in duplicating existing material, creating TWO places you have to check to see what's been updated. If an official wiki starts up and becomes a major documentation centre for user contributions, then I may consider moving my articles over, but until that time I currently intend to maintain them in place, with their complete history in tact. AllenJB You're absolutely right, it is a seperate community, and reading your replies I can't help but think Is the url really that important?. After all regardless of where the articles that you've written, you still would be the writer. You could still take part in the various discussions that may arise on the articles. The way I see it is that when the official wiki comes up, it will only be a question of time before the pages covered in the unofficial wiki are covered in the official one, particularly if it'll be mainly user-driven and people stop thinking about using the unofficial wiki, as there is a wiki and the answer isn't there. So when they find the answer, they add it. Personally I'd prefer to be part of the change rather than resisting it. I can understand reluctance to join a project you aren't certain will succeed, though. The way I see it, the official wiki has to earn my respect as a project. The unofficial wiki already has already been through this process. It's no different whether I'm trying a new piece of software or a new distro. It's not the URL that bothers me. I will, as I have said, quite happily move the articles I've written over, relicensing what I can if necessary, if/when I believe that the community would benefit. My problem is with the attitude of let's start the official wiki by taking the content of the unofficial wiki, regardless of the wishes of the active contributors of those articles. As another note, the license of gentoo-wiki doesn't stop anyone from copying but is incompatible with the license on the docs (was mentioned in a thread recently) so what is in gentoo-wiki won't be copied, but at best/worst rewritten. As an endnote, none of the above is meant as provocative or offensive, so in case it does offend; you have my apologies (it seems like a touchy subject for you so I thought I'd make it clear :-) ) Yes, the license may allow you to do this, and legally you might be able to do so under the license. But the legal license and ethics/morals involved in such action are different things. As I see it, the purpose of licensing my articles under an open license is to allow them to be contributed to and read without issues in the eventuality that the current wiki is lost for any reason (tho this is highly unlikely to happen again in the forseeable future as I and others now actively backup the content of the wiki, and the server maintainer has much better full backups in place) or the event that I am hit by a bus. If those who wish to run an official wiki can see no sensible starting point other than copying the content of the unofficial wiki, then I would bring into question what the point of an official wiki would be, and why should the Gentoo developers psend time and resources on duplicating the efforts of the community when there is a huge long list of other things they could do that would provide services to the community that are not already catered for. AllenJB
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 5 April 2010 00:21, AllenJB gentoo-li...@allenjb.me.uk wrote: My problem is with the attitude of let's start the official wiki by taking the content of the unofficial wiki, regardless of the wishes of the active contributors of those articles. [...] If those who wish to run an official wiki can see no sensible starting point other than copying the content of the unofficial wiki, then I would bring into question what the point of an official wiki would be, Your problem is based on a misconception, because you're latching on to a couple of remarks made in the thread that are not at all central to our reasons for starting an official Gentoo Wiki. It's not about hijacking your content. We already stated that we prefer to stick with the license used for most other Gentoo documentation, which prevents simply copying your content. So you don't need to worry about that. -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 3 April 2010 20:56, George Prowse george.pro...@gmail.com wrote: Does mediawiki have captcha ability? Yes, there are a number of solutions for that. -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sun, Apr 04, 2010 at 11:21:13PM +0100, AllenJB wrote: The way I see it, the official wiki has to earn my respect as a project. The unofficial wiki already has already been through this process. It's no different whether I'm trying a new piece of software or a new distro. It's not the URL that bothers me. I will, as I have said, quite happily move the articles I've written over, relicensing what I can if necessary, if/when I believe that the community would benefit. My problem is with the attitude of let's start the official wiki by taking the content of the unofficial wiki, regardless of the wishes of the active contributors of those articles. Ah yeah, I should have been more specific with what I meant. What I wanted to ask (but looking back on my mail, not what I did ask) is, what is to stop the community at the unofficial wiki to migrate to the new wiki early in the project? I don't know what you require for the new wiki to be able to gain your respect, but I imagine (wild guessing based on what it would take for it to gain my respect) that one thing is that it has quality articles, I also assume that another is activity. But in that regard, what you and the rest of the community have brought to gentoo-wiki would be a wonderful place to start for the official wiki. I don't mean your articles, well your articles as well but not necessarily the article, I primarily mean a community well adjusted to working with a gentoo-specific wiki. You guys have provided some good articles and having your contribution (in form of willingness to work with the new wiki) would be a great asset, in my opinion anyway. I can understand that you have a problem with it if the first step is taking your work, but what if you were one of the first steps. I mean a successful wiki would be a wiki with an active usergroup (the unofficial one has that), good accurate articles (the unofficial wiki has that as well), and a decent rate of visitors (the articles are useful and relevant) and again, the unofficial wiki has that. You basically have what is necessary for gentoo to grow in this aspect. So the question ends up being, why wait for someone else to prove to you what you can prove to others? (And indeed have proven to others.) If your requirements for the official wiki to gain your respect are the same as mine, then why not help make sure that it meets those requirements? Yes, the license may allow you to do this, and legally you might be able to do so under the license. But the legal license and ethics/morals involved in such action are different things. As I see it, the purpose of licensing my articles under an open license is to allow them to be contributed to and read without issues in the eventuality that the current wiki is lost for any reason (tho this is highly unlikely to happen again in the forseeable future as I and others now actively backup the content of the wiki, and the server maintainer has much better full backups in place) or the event that I am hit by a bus. But in the end you have no control over who copies it. I mean hell, I could start a blog/wiki/whatever else and copy the contents of the unofficial wiki over. And in the end you can't (and by my estimate shouldn't) complain as you knew the terms when you entered, and if not you could stop any time you realized the terms. Whether or not they're contributed to another place than where you put them up, is what you agreed to. I don't see any moral or ethical issues in this. I can understand why it might upset you, but in the end when you release something under a license that allows copying and editing it must be a situation you're prepared for. I do however see why you mgiht find it distasteful. If those who wish to run an official wiki can see no sensible starting point other than copying the content of the unofficial wiki, then I would bring into question what the point of an official wiki would be, and why should the Gentoo developers psend time and resources on duplicating the efforts of the community when there is a huge long list of other things they could do that would provide services to the community that are not already catered for. AllenJB +1 I completely agree with you, there is one reason as I can see it though. As it is at the moment there isn't a recommendation to help out with the unofficial wiki, if it became (part of) the official wiki such a recommendation would be put forth (I imagine). But then, a recommendation could be put forth now :-) But other than that, I completely agree with you. -- Zeerak Waseem pgprqdGj6cxNP.pgp Description: PGP signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
1 - requirements In order to choose the best possible wiki implementation, we need to know our requirements. So what features do you think are essential or good to have? What syntax would we prefer to use? I myself am a big fan of reStructuredText, which is quite simple, easy to pick up, highly readable, and has a good featureset. Plus, it is also reusable in other contexts (it is for example widely used in documentation of Python libraries). MediaWiki, MoinMoin and Trac have support for rst. I'm not overly concerned about what wiki we use. But may I suggest we approach gentoo-wiki to see whether they would like to be involved. Some others: - active upstream (bug fixes, security updates) - free open source software - ACLs - spam prevention measures - attachments (to upload screenshots for example) - feeds Other distros and open source projects surely have had the same considerations. Can we find out and learn from them? 2 - maintainers === Who is volunteering for maintaining the wiki? We need editors and moderators, people who look out for quality control and take care of spam removal. So let's get together a team. I'm sure if we ask on the forums we'll get some users interested as well. I would like to help as I may. Hopefully we can get a good body of users to help as well. I'm of the firm belief that it will be users who should make this idea either fly or crash down hard.Dev's have official means of documenting stuff. 3 - edit access === Do we keep to the original free for all model, with all the spam that includes, or do we go with registered users only? I think the latter is the smarter option. I also think we will want to mark certain pages official and lock down editing rights. Registered users only please. Is there anything else we should consider before getting started? What project should we create this under. gdp is for official documentation so I don't think it should be under that but it could very well be under userrel. Or it could be a new project. I also have some other ideas that I would like to implement once I get around to brain-dumping them. So I will simply ask this question. Are there any complimentary services we could offer users besides a wiki? Maybe best to just think about this and not answer it here. Cheers, Alistair
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 4 April 2010 21:33, Joshua Saddler nightmo...@gentoo.org wrote: Having to write a custom stylesheet just to get one wiki page to do what you want is pretty dumb. Yes it would be. The idea is that you design consistent styling from the get-go, so your stylesheets will be ready for those needs. Pretty much the same as the current documentation solution. How is it unfair? Because tables really are so much simpler to write in GuideXML? No, because they were displaying different things, using different features. Here's a more complicated table: http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap2_sect10 source: http://www.gentoo.org/doc/en/xml-guide.xml?passthru=1 And you think that's intuitive? Tables are a bitch, and I think both the GuideXML approach (copied from HTML) and the wiki syntax one are equally unintuitive. In my opinion reStructuredText is offering a better alternative: http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables Mediawiki mostly involves memorizing how many quote or tick marks you use. The beauty is: you don't have to memorize it, as it is just a click of a button on the editor interface away. This markup is *completely nonsemantic*. In GuideXML, you know EXACTLY what each tag means. No, I don't. The body and title tags are used quite differently from HTML, which is confusing. When do I use section and when do I use body? And what the frak is stmt? And why uri and figure instead of HTML's a and img tags? Except to a few dedicated people, GuideXML is confusing. At any time, you can throw in HTML and CSS to do stuff, because apparently Mediawiki isn't flexible enough on its own to generate your desired rendering. Rather, it's so flexible that it even accomodates using HTML and CSS should you wish so. But you don't have to. Having to mix HTML with a totally different wiki syntax is stupid. Having to mix HTML with a different dialect of XML is equally stupid, and moreover it is confusing. At least with MediaWiki, you don't have to use it, as there are other options. Having to learn CSS *on top* of learning wiki syntax (and HTML) just to write a document is retarded. Wiki editors will not have to learn CSS, unless you have very specific needs that are unforeseen by the designers of the stylesheets you use. You've tried to make the case that learning GuideXML is too hard, but in order to use Mediawiki you'd need to learn at least 3 languages. You don't need to at all. Depending on how the maintainer configures things, at most one markup language should be enough. And that is greatly helped by the editor UI. So for most simple edits you don't need to learn any markup language at all. [...] Leave the styling to a separate stylesheet, and let the code just be code. Yes, that's the whole idea. It's just that MediaWiki offers the flexibility to use those extra features, but you don't have to use them. But that's at the price of standardization: since arbitrary tags and markup is allowed, there's nothing to keep consistency between documents, or even within the same document. That's a matter of configuration. I'm all for locking that down and use a consistent standard styling, so only relatively simple markup is needed. (But we'd have the flexibility to do something more complex should we wish to configure things so.) GuideXML at least has a clean, consistent visual representation. Once you start allowing arbitrary markup, there'll be a million and one ways of representing the same thing, and that's not good for someone trying to wade through documents. There *should* be a standard way of representing information. I absolutely agree. And you can achieve the same with a wiki. And if you really wanted to, you could easily write an extension to parse GuideXML, so it could be used as wiki markup. So again, the markup is not really an argument against using a wiki instead of our current GuideXML+gorg setup. Except I haven't seen Mediawiki offer anything like our textual color palette or other code syntax and block-level formatting flexibility. What do you mean? You can predefine styles in your CSS to express your textual color palette (if I understand correctly what you meant by that). There is advanced code syntax highlighting available, for example using GeSHi. 2. It is a non-transferable skill. You can't use it anywhere else. And unless you are a regular GuideXML writer, you will have to look up its particular usage almost every time you do use it. It's just XML. That's all. If you can write HTML, then you can write XML. XML is *easier*. It's got far fewer tags, for starters. That means much, much less to learn. That's not fully correct. XML has in principle a practically infinite number of tags. It all depends on which dialect you use. If it is a dialect you do not use a lot, you will forget the usage of particular tags. Oh, and guess what? You ebuild writers are already using XML every
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-04-04 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2010-04-04 23h59 UTC. Removals: dev-libs/dvcgi 2010-03-31 17:42:31 ssuominen dev-libs/dvenv 2010-03-31 17:42:31 ssuominen dev-libs/dvmysql2010-03-31 17:42:31 ssuominen dev-libs/dvticket 2010-03-31 17:42:32 ssuominen dev-libs/dvxml 2010-03-31 17:42:32 ssuominen kde-misc/plasma-indicatordisplay2010-03-31 18:27:09 tampakrap gnome-extra/gnome-keyring-manager 2010-04-01 22:05:56 eva x11-libs/compizconfig-backend-kconfig 2010-04-03 07:19:52 jmbsvicetto Additions: dev-tcltk/tklib 2010-03-29 11:32:45 jlec dev-vcs/bzr-xmloutput 2010-03-30 23:03:22 fauli x11-terms/terminator2010-03-31 06:20:08 jlec dev-libs/libdbusmenu-qt 2010-03-31 16:31:18 tampakrap dev-libs/libdbusmenu2010-03-31 16:40:34 tampakrap kde-misc/plasma-widget-message-indicator2010-03-31 18:12:05 tampakrap games-puzzle/brainparty 2010-04-02 03:23:17 mr_bones_ dev-tcltk/tkpng 2010-04-02 06:54:44 jlec x11-themes/human-icon-theme 2010-04-02 16:18:59 ssuominen x11-libs/compizconfig-backend-kconfig4 2010-04-03 03:46:53 jmbsvicetto dev-lang/ruby-enterprise2010-04-03 06:39:01 a3li dev-embedded/scratchbox-devkit-debian-squeeze 2010-04-04 09:21:32 ayoy sys-power/pm-quirks 2010-04-04 16:07:58 scarabeus games-board/knights 2010-04-04 16:35:42 scarabeus -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-libs/dvcgi,removed,ssuominen,2010-03-31 17:42:31 dev-libs/dvenv,removed,ssuominen,2010-03-31 17:42:31 dev-libs/dvmysql,removed,ssuominen,2010-03-31 17:42:31 dev-libs/dvticket,removed,ssuominen,2010-03-31 17:42:32 dev-libs/dvxml,removed,ssuominen,2010-03-31 17:42:32 kde-misc/plasma-indicatordisplay,removed,tampakrap,2010-03-31 18:27:09 gnome-extra/gnome-keyring-manager,removed,eva,2010-04-01 22:05:56 x11-libs/compizconfig-backend-kconfig,removed,jmbsvicetto,2010-04-03 07:19:52 Added Packages: dev-tcltk/tklib,added,jlec,2010-03-29 11:32:45 dev-vcs/bzr-xmloutput,added,fauli,2010-03-30 23:03:22 x11-terms/terminator,added,jlec,2010-03-31 06:20:08 dev-libs/libdbusmenu-qt,added,tampakrap,2010-03-31 16:31:18 dev-libs/libdbusmenu,added,tampakrap,2010-03-31 16:40:34 kde-misc/plasma-widget-message-indicator,added,tampakrap,2010-03-31 18:12:05 games-puzzle/brainparty,added,mr_bones_,2010-04-02 03:23:17 dev-tcltk/tkpng,added,jlec,2010-04-02 06:54:44 x11-themes/human-icon-theme,added,ssuominen,2010-04-02 16:18:59 x11-libs/compizconfig-backend-kconfig4,added,jmbsvicetto,2010-04-03 03:46:53 dev-lang/ruby-enterprise,added,a3li,2010-04-03 06:39:01 dev-embedded/scratchbox-devkit-debian-squeeze,added,ayoy,2010-04-04 09:21:32 sys-power/pm-quirks,added,scarabeus,2010-04-04 16:07:58 games-board/knights,added,scarabeus,2010-04-04 16:35:42 Done.
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 5 April 2010 02:02, Alistair Bush ali_b...@gentoo.org wrote: I'm not overly concerned about what wiki we use. But may I suggest we approach gentoo-wiki to see whether they would like to be involved. If anybody wants to approach them, that is fine by me. I'm probably not the right person for that job, due to my critical remarks. We have approached the gentoo-wiki.com owner in past and he then declined to cooperate. I would like to help as I may. Thanks, that would be very welcome. Is there anything else we should consider before getting started? What project should we create this under. I was thinking to start a wiki project. I also have some other ideas that I would like to implement once I get around to brain-dumping them. So I will simply ask this question. Are there any complimentary services we could offer users besides a wiki? Maybe best to just think about this and not answer it here. That's a very good question, and I hope to hear some answers, especially from users. Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] Is Gentoo dying?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04-04-2010 04:50, Dale wrote: I felt sorry for the KDE folks when KDE4 was released. It just had to be a nightmare to get all that in the tree at once. If they had twice as many people working on it tho, it would have been easier. The people doing all that work wouldn't feel like they had to work so hard to get everything ready. Back to my hole now. Dale :-) :-) Dale, now that we've moved well past beyond that point and that we have a reasonably staffed team, let me thank you for your sympathy, agree with you about how extra hands would have helped much and admit that was a very tough time. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLuS6dAAoJEC8ZTXQF1qEPHxIP/2Pm0kdi57x2OuhEBpm5ZWF5 sNyy7qbY4/b6VM/UNH5NJbg3vYBPtDtQSdY0ZB5D+C2p+q2jpko9oRR4pCFQ23QK PEPAxS+d7QwKzlLfzNOTb0uwogCEqaxEBNy7tE+KjXTsqdBuGWblqHAKXDMM9sHM Nhcqcfd87krvjPzuqOEhvk/V8kLhdzmkDZF082W827UJsVkpld10wkaOymlri/vN J2N83nzCUYxkP79zGEM7FWn12dQIW+UUqblyp5FFP38pZd7kxra/IqnJl60g1IaK pJ4tt+2InZ5HVXkW4fuOmhkjZCkd4abgtHgFuUi5Go2YloKU3sJBuJkro5me2/CZ Plp485cqK38rG7nNKLK2UrwxgKU+xO/3ylb7IhI3k3Hn7uv9mV6+MAGucwe/5T+y wHgd3ia0JqO9MD3uYa2M/u7u4sXpezZVnbHVB/RYRuaLVVVK/AMo9OQDTGbNQHPR DP5/MGG5OBqZGfLCoMmJIcgIvaKN5zRyTceXQxe0W/HXfU2zGMGTm+SBG0kM3zBH yHQjeFqA/W48CwOaCy+zwS3YaGKnuS9036VIBnhyqBpCCEMMwJ9W02abISbN2qg5 wmpbIogQT3yf6E/37x1xFeYCxdpeLwuII1hqSEBNWNz+6JBV04Zk5K7nrcsMEbo2 sKKWU1F7nb8Ha9rh58v8 =CP10 -END PGP SIGNATURE-
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Alistair Bush wrote: I'm not overly concerned about what wiki we use. But may I suggest we approach gentoo-wiki to see whether they would like to be involved. +1, especially the overly concerned part. Seriously folks. Just start it. Take whatever you as a person feel comfortable with. Talk to infra, if there are concerns about security. Then get moving. Maybe even set up multiple implementations and start evaluating, if you can trick infra into doing the setup. If not, you'd have to live with what they give you. You can theorize all you want about the best possible solution. That will just clog up the pipes and piss users off no end. It certainly did so for me. I'm now at the point where i'm willing to bet money on the wiki request never actually reaching infra. Can we please go back to happy days where guys and gals worked on an implementation FIRST, posted to lists SECOND and ironed out errors via peer review THIRD? It'll make us all more productive. What project should we create this under. Please don't make it another project. This will just create a new territory and spread resources even thinner. Take one of the user-facing projects like forums or userrel. But don't let this be a blocker to get things done. You can always change ownership of the stuff once you actually get some property to talk about. An important lesson i've learned during the last days as i've taken up php stuff: people, users and devs alike, will step up to help you, do things for you, work with you and be generally amazing if you (1) ask specific, detailed questions and (2) provide some of the work yourself. Usually you have to do (2) before you can do (1). Applying this the wiki debate, you (1) ask specific, *technical* questions, you ideally answer with yes/no (1.1) Do we have an ebuild for it? If no, can i maintain one? (1.2) Will infra emerge the ebuild for me? If not, why not? (1.3) Who do i pester about my administrator access data? (1.4) Who can i use as lab-monk^W^W^Wa test group? How to reach them? (2) set up some fscking wiki and let people play with it. (3) profit ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On Sat, 2010-04-03 at 12:50 +0300, Petteri Räty wrote: I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? I would like to avoid things like this: https://bugs.gentoo.org/show_bug.cgi?id=113121#c21 Not applicable to the bug above but in general our social contract says: We will not hide problems The problem is really the RESOLVED connotation and the hiding that goes along with that on searches, etc. The LATER status itself can be useful when used properly (more as ASSIGNED LATER). In the lack of that some bigger teams might need to think of other methods to get things meant for LATER out of main views of huge bug lists. In my case, I want to have a gnome saved search that shows all OPEN (non-LATER) bugs directly assigned to gnome, and another saved search that shows those where gnome@ is merely in CC, or anything marked as LATER. Though that might not be achievable, so three saved searches really. More useful might be a date field upon which it will simply automatically re-open. Maybe something one is unable to set more than 30 or so days into the future. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://blogs.gentoo.org/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Mon, 5 Apr 2010 02:08:06 +0200 Ben de Groot yng...@gentoo.org wrote: On 4 April 2010 21:33, Joshua Saddler nightmo...@gentoo.org wrote: Having to write a custom stylesheet just to get one wiki page to do what you want is pretty dumb. Yes it would be. The idea is that you design consistent styling from the get-go, so your stylesheets will be ready for those needs. Pretty much the same as the current documentation solution. How is it unfair? Because tables really are so much simpler to write in GuideXML? No, because they were displaying different things, using different features. Here's a more complicated table: http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap2_sect10 source: http://www.gentoo.org/doc/en/xml-guide.xml?passthru=1 And you think that's intuitive? Tables are a bitch, and I think both the GuideXML approach (copied from HTML) and the wiki syntax one are equally unintuitive. In my opinion reStructuredText is offering a better alternative: http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables At least the GuideXML approach to tables is familiar to anyone who's worked with HTML. Oh wait, you shouldn't be comparing GuideXML with HTML. More on that later in this message. Also, don't get me started on rST's many failings. It's just like wiki syntax, in that anything you want to do besides line spaces and lists involves stupid nonsemantic code. Having to define URIs twice is retarded: External hyperlinks sample sentence, like Python_. .. _Python: http://www.python.org/ Tables: A big problem with rST and wiki markup is that they try to preserve the rendered format within the source code view. +++---+ | Header 1 | Header 2 | Header 3 | +++===+ | body row 1 | column 2 | column 3 | +++---+ That's rST source. This gets unwieldy very quickly for larger tables, as they'll overflow your editor window. Hey, that might not be a problem, but it's also a losing proposition to try to have that stuff rendered within the source view. Let the renderer take care of the final rendering, as really, tags and markup are all arbitrary. What should matter is how it appears in your webbrowser, since that'll vary from the source view anyways. . . . I hope you aren't seriously suggested rST as the wiki format. Mediawiki mostly involves memorizing how many quote or tick marks you use. The beauty is: you don't have to memorize it, as it is just a click of a button on the editor interface away. And not everyone will want to do that. I certainly don't like clicking around when it's easier and faster for me to just type the code myself. Really, you're mostly making a case for a graphical XML editor like Beacon, rather than making a case for a wiki. :) This markup is *completely nonsemantic*. In GuideXML, you know EXACTLY what each tag means. No, I don't. The body and title tags are used quite differently from HTML, which is confusing. When do I use section and when do I use body? And what the frak is stmt? And why uri and figure instead of HTML's a and img tags? Except to a few dedicated people, GuideXML is confusing. That's your problem, then. Do you know what semantic means? Semantic doesn't mean just like HTML. So stop treating it that way. Let's look at semantic tags. It's not hard to see that var is a variable and that stmt is a statement, and comment is a comment. Semantic markup is markup that means what it says. Using punctuation marks like ' '' ; : is neither semantically useful nor easily readable, as I showed in the code samples you oh-so-casually skipped over. Nice try. ' and ' ' mean nothing in and of themselves. But you're not a web author, so I'll stop trying to beat you over the head with how things work. Next point: Having to mix HTML with a different dialect of XML is equally stupid, and moreover it is confusing. At least with MediaWiki, you don't have to use it, as there are other options. Why the hell do you keep bringing up HTML? Stop comparing GuideXML with HTML. Treat them as two separate languages, please. I only mentioned GuideXML in the context of it's easier to learn because it has fewer tags than HTML -- you operate under the mistaken assumption that GuideXML should be *like* HTML, and that HTML has too many tags. You assume that everyone comes from an HTML background and thus will be confused by GuideXML. What do you mean? You can predefine styles in your CSS to express your textual color palette (if I understand correctly what you meant by that). There is advanced code syntax highlighting available, for example using GeSHi. Okay, then you also need a way to get those styles into your document by coming up with new tags or wiki markup. var is a variable in GuideXML, and it'll be colored yellow. You mark this variable in a pre block with the var tag, which is created just for
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03-04-2010 13:19, Ben de Groot wrote: A proposal for a Gentoo WIKI that generated much replies I have the following general comments about this thread. * I congratulate everyone involved on this that is so motivated to create a new option for hosting content for the Developers and Community at large and wish all the best for this project. * I would humbly like to suggest that there will be a larger chance of success for this project if those promoting it focus on the benefits it can bring, work on generating new content and give up on the idea of replacing other projects and communities. In particular I'd also advice people in this project to work with existing projects and communities and to avoid clashes over content, format and or merit. * If those involved in this project are willing to, I think it could fit well within the User Relations area as this is another way to reach out to our community. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLuUSKAAoJEC8ZTXQF1qEPNJUQAMugv/k0tPccGpJlgWeyvmjv 6RKuhBjH9Ty/pIS3C8eQApPxP7oUMwMoeP59fmGrFlLtw0rGyqBTDFXlm7a7I8cY Eof4NnZe2TJCqZWqSaEnAUdswgb4yrZXifzaRn3ITKR1Q9g705/Gs63pjVC/RoSn ubtFinZCE2IlVYdG6j96uO3aFy7UgHwkSX4yVwV2DJCA1IoGtzJjxEisiLkmY+02 4PBAgg+MpSpFT7EG1/ADfKYDyGGID3Dr3tqXlSoHOM9nl41cs4pe4UL5G6VzirDb NUj+WFSc195APNenFdvpU7bDWP5guCuS9uaPhJrN7z9uZ1iHtmluz0Y3kx6yx9Ss IWuxMwFVe9yvhGqSBWafBrdaCWwTBAzQJaqDUBNO2WAulGulOve6ZT2CMFGMWXz7 OvcuRhAh8B2ab4ln40oDqPNm285YhwDoCs4khJAAdUezrPYW5aMS3hr6s4AbC2C0 W+xx/NWoNTUTNyoHHlX1uUB35+1jnr/3pRSRnXOECYT8ag8u1xKZ39J+V41OfQZV /CZWrExV9B1gxVnjFPDWjhKhIRkwpeKCOwHiXMLyTrK+Rp4dyLiGh6mjdvu0NURW GoGKZsrFLTZoREmWlI4EEkaTw+WeJDdfhkiOdhewsZoEgc1V97Nh4nFw+Mr5LFZb B2h6Cg+6nkTPuphjc5ME =NZyc -END PGP SIGNATURE-
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 4/3/10 3:40 PM, Ben de Groot wrote: Are there any other ideas on how to improve our recruitment process? The idea appeared before, but I think it's worth noting. Either merge the ebuild and end quizzes, or make the split actually meaningful. In my case I just finished both at the same time, but was confused why they are separate. I think I've seen similar comments from other developers. I think I'd rather prefer merging the quizzes. One thing i've noticed is that the ebuild quiz is far more difficult than the eom quiz. We seem to have the biggest hurdle first. What I would like to see is either the quizzes be merged or An easier first quiz that covers the basics which after being answered the user can become a gentoo developer ( ie @gentoo.org email, ssh access to d.g.o, etc) but no access to push directly to the tree. Instead all commits must be pushed thru their mentor, who is responsible for qa'ing and giving advice. Currently I don't think mentors really have much of a role. There is certainly no requirement for a mentor to qa their charges commits, but if they are the ones pushing to the tree the mentor has all the responsibility. This might just make mentors more responsible for the quality of recruits. Some of this could be done regardless of whether there are separate quizzes or not obviously. But I think it creates a nice workflow. - Alistair.
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 5 April 2010 04:01, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: * I congratulate everyone involved on this that is so motivated to create a new option for hosting content for the Developers and Community at large and wish all the best for this project. Thank you! * I would humbly like to suggest that there will be a larger chance of success for this project if those promoting it focus on the benefits it can bring, work on generating new content and give up on the idea of replacing other projects and communities. In particular I'd also advice people in this project to work with existing projects and communities and to avoid clashes over content, format and or merit. Yes, the thread made some excursions, but let's focus on the task at hand. The wiki is in the first place about offering something that has been missing. It is also about bringing people together. It is not about duplicating effort. * If those involved in this project are willing to, I think it could fit well within the User Relations area as this is another way to reach out to our community. I'm not sure UserRel is exactly the right fit, as we very much also are about offering services to developers for more internal use, such as project meeting agendas. I do think we should work closely together, like the other participating projects mentioned on the UserRel project page. -- Ben de Groot Gentoo Linux Qt project lead developer
[gentoo-dev] Re: Is Gentoo a Phoenix?
Zeerak Mustafa Waseem posted on Sun, 04 Apr 2010 22:19:06 +0200 as excerpted: esOn Sat, Apr 03, 2010 at 07:33:53AM -0400, Richard Freeman wrote: I really think that the Gentoo recruitment process needs improvement. Right now it seems like a LOT of effort is required both to become a Gentoo dev and to help somebody become a Gentoo dev. That means we have great people, but not many of them. I like that last sentence summation. It's perhaps optimistic, but does bring into sharp focus both a positive and a negative of the current process. I think the problem is that our recruitment process uses the ability to answer complex technical and organizational questions as a way to assess maturity. I think that maturity is far more important than technical skill in a distro - a mature person will recognize their own limitations and exercise due diligence when stepping outside of them. Instead of playing 20 questions and going back and forth with recruits, maybe a better approach would be to cut down the questions dramatically (or more clearly put their answers in the documentation), and then use other approaches like references and interviews. A new recruit might be given the names of 5 devs that they will need to interview with for 30-60 minutes by phone or IRC (preference on phone), and they will need to submit references, who will be contacted. When we hire people at work we don't play trivial pursuit with them, we use an interview to get a feel for what they're like and how they handle situations, and we screen resumes and references to determine experience. I'm sure any of the professional linux distros would work in the same way, but perhaps somebody should ask around and see how it is done elsewhere. I'm not exactly sure how you'd want the references to work, I mean, as in prior jobs/projects worked on? I know that I'd like to help out with development, but as it stands I don't think I have the necessary skills (various programming language etc), so that is something I'm working on. I expect rich0 had in mind (tho I won't claim to speak for him) something a bit broader when referring to references. Certainly, in the FLOSS world many people are self-taught to some degree or another, and many are volunteers, so references in the traditional job sense may not be available. But in the FLOSS world, the term is indeed often used in a broader sense. For instance, if I were to apply, I'd list my long-time involvement on the pan (Internet news client) lists, where my involvement hasn't been as much in the technical sense but in helping out users, and ideally, in being an interface between users and devs such that devs need spend less time helping users and can spend more time developing. =:^) In Gentoo, not only my record of involvement on the amd64 list and here (I've followed the dev list, as much to get a heads-up on what's coming before it hits as anything else, since 2004.0, before I even had Gentoo successfully installed, as that wasn't until 2004.1), but on bugs.gentoo. Even if those aren't particularly technical references, they absolutely demonstrate consistency and integrity in community contribution. Those references demonstrate integrity, in terms both of length of commitment, and security-wise. If I'm a bad guy, I must be a pretty patient one! =:^) Others won't have that length of service to point to, but they have an IRC handle that has come to be identified with cooperativeness and willingness to help and to learn. Bugday participation is a very solid reference, as is work on one of the overlays with reasonably heavy community involvement, be it a specialized one like the java or kde overlays, or a couple of ebuilds on sunrise. There's also the forums, with their very direct and practical mechanism for recognizing frequent and helpful posters, and lets not forget the reference points a well developed doc submission (and docs takes plain text submissions too, I'm told, right nightmorph?) is going to be worth. These sorts of references can be developed in perhaps six months or so, rather less if you've already a partially developed docs addition in mind. As a consequence I naturally don't have any references (and might not by the time I feel ready) but that wouldn't necessarily mean that I'm not qualified to be working as a dev. Also one could imagine that a number of other people without references, but the necessary qualifications might think To hell with this, I'll just put my effots somewhere else. Keep in mind that for many of the above, the six months to the establishment of a reasonable record may be well underway before one ever decides to take their Gentoo contributions to the next level. As with character and community references for a job or rental/lease, if you're finding yourself having to deliberately develop them, you're probably going about it the wrong way -- by the time you /need/ them, you
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 5 April 2010 08:13, Ben de Groot yng...@gentoo.org wrote: On 5 April 2010 03:13, Joshua Saddler nightmo...@gentoo.org wrote: [...] Really, you're mostly making a case for a graphical XML editor like Beacon, rather than making a case for a wiki. :) That would already be a big improvement, yes. That's your problem, then. Do you know what semantic means? Yes, I do. No need to be condescending. But you're not a web author, I am, altho not as active lately. Why the hell do you keep bringing up HTML? Stop comparing GuideXML with HTML. Treat them as two separate languages, please. Because clearly GuideXML is based on HTML. And anyone who knows HTML will likely be confused by some features of GuideXML. I can't treat them as completely separate, as there is too much overlap. I only mentioned GuideXML in the context of it's easier to learn because it has fewer tags than HTML -- you operate under the mistaken assumption that GuideXML should be *like* HTML, No, I wish it weren't, but it *is* like HTML. and that HTML has too many tags. I never said that. You assume that everyone comes from an HTML background and thus will be confused by GuideXML. I would think that most people that become involved with Gentoo have most likely been exposed to some HTML coding. You guys should take a while to cool off at this stage. Quite frankly, the documentation project is just another open source project - if anyone wants to change how things are done, the only real way to do that is join the team, prove that you are dedicated and committed, and promote change from the inside. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 5 April 2010 10:34, Arun Raghavan ford_pref...@gentoo.org wrote: On 5 April 2010 08:13, Ben de Groot yng...@gentoo.org wrote: On 5 April 2010 03:13, Joshua Saddler nightmo...@gentoo.org wrote: [...] You guys should take a while to cool off at this stage. Never mind me. I missed Ben's last email. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
Just replying randomly. On 05.04.2010 04:33, Tobias Heinlein wrote: I think this is a good starting point to get rid of the some important questions are too hard to answer dilemma that can be implemented relatively fast. On top of that I like Sebastian's idea to order the quizzes by difficulty -- this means just ordering by the categories I just mentioned would be sufficient: 1 first, then 2, then 3. I am not against this idea but frankly, I do not understand what is so demotivating about the ebuild quiz. If you get demotivated because of a single exam, perhaps the problem is with the motivation and not with the exam itself. I took the published quiz just for the fun of it and to see where I missed. It is not that long. What is demotivating is a) lack of response from your mentor/proxy-maintainer etc. It is demotivating when you have to wait for days for each question you ask. b) infighting and name calling one sees on irc, gentoo-dev etc. Do I really want to be a part of this? pops into mind. Suggestions: 1. Bring your responsibilities in line with your capabilities. If you are always falling behind, either increase the time you spend on Gentoo or decrease your responsibilities. It is no fun playing catch-up. 2. Streamline the recruitment process so that existing devs do not spend too much time and effort during mentoring. Objective is to make recruitment not a burden on the dev, i.e streamline for the dev not for the candidate. 3. Take it down a notch in gentoo-dev, irc. No ad hominem attacks and no flame wars please. You are supposed to enjoy this. Easier said than done I suppose. -- Eray
