<br><br><div class="gmail_quote">2009/7/17 Andy Allan <span dir="ltr"><<a href="mailto:gravitystorm@gmail.com">gravitystorm@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
</div>That's practically an argument for keeping them separate in the first place.<br>
<br>
For the same reason that we have trac for software bugs (we don't get<br>
people to add new bug reports in comments into the source files) we<br>
shouldn't put bugs directly into the geodata. Next thing we'd be doing<br>
something horrid to the tags so that I can reply to a bug saying<br>
"bug:151234:gravitystorm:20090715=I've been there, but it looks fine<br>
to me" and then building tools to parse all that stuff.<br>
<br>
The geodata tables are for geodata. We're already trying to prise the<br>
non-geodata tags out of the geodata (e.g. putting created_by on<br>
changesets). Lets not take five steps backwards by putting bugs in as<br>
nodes/ways/relations.<br>
<div><div></div><br></div></blockquote></div><br>I agree that we should not start putting the bugs into the geodata. It will make the database even heavier for no real advantages. Keeping a separate database is a much saner option and much manageable.<br>
It also allows the use of workflow which is always useful when managing a bug. If you put this inside the geodata, you lose that kind of flexibility.<br><br>Emilie Laffray<br>