Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am in need of preparing powerpoint slides to discuss Trac Workflow.
I caught hold of "One Laptop per Child" (olpc) Trac Workflow and impressed by the workflow it follows.Can anyone Help me with this:
Code:
1. Do olpc follows default workflow which trac comes with default?
2. Any links or hint where I can find resources for further explanation of each roles of Maintainer,coder,builder,releaser etc..
1. Do olpc follows default workflow which trac comes with default?
No, it is a customized workflow.
Quote:
2. Any links or hint where I can find resources for further explanation of each roles of Maintainer,coder,builder,releaser etc..
The explanations at http://wiki.laptop.org/go/Trac_ticket_workflow seem pretty self-explanatory. If not, you'll need to do some reading, particularly about the various forms of SDLC (software development life cycle).
My Team has agreed with olpc Concept. I have also created a Powerpoint Slides for the same.
Main Emphasis:
Code:
Characters
Anonymous Alice -- generic (possibly minimally skilled) Trac user.
Terry Ticket-Herder -- ticket herder who watches incoming tickets and improves their quality.
Carol Coder -- coder who diagnoses, designs, codes, and reviews code.
Mark Maintainer -- module maintainer (packager) aggregates code and pushes it into build streams (i.e. into Fedora or Joyride).
Release Rob -- release team member who approves requests to modify a stable build stream.
Bill Builder -- build team member
Quality Assurance -- QA team member
[edit] Story
Anonymous Alice observed curious behavior while exploring the system. She records it in Trac but does not set the next_action field or sets it to unknown.
Terry Ticket-Herder decides Alice's reported behavior is significant but doesn't know how to reproduce it so he changes the next_action to reproduce to indicate his need for instructions on how to reproduce the issue.
Terry might instead have closed Alice's ticket as invalid, worksforme, etc or have sent it on to a later state if Alice wrote a particularly good ticket.
If necessary, Terry would also fill in the Milestone, Component, Keywords, and CC fields to conform to our Trac conventions.
Once Alice's behavior can be reproduced, it can be diagnose[d] by Carol Coder (probably with help from Alice).
Carol will eventually propose a design that she thinks will resolve the issue.
Carol will code to her design and will seek review of her work. She will also write a testcase.
When all is in order, Carol or Mark Maintainer will package the changes and add them to a development build (in the add to build state).
When built in Joyride, Carol or Mark will test in build.
If the test fails, then the tester may remand the issue to an earlier state and owner; otherwise, the tester should advance the ticket to the next state (see below).
Test results should be recorded according to the Trac conventions (e.g as a keyword like joyride-2230:+ for a 'pass' or 8.2-757:- for a 'fail').
During change control, changes must pass through three additional steps:
Changes cannot be committed to the stable build stream without meeting basic requirements. Release Rob will regularly review tickets in the approval for release state.
Approved changes will be sent to the Bill Builder in the add to release state.
Once Bill updates the stable build stream, he will place the ticket in the test in release state for further testing by Alice, Carol, or another friend.
After being tested as fixed in a release-stream build, issues should be pushed through some of the qa signoff, finalize, or no action states. See below.
Occasionally, an issue may require test facilities beyond those available to ordinary developers and testers or may be so important that it requires additional systematic testing. Such issues can be pushed, at anyone's discretion, through the qa signoff state where Quality Assurance will examine them and pass them on.
Rob will document tickets which reach the finalize state in the Release Notes.
Tickets will eventually require no action.
Rob is responsible for closing user-facing issues which result in changes to the build or work-arounds.
Other issues can be closed by anyone when they cease to be relevant to the release proces
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.