Opened 16 years ago
Last modified 15 years ago
#289 new task
Finish Bellatrix Milestone
| Reported by: | bknecht | Owned by: | nobody |
|---|---|---|---|
| Priority: | trivial | Milestone: | |
| Component: | misc | Version: | |
| Keywords: | Cc: | ||
| Referenced By: | References: |
Description
Bellatrix or version 0.2 of Orxonox should be finished since last summer. Finishing the Milestone does not involve coding but rather a redistribution of tickets.
- Tickets which involve stuff we never even started last summer should be moved to a future milestone (Castor or Future Features).
- Tasks done or partly done until last summer should be closed and if necessary a new ticket should be created consisting of the remaining part of the task. This new ticket should be moved to a future milestone (Castor or Future Features).
You should end up with a finished milestone and maybe some new tickets in other milestones.
Change History (3)
comment:1 follow-up: ↓ 2 Changed 16 years ago by rgrieder
comment:2 in reply to: ↑ 1 Changed 16 years ago by bknecht
Well the original purpose of a milestone is to group tickets together and set a global deadline for those tickets. In this sense we decided to create a milestone for every semester as the PPS students need to finish their projects during that time. Of course one should normally not edit a milestone in the proposed fashion, because this totally defies its purpose. However the milestone has not been created correctly, as we should only have those tickets in the milestone which are really worked on.
I don't know who this 'we' is who decided on the versions only. About the versions we decided that we increment the sub-version number per semester (that's why each milestone has a version number as well). The subsub-version number has been introduced for planned merges during the semester as it is recommended to merge early to find merge bugs early as well (see present problem with the presentation bug).
So the versions and the milestones go hand in hand and are incremented the same way. You might noticed that we should have reached version 0.3 by now, as we finished the third semester since starting from scratch. I have forgotten to add more versions to the trac-admin, which I will do as soon as I get home.
I'm refering on decisions we made in the think tank meeting one and a half years ago.
comment:3 Changed 15 years ago by rgrieder
We could in fact go with one milestone per semester. At the beginning of a new semester, when every student has his ticket, we would create a new milestone and assign those tickets to it. The problem is just that we'll probably never finish a milestone then because at least one ticket will not be finished, I'm pretty sure. But we could reassign tickets.
So milestones provide simple deadlines and maybe help scheduling though we're probably too few people to make real use of milestones. And remember what Douglas Adams said about deadlines 
What about postponing that milestone? Does it really make sense to edit every ticket just that we have a new milestone?
And btw. we decided to go for versions only, we don't want to complicate things. Also I took the liberty of adjusting the bellatrix milestone (before that version decision however).