One of my tasks has been to review the schedule. Of course, we all should be looking at it. I've been struggling some to make sense of it. There are a couple of issues, but even a few issues can make it very confusing.
You should all be aware that John has posted the schedule at
http://poelstra.fedorapeople.org/schedules/f-14/
If you look at f-14-docs-tasks.html it can be very confusing since release notes, announcements and guides tasks are all mixed together. The report, f-14-docs-tree-tasks.html is a lot easier to digest. Until you have your head around that one, the docs combined with translation and releng are totally confusing, so look at the tree tasks first.
It is a pity that you don't seem to be able to get a Gantt chart out of taskjuggler, but if you download the two files from John's "source" directory (f-14.tjp and reports.tji) and open them up in taskjuggler, you can see the dependencies in the source. To do that:
1) Select the tasks tab on the left 2) Highlight the task you wish to examine (note that in general the tasks are folded into higher level tasks) 3) The task will be highlighted in the source on the right, and if there is a dependency, it will say "depends" on the right under the highlighted task name
It still isn't super-simple since Docs is only a tiny part of the whole release, and of the hundreds of "external to docs" tasks, there are perhaps a dozen that actually matter to us directly, and they don't always show up within the folded group (e.g. Beta Release Notes), so it isn't always obvious why a particular task has to happen on a particular day without a fair amount of digging.
Rudi and I will be getting updates to John, so if you notice anything that seems out of place please let us know.
Thanks, --McD
On Mon, Jun 21, 2010 at 09:07:53 -0400, "John J. McDonough" wb8rcr@arrl.net wrote:
It is a pity that you don't seem to be able to get a Gantt chart out of taskjuggler, but if you download the two files from John's "source" directory (f-14.tjp and reports.tji) and open them up in taskjuggler, you can see the dependencies in the source. To do that:
It should be possible to do that. Documentation related to this is at: http://www.taskjuggler.org/manual-2.4.3/generating_reports_of_the_scheduled_...
John J. McDonough said the following on 06/21/2010 06:07 AM Pacific Time:
One of my tasks has been to review the schedule. Of course, we all should be looking at it. I've been struggling some to make sense of it. There are a couple of issues, but even a few issues can make it very confusing.
I'd love to help make it less confusing. This is the first time I've heard it was a problem.
You should all be aware that John has posted the schedule at
http://poelstra.fedorapeople.org/schedules/f-14/
If you look at f-14-docs-tasks.html it can be very confusing since release notes, announcements and guides tasks are all mixed together. The report, f-14-docs-tree-tasks.html is a lot easier to digest. Until you have your head around that one, the docs combined with translation and releng are totally confusing, so look at the tree tasks first.
It is a pity that you don't seem to be able to get a Gantt chart out of
It is a pity someone never asked :)
taskjuggler, but if you download the two files from John's "source" directory (f-14.tjp and reports.tji) and open them up in taskjuggler, you can see the dependencies in the source. To do that:
- Select the tasks tab on the left
- Highlight the task you wish to examine (note that in general the tasks are folded into higher level tasks)
- The task will be highlighted in the source on the right, and if there is a dependency, it will say "depends" on the right under the highlighted task name
It still isn't super-simple since Docs is only a tiny part of the whole release, and of the hundreds of "external to docs" tasks, there are perhaps a dozen that actually matter to us directly, and they don't always show up within the folded group (e.g. Beta Release Notes), so it isn't always obvious why a particular task has to happen on a particular day without a fair amount of digging.
Rudi and I will be getting updates to John, so if you notice anything that seems out of place please let us know.
Thanks, --McD
It is disappointing and counter productive to see posts like this complaining about how hard it is to use what you've been given when to my knowledge you've never specifically requested what you need to make your job easier.
What were you hoping people would take away from this post beyond "the schedule is too hard to read and we'll be sending changes to John" ?
John
On Mon, 2010-06-21 at 11:57 -0700, John Poelstra wrote:
It is disappointing and counter productive to see posts like this complaining about how hard it is to use what you've been given when to my knowledge you've never specifically requested what you need to make your job easier.
What were you hoping people would take away from this post beyond "the schedule is too hard to read and we'll be sending changes to John" ?
John,
It wasn't my intent to be negative towards you at all, indeed, the more I dig the happier I am that you are doing the heavy lifting and not me.
I am going through the schedule, trying to sort out the issues. And, as in previous releases, there are fewer issues than the release before. The challenge is that most of the issues are non-obvious. Even when you are pretty intimate with the process, it is hard to catch the disconnects. I thought if a few more folks would get their eyes on it we would miss fewer things.
Getting your head around a project this big is hard, really hard, as you know better than anyone. Since I (supposedly) understand the Docs processes, I view the disconnects as much more my problem than yours.
From a Docs perspective, F13 went really well. I'd like to see F14 go
ever better. So yeah, I'm being really picky.
Taskjuggler is in no way easy to use, but with a project this size, neither is anything else. I was simply hoping to draw more eyes, so Rudi and I can come to you with a concise set of corrections just once (we were tasked with that a couple of meetings ago). I appreciate the hard work you have done, and I thought if we could get the Docs part sorted amongst us girls before we bothered you with it, we wouldn't need to keep cycling back, chewing up your time. I would like to see this coming release be perfect. We really are pretty close.
--McD
I am going through the schedule, trying to sort out the issues. And, as in previous releases, there are fewer issues than the release before. The challenge is that most of the issues are non-obvious. Even when you are pretty intimate with the process, it is hard to catch the disconnects. I thought if a few more folks would get their eyes on it we would miss fewer things.
During the Fedora 12 release I remember having a confrence call about the schedule because we were trying to fix some issues. This process was very benificial to me, being able to talk about what needed done when rather then just looking at a list was a great help. Maybe this is something that we could look into doing again. It may not be for the same reasons as last time, but the more communication we have the better.
Zach Oglesby said the following on 06/22/2010 01:02 AM Pacific Time:
I am going through the schedule, trying to sort out the issues. And, as in previous releases, there are fewer issues than the release before. The challenge is that most of the issues are non-obvious. Even when you are pretty intimate with the process, it is hard to catch the disconnects. I thought if a few more folks would get their eyes on it we would miss fewer things.
During the Fedora 12 release I remember having a confrence call about the schedule because we were trying to fix some issues. This process was very benificial to me, being able to talk about what needed done when rather then just looking at a list was a great help. Maybe this is something that we could look into doing again. It may not be for the same reasons as last time, but the more communication we have the better.
I'm willing to do whatever is needed to help produce the best schedule possible for Fedora 14--including creating special reports or having a conference call. Let me know what you need or how you would like to proceed.
John P
On Tue, 2010-06-22 at 09:01 -0700, John Poelstra wrote:
I'm willing to do whatever is needed to help produce the best schedule possible for Fedora 14--including creating special reports or having a conference call. Let me know what you need or how you would like to proceed.
John P
John
I appreciate that, and I expect that we may be able to do with a couple of emails, depending on what L10N runs into on their side of the schedule. I think there are only minor issues, and we won't need the extended effort we made for F12 and F13.
Bruno Wolff's note yesterday gave me an important insight; taskjuggler is a command-line tool with a GUI, much like git, and not an extremely lame GUI tool. With that bit of insight, I am right now getting the kind of examination I would like, and getting it quite easily.
--McD
John J. McDonough said the following on 06/22/2010 10:45 AM Pacific Time:
On Tue, 2010-06-22 at 09:01 -0700, John Poelstra wrote:
I'm willing to do whatever is needed to help produce the best schedule possible for Fedora 14--including creating special reports or having a conference call. Let me know what you need or how you would like to proceed.
John P
John
I appreciate that, and I expect that we may be able to do with a couple of emails, depending on what L10N runs into on their side of the schedule. I think there are only minor issues, and we won't need the extended effort we made for F12 and F13.
Bruno Wolff's note yesterday gave me an important insight; taskjuggler is a command-line tool with a GUI, much like git, and not an extremely lame GUI tool. With that bit of insight, I am right now getting the kind of examination I would like, and getting it quite easily.
--McD
Yes, TaskJuggler has the illusion of being a GUI scheduling tool like Microsoft Project or GanttProject which it is not. It is better thought of as an IDE.
I'm still not following the logic of this thread :) Be bold, ask for exactly what you need to make your work easier!
Attached is a gantt chart for the Docs Team and another combining Docs and Translation. Generating this chart is a hack I should probably blog about.
John
On Wed, 2010-06-23 at 06:16 -0700, John Poelstra wrote:
Yes, TaskJuggler has the illusion of being a GUI scheduling tool like Microsoft Project or GanttProject which it is not. It is better thought of as an IDE.
I'm still not following the logic of this thread :) Be bold, ask for exactly what you need to make your work easier!
Attached is a gantt chart for the Docs Team and another combining Docs and Translation. Generating this chart is a hack I should probably blog about.
** Docs folks please review attached PDFs **
John
I've been able to go one better, a single page Gantt for each of the major pieces, which I have been bleeding on and hope to talk about at the meeting tonight. When there are only a relative few tasks, it is easier to get your head around, and there aren't interdependencies between guides and release notes, and really only one between beta and GA. When you can print it out on a single page it is a lot easier to deal with and sit and scratch your head over.
What I have found so far, as I said, are real fine points: 1) One or two places where I think we could benefit from an additional notification 2) A couple of places where some wording changes might be helpful 3) One place where something in beta belongs in GA
I'm not entirely sure I'm happy with beta. Still some noodling to do.
Gantts attached - Docs folks please look over if you can before the meeting tonight.
We'll run these by the team tonight and see what I'm overlooking.
--McD
John,
I would like to propose the following changes to the Release Notes schedule. Rudi is taking point on the Guides part of the schedule:
Add to alpha Validate former beat writers 10 days before "Start Alpha Beat and Feature page Review" Elapsed time 5 days note "Check that beat writers for previous release are willing to contribute to the current release" Recruit new beat writers After "Validate Beat Writers" Elapsed time 5 days note "Identify unmanned beats and recruit contributors to handle those beats" Notify Devel alpha release notes 5 days before "Comb Beats and Feature Pages for Alpha" Elapsed time 0 note "Send notification to devel list that work on alpha release notes is starting and developers wishing to be mentioned should consider commenting in the appropriate beat as well as having feature page complete"
Beta changes "Port Wiki to Publican" should extend one day past "Wiki Freeze" "Reminder to development: wiki freeze in 7 days" Should be part of GA release notes, not beta "Build and post release-notes to docs.fedorahosted.org" Change description to: "Build and post beta release notes to docs.fedoraproject.org" Add "Build and post Fedora Technical Notes to docs.fp.o" Same date as "Build and post beta release notes to docs.fedoraproject.org" Change description "Build fed-rel-notes.rpm for Beta Release" to "Build f-r-n.rpm and push to updates-candidate" note "fedora-release-notes.rpm needed for nightly compose"
GA Changes add "Update and post Fedora Technical Notes to docs.fp.o" Same date as "Final (GA) Release"
Thanks --McD
John J. McDonough said the following on 06/28/2010 08:28 AM Pacific Time:
John,
I would like to propose the following changes to the Release Notes schedule. Rudi is taking point on the Guides part of the schedule:
Add to alpha Validate former beat writers 10 days before "Start Alpha Beat and Feature page Review" Elapsed time 5 days note "Check that beat writers for previous release are willing to contribute to the current release" Recruit new beat writers After "Validate Beat Writers" Elapsed time 5 days note "Identify unmanned beats and recruit contributors to handle those beats" Notify Devel alpha release notes 5 days before "Comb Beats and Feature Pages for Alpha" Elapsed time 0 note "Send notification to devel list that work on alpha release notes is starting and developers wishing to be mentioned should consider commenting in the appropriate beat as well as having feature page complete"
Beta changes "Port Wiki to Publican" should extend one day past "Wiki Freeze" "Reminder to development: wiki freeze in 7 days" Should be part of GA release notes, not beta "Build and post release-notes to docs.fedorahosted.org" Change description to: "Build and post beta release notes to docs.fedoraproject.org" Add "Build and post Fedora Technical Notes to docs.fp.o" Same date as "Build and post beta release notes to docs.fedoraproject.org" Change description "Build fed-rel-notes.rpm for Beta Release" to "Build f-r-n.rpm and push to updates-candidate" note "fedora-release-notes.rpm needed for nightly compose"
GA Changes add "Update and post Fedora Technical Notes to docs.fp.o" Same date as "Final (GA) Release"
Thanks --McD
Got it. I'm planning to have these changes in by the end of the week and will send email when they are done.
John
John J. McDonough said the following on 06/28/2010 08:28 AM Pacific Time:
John,
I would like to propose the following changes to the Release Notes schedule. Rudi is taking point on the Guides part of the schedule:
Add to alpha Validate former beat writers 10 days before "Start Alpha Beat and Feature page Review" Elapsed time 5 days note "Check that beat writers for previous release are willing to contribute to the current release" Recruit new beat writers After "Validate Beat Writers" Elapsed time 5 days note "Identify unmanned beats and recruit contributors to handle those beats" Notify Devel alpha release notes 5 days before "Comb Beats and Feature Pages for Alpha" Elapsed time 0 note "Send notification to devel list that work on alpha release notes is starting and developers wishing to be mentioned should consider commenting in the appropriate beat as well as having feature page complete"
Beta changes "Port Wiki to Publican" should extend one day past "Wiki Freeze" "Reminder to development: wiki freeze in 7 days" Should be part of GA release notes, not beta "Build and post release-notes to docs.fedorahosted.org" Change description to: "Build and post beta release notes to docs.fedoraproject.org" Add "Build and post Fedora Technical Notes to docs.fp.o" Same date as "Build and post beta release notes to docs.fedoraproject.org" Change description "Build fed-rel-notes.rpm for Beta Release" to "Build f-r-n.rpm and push to updates-candidate" note "fedora-release-notes.rpm needed for nightly compose"
GA Changes add "Update and post Fedora Technical Notes to docs.fp.o" Same date as "Final (GA) Release"
Thanks --McD
All updates have been made. Please let me know if I missed something or there are any other changes you'd like to make.
http://poelstra.fedorapeople.org/schedules/f-14/f-14-docs-tasks.html http://poelstra.fedorapeople.org/schedules/f-14/f-14-docs-tree-tasks.html
John
Greetings Docs team. The Software Management Guide is now available to receive translations [1], but it seems to be a little outdated. Some of its contents are relevant and have been incorporated into the User Guide, and some of them are no longer useful (like instructions on how to use programs like Pirut and Pup, which no longer exists). So, my question is: Do we need this guide? Maybe so: It's a nice, short, simple book, perfect for new Fedora users who want to start messing around with the command line. Perhaps I'm wrong, but this is the only guide where we explain what a repo is, and how to set them up. Maybe we can add some content here, like how to deal with the conflicts between active repositories, or explain which the yum options are, what they do exactly, and some sort of tips like that. I don't mind grabbing the torch to start updating this guide, if you all think that its a good idea of course. But I will need guidance. I mean, I'm not quite familiar with Publican and DocBook, but I'm more than willing to learn. Looking forward to your comments, see you around, Daniel Cabrera (es)
[1] http://translate.fedoraproject.org/projects/p/docs-software-management-guide...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/24/2010 06:30 PM, daniel cabrera wrote:
Greetings Docs team. The Software Management Guide is now available to receive translations [1], but it seems to be a little outdated. Some of its contents are relevant and have been incorporated into the User Guide, and some of them are no longer useful (like instructions on how to use programs like Pirut and Pup, which no longer exists). So, my question is: Do we need this guide? Maybe so: It's a nice, short, simple book, perfect for new Fedora users who want to start messing around with the command line. Perhaps I'm wrong, but this is the only guide where we explain what a repo is, and how to set them up. Maybe we can add some content here, like how to deal with the conflicts between active repositories, or explain which the yum options are, what they do exactly, and some sort of tips like that. I don't mind grabbing the torch to start updating this guide, if you all think that its a good idea of course. But I will need guidance. I mean, I'm not quite familiar with Publican and DocBook, but I'm more than willing to learn. Looking forward to your comments, see you around, Daniel Cabrera (es)
[1] http://translate.fedoraproject.org/projects/p/docs-software-management-guide...
Daniel, Feel free to take on this project of updating this guide. It would be a great help! And don't feel like you are on your own, either. If you have any questions about the content or about DocBook and Publican please bring it to IRC (#fedora-docs) or here on the list. If you need any additional permissions for committing just let us know here on the list and we'll get you taken care of.
Thanks for offering to work on updating this guide. It is a good guide to have but is just very stale currently.
- --Eric
docs@lists.stg.fedoraproject.org
-
Bruno Wolff III -
Daniel Cabrera -
Eric Christensen -
John J. McDonough -
John Poelstra -
Zach Oglesby