If you don't object please comment and re-assign to infra so they can grant write permissions to me. Thanks!
Changing the subject because infra can't grant access on a per-file level.
It's not our policy for folks to have write access until they've proven they have a fluent command of GuideXML and have a history of contributions to our main documentation. However, I'd be happy to apply any patches you have for the guide -- I recognize that it's very out of date. I'm the only one that's been working on it, since the rest of Releng is either busy or uninterested in updating the guide for the latest genkernel versions.
(In reply to comment #2) > It's not our policy for folks to have write access until they've proven they > have a fluent command of GuideXML and have a history of contributions to our > main documentation. I do not intent to touch more than the page on genkernel. I don't see any risk to give write access to a person who has write access to the package tree, already. I have touched GuideXML before plus we have validity pre-commit hooks in place. If you still worry about my permissions, I propose we move the genkernel docs into project space where everyone can write to. You'll need a transparent redirect to keep the old URL working, though. > However, I'd be happy to apply any patches you have for the guide I'm unsure if I'm really willing to bother with opening bugs, handling patches, and mails, and waiting. I have lots of other work with higher fun factor to choose from. > I'm the only one that's been working on > it, since the rest of Releng is either busy or uninterested in updating the > guide for the latest genkernel versions. Correct, even the docs within genkernel (man page and --help output) are incomplete and out of sync. I have write access to that place, as I'm on the overlays team. Does any of that change anything for you?
(In reply to comment #3) > I do not intent to touch more than the page on genkernel. It's not possible to give write access to only one document. > I don't see any risk to give write access to a person who has write access to > the package tree, already. It's not at all the same thing. Ebuilds != docs; they have separate QA policies. That's a reason why there's a separate GDP staff quiz that folks have to complete before getting docs access -- you wouldn't trust a GDP member to start making commits to gentoo-x86 without having been vetted by ebuild staff, would you? > I have touched GuideXML before plus we have validity pre-commit hooks in place. The pre-commit hooks ONLY work on checking coarse things like general validity. They do nothing to ensure well-formed XML, correct English grammar, tab removal, typos, or handling date/version and other minor tags correctly. > If you still worry about my permissions, I propose we move the genkernel docs > into project space where everyone can write to. You'll need a transparent > redirect to keep the old URL working, though. Possibly, but the redirects are really a pain for all our other documents, as well as keeping accurate logs of "how many hits" and especially maintaining CVS history. > I'm unsure if I'm really willing to bother with opening bugs, handling patches, > and mails, and waiting. I have lots of other work with higher fun factor to > choose from. You're making the same argument lxnay did a few years ago: he came in, demanded that we give him write access to gentoo-x86 so he could "fix our problems," since he "couldn't be bothered to 'waste time' going through our process." It's not going to happen that way, sorry. Going through the process is one of the ways we know someone has the time, concentration, and skill each of our documents *requires* - they need the utmost care. Especially for our English documentation; this is held to the highest standards, since all our translations and secondary docs depend on it. HOWEVER! I am willing to help you out above and beyond our usual procedures. :) If you don't want to file a bug, then email me a patch directly. I'll do my best to get to it that very same day. No mucking about with Bugzilla or attaching patches in a multistep process. Though you should realize that by emailing me directly, you forgo having anyone else from the GDP step in and help take care of it, unless you CC all of us. That said, the "lag time" for me to respond to bugs and personal requests is pretty low, especially when a Gentoo developer brings the item to my attention. Usually I'll fix the issue within a few minutes of an email.
Hi Sebastian, generally speaking, the rule is "only GDP can touch gentoo/xml/htdocs/doc". Why don't you become part of the GDP? :) I don't see a problem even if you say beforehand that you don't care and only want to fix one document. Seriously though -- the level of bureaucracy is probably rather annoying for a guy like you, but we do have a reason for that, ranging from trying to guarantee that the English is good enough, that the XML syntax follows our coding style etc etc. I guess it's gonna be much easier when we migrate to git (nobody works on that ATM AFAIK, though), where you'd basically just submit merge requests. Even with git, though, that last step, ie. merging the actual changes, would have to be done by someone from GDP, again for that QA reasons. I hope you'll at least understand our point and not feel like we're asking you to GOFU and not appreciate your contributions, which would be far from true. Have fun.
(In reply to comment #5) > I hope you'll at least understand our point and not feel like we're asking you > to GOFU and not appreciate your contributions, which would be far from true. > Have fun. ^^ What jkt said. But he said it much more succinctly. :)
(In reply to comment #4) > (In reply to comment #3) > > I do not intent to touch more than the page on genkernel. > > It's not possible to give write access to only one document. I'm aware. I mentioned it to point out that you actually do put a lot of trust in me, but maybe didn't notice. I wanted to bring that to your attention. > > I don't see any risk to give write access to a person who has write access to > > the package tree, already. > > It's not at all the same thing. Ebuilds != docs; they have separate QA > policies. That's a reason why there's a separate GDP staff quiz that folks have > to complete before getting docs access -- you wouldn't trust a GDP member to > start making commits to gentoo-x86 without having been vetted by ebuild staff, > would you? No, but that case seems asymmetric to me. Getting ebuilds right seems harder to me than the technical aspects of doing documentation. > The pre-commit hooks ONLY work on checking coarse things like general validity. > They do nothing to ensure well-formed XML, correct English grammar, tab > removal, typos, or handling date/version and other minor tags correctly. Right. > Possibly, but the redirects are really a pain for all our other documents, as > well as keeping accurate logs of "how many hits" and especially maintaining CVS > history. If that's a problem, I don't know what to suggest. > > > I'm unsure if I'm really willing to bother with opening bugs, handling patches, > > and mails, and waiting. I have lots of other work with higher fun factor to > > choose from. > > You're making the same argument lxnay did a few years ago: he came in, demanded > that we give him write access to gentoo-x86 so he could "fix our problems," > since he "couldn't be bothered to 'waste time' going through our process." Agreed, it's a difficult problem: on the one hand you want to ensure the highest quality, on the other QA needs to be done in a way not taking too much fun out of the process for the person doing the initial work. > It's not going to happen that way, sorry. Going through the process is one of > the ways we know someone has the time, concentration, and skill each of our > documents *requires* - they need the utmost care. Especially for our English > documentation; this is held to the highest standards, since all our > translations and secondary docs depend on it. I see. > HOWEVER! I am willing to help you out above and beyond our usual procedures. :) > > If you don't want to file a bug, then email me a patch directly. I'll do my > best to get to it that very same day. No mucking about with Bugzilla or > attaching patches in a multistep process. Though you should realize that by > emailing me directly, you forgo having anyone else from the GDP step in and > help take care of it, unless you CC all of us. Could I mail those patches to gentoo-doc to solve the number-of-eyes problem? Would that usage fit into the purpose of that list? Would some alias a better target? I think I can live with that for the moment. Maybe that's even going to be fun. (In reply to comment #5) > Why don't you become part of the GDP? :) I don't see a > problem even if you say beforehand that you don't care and only want to fix one > document. What would joining take and what rights and duties does it bring? You mentioned quizzes? Do you have pointers on this for me? > I guess it's gonna be much easier when we migrate to git > (nobody works on that ATM AFAIK, though), where you'd basically just submit > merge requests. Even with git, though, that last step, ie. merging the actual > changes, would have to be done by someone from GDP, again for that QA reasons. While you mention Git: Maybe I can be of help with the transition. But let's take that topic somewhere else. Maybe you can mail me pointers on where you are with that? ´ > I hope you'll at least understand our point and not feel like we're asking you > to GOFU and not appreciate your contributions, which would be far from true. > Have fun. I'm actually very thankful that (both of) you explain motivations in such detail to me. Best, Sebastian
We seem to have an amenable arrangement; thanks for all the patches so far. You can continue to send them to Bugzilla and the ML. If you're interested in becoming a member of the GDP, we have a few policy guides and HowTos referenced on our project page: http://gdp.gentoo.org Any questions, just ask one of us on IRC or via email. Thanks!
