m (Created page with '<Emad78> How do I know what "branch" to use when editing a doc. Will someone tell me exactly which one to use. <Emad78> Also I can just follow the git wiki commands to do that s...') |
mNo edit summary |
||
| Line 1: | Line 1: | ||
<Emad78> How do I know what "branch" to use when editing a doc. Will someone tell me exactly which one to use. | <Emad78> How do I know what "branch" to use when editing a doc. Will someone tell me exactly which one to use. | ||
<Emad78> Also I can just follow the git wiki commands to do that stuff? | <Emad78> Also I can just follow the git wiki commands to do that stuff? | ||
<quaid> here's the basic idea: | <quaid> here's the basic idea: | ||
<quaid> * If the bug is filed against a specific version of a document that ties to a specific version of software, so the bug is only applicable to that version of the document, then we want to fix the bug in the branch associated with that version. | <quaid> * If the bug is filed against a specific version of a document that ties to a specific version of software, so the bug is only applicable to that version of the document, then we want to fix the bug in the branch associated with that version. | ||
<quaid> typically that branc is "F-12" or | <quaid> typically that branc is "F-12" or some such. | ||
<quaid> * However, in docs it's common that the bug needs fixing in all versions, so that might mean fixing it in HEAD and then committing the same change in the other branches | <quaid> * However, in docs it's common that the bug needs fixing in all versions, so that might mean fixing it in HEAD and then committing the same change in the other branches | ||
<quaid> also, we don't support (fix) docs that are tied to a release of Fedora that is no longer supported. | <quaid> also, we don't support (fix) docs that are tied to a release of Fedora that is no longer supported. | ||
<quaid> the git guide on the wiki has most of the commands you need, I think. | <quaid> the git guide on the wiki has most of the commands you need, I think. | ||
<Emad78> Ok, so when I made all those edits on the UG, I made a bunch of changes in 4 files. Is it good to do so many changes and do one commit for all of them? | <Emad78> Ok, so when I made all those edits on the UG, I made a bunch of changes in 4 files. Is it good to do so many changes and do one commit for all of them? | ||
<quaid> it depends :) | <quaid> it depends :) | ||
| Line 23: | Line 17: | ||
<quaid> if you make big structure changes, do those first and commit, then do content changes (clean-up, typos, etc.) as a second commit | <quaid> if you make big structure changes, do those first and commit, then do content changes (clean-up, typos, etc.) as a second commit | ||
<quaid> it makes it easier for others to review the work and see the impact. | <quaid> it makes it easier for others to review the work and see the impact. | ||
<quaid> one nice thing about git, if you haven't discovered it, is that committing is easy since it's a local event; I find myself committing more often for more granular reasons because it's "cheap" and can be done offline. | <quaid> one nice thing about git, if you haven't discovered it, is that committing is easy since it's a local event; I find myself committing more often for more granular reasons because it's "cheap" and can be done offline. | ||
* quaid was a CVS and SVN user for many years and dreaded each commit. | * quaid was a CVS and SVN user for many years and dreaded each commit. | ||
<Emad78> Ok, So the proper etiquette is to ask the Doc owner before doing a bug fix then right. Cause there might be a couple fixes I can do to keep on learning> | <Emad78> Ok, So the proper etiquette is to ask the Doc owner before doing a bug fix then right. Cause there might be a couple fixes I can do to keep on learning> | ||
<quaid> it depends :) | <quaid> it depends :) | ||
<quaid> you can put a note in the bug report that you'd like to fix it, or go ahead and show the fix. | <quaid> you can put a note in the bug report that you'd like to fix it, or go ahead and show the fix. | ||
<quaid> if you've been given commit rights to the doc repository by the doc owner | <quaid> if you've been given commit rights to the doc repository by the doc owner | ||
| Line 37: | Line 29: | ||
<quaid> remember -- source control management means never having to say you are sorry | <quaid> remember -- source control management means never having to say you are sorry | ||
<quaid> if your fix doesn't work, it can be backed out, or more likely, just tweaked in the next commit. | <quaid> if your fix doesn't work, it can be backed out, or more likely, just tweaked in the next commit. | ||
<Emad78> I'm usually full of them, so I never know when they pop up. | <Emad78> I'm usually full of them, so I never know when they pop up. | ||
teachingopensource.org | |||
<quaid> Emad78: one nice thing about IRC is the asynchronous nature of it | <quaid> Emad78: one nice thing about IRC is the asynchronous nature of it | ||
<quaid> I leave my client running all the time in a way I can detach from, so if you ask questions or comment | <quaid> I leave my client running all the time in a way I can detach from, so if you ask questions or comment | ||
| Line 54: | Line 45: | ||
<quaid> because we are "just like" coding projects, even non-docs team participants might know the right answer, etc. | <quaid> because we are "just like" coding projects, even non-docs team participants might know the right answer, etc. | ||
<Emad78> Yeah, and I figured these were pretty easy to answer. And since I was on here I thought I would see if anyone was around. | <Emad78> Yeah, and I figured these were pretty easy to answer. And since I was on here I thought I would see if anyone was around. | ||
<quaid> since the textbook I'm working on includes this sort of material, I'll likely reference it to the list later, see if it's useful to newer contributors, etc. | <quaid> since the textbook I'm working on includes this sort of material, I'll likely reference it to the list later, see if it's useful to newer contributors, etc. | ||
<Emad78> Yeah that's true. Maybe if I gather a bunch of new contributor questions I can email the list. You think we could do a new contributor FAQ type thing?? | <Emad78> Yeah that's true. Maybe if I gather a bunch of new contributor questions I can email the list. You think we could do a new contributor FAQ type thing?? | ||
<laubersm> Emad78, you can just start creating one in the wiki ;) | <laubersm> Emad78, you can just start creating one in the wiki ;) | ||
<laubersm> Thanks quaid for answering... I'm not really here yet... been busier than I thought for the day | <laubersm> Thanks quaid for answering... I'm not really here yet... been busier than I thought for the day | ||
| Line 68: | Line 60: | ||
<laubersm> Emad78, keep making notes. we will eventually get to them. | <laubersm> Emad78, keep making notes. we will eventually get to them. | ||
* laubersm is off to finish other stuff now... | * laubersm is off to finish other stuff now... | ||
<quaid> Emad78: there's a cultural thing in FLOSS about "annoying newbies", both from the perspective of the experienced contributor and the person who may feel like an annoying newbie! | <quaid> Emad78: there's a cultural thing in FLOSS about "annoying newbies", both from the perspective of the experienced contributor and the person who may feel like an annoying newbie! | ||
<quaid> https://www.theopensourceway.org/wiki/Stuff_everyone_knows_and_forgets_anyway#Turn_annoying_newbies_in_to_instant_contributors_with_the_power_of_To_Document | <quaid> https://www.theopensourceway.org/wiki/Stuff_everyone_knows_and_forgets_anyway#Turn_annoying_newbies_in_to_instant_contributors_with_the_power_of_To_Document | ||
| Line 77: | Line 70: | ||
<quaid> you can actually construct the whole thing there, then 'move' it later to [[Docs new contributor FAQ]] | <quaid> you can actually construct the whole thing there, then 'move' it later to [[Docs new contributor FAQ]] | ||
<Emad78> Well ok then, on to being a "contributor" then. Thanks laubersm ;) | <Emad78> Well ok then, on to being a "contributor" then. Thanks laubersm ;) | ||
<Emad78> quaid: This (theopensourceway.org) is a good read. | <Emad78> quaid: This (theopensourceway.org) is a good read. | ||
Revision as of 22:31, 27 March 2010
<Emad78> How do I know what "branch" to use when editing a doc. Will someone tell me exactly which one to use. <Emad78> Also I can just follow the git wiki commands to do that stuff?
<quaid> here's the basic idea: <quaid> * If the bug is filed against a specific version of a document that ties to a specific version of software, so the bug is only applicable to that version of the document, then we want to fix the bug in the branch associated with that version. <quaid> typically that branc is "F-12" or some such. <quaid> * However, in docs it's common that the bug needs fixing in all versions, so that might mean fixing it in HEAD and then committing the same change in the other branches <quaid> also, we don't support (fix) docs that are tied to a release of Fedora that is no longer supported. <quaid> the git guide on the wiki has most of the commands you need, I think.
<Emad78> Ok, so when I made all those edits on the UG, I made a bunch of changes in 4 files. Is it good to do so many changes and do one commit for all of them? <quaid> it depends :) <quaid> are they all a fix for one bug report? <quaid> if so, one commit is fine <quaid> one per bug report is a good measure <quaid> another example of where to split: <quaid> if you make big structure changes, do those first and commit, then do content changes (clean-up, typos, etc.) as a second commit <quaid> it makes it easier for others to review the work and see the impact. <quaid> one nice thing about git, if you haven't discovered it, is that committing is easy since it's a local event; I find myself committing more often for more granular reasons because it's "cheap" and can be done offline.
- quaid was a CVS and SVN user for many years and dreaded each commit.
<Emad78> Ok, So the proper etiquette is to ask the Doc owner before doing a bug fix then right. Cause there might be a couple fixes I can do to keep on learning> <quaid> it depends :) <quaid> you can put a note in the bug report that you'd like to fix it, or go ahead and show the fix. <quaid> if you've been given commit rights to the doc repository by the doc owner <quaid> you have already been given what you need to make your own decision - if you think you have it (or even may have it), do the fix and commit it. <quaid> you can note in the bug report that you made a commit (link) and think it fixes the bug., if so, please close. <quaid> of course, if you keep doing that, you'll end up with bugs assigned to you :) <quaid> remember -- source control management means never having to say you are sorry <quaid> if your fix doesn't work, it can be backed out, or more likely, just tweaked in the next commit.
<Emad78> I'm usually full of them, so I never know when they pop up. teachingopensource.org <quaid> Emad78: one nice thing about IRC is the asynchronous nature of it <quaid> I leave my client running all the time in a way I can detach from, so if you ask questions or comment <quaid> I see it later and reply <Emad78> Yes this is way easier than emailing a ton to you. <quaid> we have discussions that span timezones and never even be together in the channel at the same time <quaid> right, but it misses some of the value of mailing lists -- it's a balance <Emad78> I hear ya. <quaid> for example, in the mailing list many more get to read the above advice; but it can be inconvenient for every little thing <quaid> anyway, don't be afraid to leave questions in the channel and see who answers :) <quaid> because we are "just like" coding projects, even non-docs team participants might know the right answer, etc. <Emad78> Yeah, and I figured these were pretty easy to answer. And since I was on here I thought I would see if anyone was around.
<quaid> since the textbook I'm working on includes this sort of material, I'll likely reference it to the list later, see if it's useful to newer contributors, etc. <Emad78> Yeah that's true. Maybe if I gather a bunch of new contributor questions I can email the list. You think we could do a new contributor FAQ type thing??
<laubersm> Emad78, you can just start creating one in the wiki ;) <laubersm> Thanks quaid for answering... I'm not really here yet... been busier than I thought for the day <laubersm> and I have a few more things to do before dark. Then one other chapter to review before I can dig into the UG stuff. <laubersm> My *plan* (that is failing miserably so far) was to see what had to be done so I could get a task list going somewhere (trac or wiki depending on what I find) <Emad78> laubersm: I would need some direction in starting something like that on the wiki. <laubersm> Emad78, is doing a great job killin goff the bugs! <laubersm> Emad78, can do - just not for at least another couple of hours. <laubersm> others might be able to help sooner (hint hint quaid) <Emad78> laubersm: Oh no it doesn't have to be right now. But SOON would be good. <laubersm> Emad78, keep making notes. we will eventually get to them.
- laubersm is off to finish other stuff now...
<quaid> Emad78: there's a cultural thing in FLOSS about "annoying newbies", both from the perspective of the experienced contributor and the person who may feel like an annoying newbie! <quaid> https://www.theopensourceway.org/wiki/Stuff_everyone_knows_and_forgets_anyway#Turn_annoying_newbies_in_to_instant_contributors_with_the_power_of_To_Document <quaid> that's what laubersm just did to you :) <quaid> which I was also considering, so I'm happy to help get that flow <quaid> for super-easy you might want to make a page in your personal "sandbox" on the wiki, that is, the pages under your user name: <quaid> User:Emad78/New_Docs_contributor_FAQ_dump <quaid> then copy and paste our discussion from above in to there as a quick grab and reminder :) <quaid> you can actually construct the whole thing there, then 'move' it later to Docs new contributor FAQ <Emad78> Well ok then, on to being a "contributor" then. Thanks laubersm ;) <Emad78> quaid: This (theopensourceway.org) is a good read.