On Wed, 2010-11-24 at 10:22 -0500, Eric "Sparks" Christensen wrote: > It isn't that cumbersome. It would take me less than a minute to post a > patch on BZ. I challenge you to do ANYTHING in BZ in a minute. But posting the patch seems silly. Post the commmit. You need the commit anyway to identify the particular commit that was QAed. > But once the change is in the repo it is too late. You shouldn't commit > a change before it is QA'd. If the change is in the repo then there is > a high chance that the change will make it to the final guide without > being checked. No, no, no. The whole point of a repo like git is to make working collaboratively easy. For that to work you need to commit frequently. The idea that somehow what is in the repo is sacred is a view that makes working together hard. Sure, it may have held some sway back in the RCS days before collaborative RCSs were available, or maybe even with CVS where doing anything is so bloody hard and fraught with risk, but wit git there is no argument not to commit, certainly not if you have a way to identify QAed commits. For a lot of the guides you can get away with it because there is only one person working on the guide. If more than one are working at the same time you absolutely must commit frequently or you stand the risk of tripping all over each other. > The pending list already exists... it's called BZ. It only exists if you go through all the extra manual steps. And finding what you want to publish could be a real challenge. Sure, for QA its easy, just search on open bugs with a QA needed tag. But when you want to publish something, you will be looking in closed bugs which eventually will get to be quite a list. And how do you know what release? Do you go searching through all the commits until you find the matching patch? > When was the last time you tried to roll back an edit that was made > several pushes ago? I fail to see what's so tough about git checkout QA-DONE-17 or whatever. The only messy bit I see is that you would probably want to keep the history of QAed commits, so each completed QA would want to have a new name, probably a serial number. I could see multiple QA requests as well, although I see less need for keeping the history. > I'm good with 2-4. I hadn't really thought about doing something like > this. I don't know that this is possible in SVN, though. It is. Of course, like everything in SVN it's slower and more complicated, but the tagging idea is pretty similar. It's just that SVN has no concept of a global commit, so the author has to be careful to tag a complete, coherent set of commits. > nb? That was the first thought that came to my mind. > Well, I was talking more about a tag that isn't there but should/could > be and not a broken tag. I hadn't thought about that. That could be a big win. --McD -- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
