Team Members:
Here is a test case for updating the yum guide, "Managing Software with Yum".
On web page http://fedora.redhat.com/docs/yum/en/sn-yum-proxy-server.html, there is a typo:
The section:
# The proxy server - proxy server:port number proxy=http://mycache.mydomain.com:3128 # The account details for yum connections proxy_username=yum-user proxy_password=qwerty
should be:
# The proxy server - proxy server:port number http_proxy=http://mycache.mydomain.com:3128 <== # The account details for yum connections proxy_username=yum-user proxy_password=qwerty
(I found this out the hard way).
The current approach is to file a bug report with bugzilla. Should we continue with this approach?
Do we correct the wiki version instead and then apply the fixes to the DocBook version? The wiki page is located at http://fedoraproject.org/wiki/Docs/Drafts/SoftwareManagementGuide/YumProxy
This is a real example. I am in the process of documenting the work flow and really would like feedback on this.
John Babich
On Mon, 2006-12-18 at 19:58 +0300, John Babich wrote:
Team Members:
Here is a test case for updating the yum guide, "Managing Software with Yum".
[snip bug]
The current approach is to file a bug report with bugzilla. Should we continue with this approach?
Yes, although in this case you might skip that since you are involved as a maintainer for that guide. However, the value of using bugzilla extends to other people who find this bug, maybe in a mirror version or old copy. The existence of the bug report can be helpful in resolving that.
Do we correct the wiki version instead and then apply the fixes to the DocBook version? The wiki page is located at http://fedoraproject.org/wiki/Docs/Drafts/SoftwareManagementGuide/YumProxy
Once a bug has been filed, the writer researches the bug. Assuming a fix is required, the fix is applied to the *source*. Then the source is used to rebuild the document, which is published again.
In the case of this guide, the source is XML in CVS. For the release notes, the source is the Wiki. *However*, because of the complexity and lossiness of conversion from the Wiki, for the release notes we are fixing it in the Wiki _and_ manually fixing the same spot in the XML.
I think we would all agree that if you find a bug in your own work, or in a work you are a permitted contributor for, you don't need to file the bug. The only reason to file is if you need a conversation (on record) with people about a fix, etc. For example, the correction in the documentation might be a poor fix where the application in question really needs to be fixed. So, you might start up a bug report about the problem in the document, drag in the application maintainer, and then eventually reassign the bug to that person to fix in the application. Then they can reassign the bug back to the writer to note the fix in the documentation.
Clear as mud?
This is a real example. I am in the process of documenting the work flow and really would like feedback on this.
Go ahead and roll it out as you come up with it (http://fedoraproject.org/wiki/DocsProject/WorkFlow) and we'll watch to see if there are any missing pieces in the workflow.
- Karsten
On Mon, 2006-12-18 at 19:58 +0300, John Babich wrote:
Team Members:
Here is a test case for updating the yum guide, "Managing Software with Yum".
On web page http://fedora.redhat.com/docs/yum/en/sn-yum-proxy-server.html, there is a typo:
The section:
# The proxy server - proxy server:port number proxy=http://mycache.mydomain.com:3128 # The account details for yum connections proxy_username=yum-user proxy_password=qwerty
should be:
# The proxy server - proxy server:port number http_proxy=http://mycache.mydomain.com:3128 <== # The account details for yum connections proxy_username=yum-user proxy_password=qwerty
(I found this out the hard way).
What, exactly, did you experience or observe? I have the first usage in my /etc/yum.conf and it works. I just did a "yum clean all" and everything worked as expected with my squid proxy. (I am tunneling it through SSH, but that shouldn't matter in this case.)
A quick glance at /usr/lib/python2.4/site-packages/yum/config.py and /usr/lib/python2.4/site-packages/yum/yumRepo.py says this usage is more complicated. You may be able to use a different proxy for each protocol, but "proxy=<URL>" is a perfectly valid usage.
The current approach is to file a bug report with bugzilla. Should we continue with this approach?
Do we correct the wiki version instead and then apply the fixes to the DocBook version? The wiki page is located at http://fedoraproject.org/wiki/Docs/Drafts/SoftwareManagementGuide/YumProxy
This is a real example. I am in the process of documenting the work flow and really would like feedback on this.
I would advocate further investigation before you file this one. :-) Happy to help if I can!
On 12/19/06, Paul W. Frields stickster@gmail.com wrote:
What, exactly, did you experience or observe? I have the first usage in my /etc/yum.conf and it works. I just did a "yum clean all" and everything worked as expected with my squid proxy. (I am tunneling it through SSH, but that shouldn't matter in this case.)
This is where it gets tricky. I guess the good thing about filing a bug report is that, if done correctly, the filer should verify the bug and explain the context in as much detail as possible.
Suffice it to say that, in my situation, I required http_proxy for doing basic authentication with my ISP. It may work differently in your setup, or I may have changed the initial conditions by already having exported http_proxy in my session.
I will go back and verify the facts before I change anything.
Thanks for the replies.
John Babich
On Tue, 2006-12-19 at 08:48 +0300, John Babich wrote:
On 12/19/06, Paul W. Frields stickster@gmail.com wrote:
What, exactly, did you experience or observe? I have the first usage in my /etc/yum.conf and it works. I just did a "yum clean all" and everything worked as expected with my squid proxy. (I am tunneling it through SSH, but that shouldn't matter in this case.)
This is where it gets tricky. I guess the good thing about filing a bug report is that, if done correctly, the filer should verify the bug and explain the context in as much detail as possible.
Yes, to the meta-point in this discussion, this is the advantage of filing a bug report. We could add the yum developer to resolve the question, for example. Attach patches of suggested fixes, such as admonition that covers your situation. Etc.
But how do we cover this in the case of e.g. one writer and another needing to discuss and dispute technical content? Our workflow should allow for informal channels of discussion, and give some suggestions about when to break out of informality into something more formal (difficult to use) but useful (can drag in more people). Also, informal discussions should probably happen on-list, so we all benefit/critique.
- Karsten
-
John Babich -
Karsten Wade -
Paul W. Frields