Monty Taylor: Bugs vs Blueprints
Launchpad has two facilities for filing tasks that need to be done in a source tree, Bugs and Blueprints. I've spoken to folks who think the two should be collapsed in to one thing, and folks who think they need to remain separate. I'm in the latter camp, so I thought I'd weigh in real quick with a quick explanation of what I think the difference between the two is. Whether they are fundamentally the same object in the backend object model is irrelevant to me - I'm talking about developer workflow and thought.
In my view, it's really simple:
- A Bug is a record of something that needs to be done - the what
- A Blueprint is a record of how something will be done - the how
If you accept that premise, then you can have a task that has both a bug and a blueprint associated with it. Or you could have a bug with no blueprint (sometimes stating the problem implies the solution) It makes less s! ense to have a blueprint without a bug - but we do this as a shortcut often times because launchpad doesn't have an automatic 'create a bug for this' feature for blueprints. On the other hand, many of the blueprints the Ubuntu project works with during UDS planning aren't really things with bugs - unless you consider them all to be hows of solving bug#1. Or perhaps there is a missing or merely implied definition of the what for many of them, which might mean that the discussion of how meanders for a little bit.
I think the current structure of blueprints backs me up here. It is intended that a blueprint have a wiki page (implying that perhaps the information might be longer in form) and blueprints have a wonderful dependency graphing feature - which is quite useful for project planning ... "to accomplish this (bug#1) I'm going to do this (blueprint#1) which depends on these other things being done first (blueprint#2 and blueprint#3)"
Additionally, blue! prints having an associated wiki page implies that anything with a blu eprint is something that should turn in to documentation. If you're writing up a description of how you're going to do something, then perhaps that means when you're done you've written a description of how or why you actually did something, which is sort of what internals documentation is, right?
Now - can things be better with blueprints? Of course. There was discussion at the last UDS of having blueprints have a merge-request style discussion/approval process, which I would whole-heartedly approve of. Additionally, the wiki element could be baked in to the blueprint, and bzr branchable.
But I strongly believe that both serve a strong and fundamentally different purpose.
URL: http://inaugust.com/post/80
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
