Comments on: praise git http://iquaid.org/2008/11/07/praise-git/ ... the four laws of humanity ... Mon, 23 Jan 2012 20:07:59 +0000 hourly 1 http://wordpress.org/?v=3.3 By: quaid http://iquaid.org/2008/11/07/praise-git/comment-page-1/#comment-2650 quaid Mon, 17 Nov 2008 10:12:32 +0000 http://iquaid.org/?p=222#comment-2650 I think you disagree because you've never been involved in the process of converting from the wiki to XML. ;-P The timeframe that is under discussion here is a small window from when we build the fedora-release-notes package for the Preview Release to when we freeze content changes for GA. This timeframe is about seven days, and it actually occurs after the fedora-release-notes package is out in the PR. Up until the release of that package, it makes sense to do all work in the upstream source (a.k.a. the wiki.) Once that package is out, there is a lot of work going on during that one week. It has continuously proved to be difficult to pull from the wiki during that time. As soon as we get a section complete, more changes come in, often very raw language that requires the full treatment that the rest of the notes got all month. We honestly haven't decided what the process is going to be next time; we just needed a solution this time to stem the bleeding. We've always done a good job of allowing people to make content changes as close as possible to the various stages of release. We have to balance that against the historical record of how many people make such last hour changes (answer: relatively few) and how disruptive it is keeping that channel open until the last hour. One surprise this time was a change in wiki behavior. I personally lost track of the release notes beats because MediaWiki turns off the watch alert for a page if you don't respond to each watch email. Unlike an issue tracker, such as Bugzilla or Trac, the wiki is not a comparatively great way to keep track of release blockers close to a release. I think you disagree because you’ve never been involved in the process of converting from the wiki to XML. ;-P

The timeframe that is under discussion here is a small window from when we build the fedora-release-notes package for the Preview Release to when we freeze content changes for GA.

This timeframe is about seven days, and it actually occurs after the fedora-release-notes package is out in the PR. Up until the release of that package, it makes sense to do all work in the upstream source (a.k.a. the wiki.) Once that package is out, there is a lot of work going on during that one week. It has continuously proved to be difficult to pull from the wiki during that time. As soon as we get a section complete, more changes come in, often very raw language that requires the full treatment that the rest of the notes got all month.

We honestly haven’t decided what the process is going to be next time; we just needed a solution this time to stem the bleeding. We’ve always done a good job of allowing people to make content changes as close as possible to the various stages of release. We have to balance that against the historical record of how many people make such last hour changes (answer: relatively few) and how disruptive it is keeping that channel open until the last hour.

One surprise this time was a change in wiki behavior. I personally lost track of the release notes beats because MediaWiki turns off the watch alert for a page if you don’t respond to each watch email. Unlike an issue tracker, such as Bugzilla or Trac, the wiki is not a comparatively great way to keep track of release blockers close to a release.

]]> By: Kevin Kofler http://iquaid.org/2008/11/07/praise-git/comment-page-1/#comment-2638 Kevin Kofler Sun, 09 Nov 2008 04:45:12 +0000 http://iquaid.org/?p=222#comment-2638 I disagree that this is an improvement over the old practice of just keeping the documentation (especially the release notes) in the wiki and converting it to XML the day of the deadline. It's easy to make a simple edit in the wiki, it's a lot more work to make it in git (and also a significant learning curve for most of the documentation writers), to the point where the recommendation [1] is to file all changes in Bugzilla rather than just committing them - hardly an efficient process. [1] http://marilyn.frields.org:8080/~paul/wordpress/?p=1272 I disagree that this is an improvement over the old practice of just keeping the documentation (especially the release notes) in the wiki and converting it to XML the day of the deadline. It’s easy to make a simple edit in the wiki, it’s a lot more work to make it in git (and also a significant learning curve for most of the documentation writers), to the point where the recommendation [1] is to file all changes in Bugzilla rather than just committing them – hardly an efficient process.

[1] http://marilyn.frields.org:8080/~paul/wordpress/?p=1272

]]>