Running a concurrent Mantis tracker would be confusing and fragment the development pathway. We have an issue tracker; it&#39;s on github.<div><br></div><div>What&#39;s being talked about here are two separate things. Jenkins is a continuous integration system. It can be configured to run the suite of unit tests, regression tests, and any kind of automated functional tests for every commit on github and every pull request.</div>
<div><br></div><div>Github is our issue tracker. Github, and only github, is where new issues should be reported (unless it&#39;s security related, in which case an email should be sent to the core devs directly).</div><div>
<br></div><div>Certainly developers should be responsible for making sure that regression tests for bugs they fix make it either into the unit tests or Matt&#39;s functional test repository. QA should hold them accountable for that (re-opening tickets for bugs that have been fixed but without regression tests).</div>
<div><br></div><div>The other thing we&#39;re talking about is coordinated release testing--getting release candidates in the hands of actual users and making sure that issues are reported. This is something that can&#39;t be automated as the point really is to pick up on things that the testing suite missed. You sound more qualified than me for coming up with a process, but in the end discovered issues should be reported to github, the final repository of issues that hold up Gavin from doing a release.</div>
<div><br></div><div>Just my 0.002BTC</div><div>Mark</div><div><br><div class="gmail_quote">On Wed, Sep 26, 2012 at 6:22 AM, steve <span dir="ltr">&lt;<a href="mailto:steve@mistfpga.net" target="_blank">steve@mistfpga.net</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think you might be misunderstanding a little. I am not trying to<br>
replace the current system, I need to make sure that what I do will be<br>
compatible with it (seamlessly so for the developer). I do not want this<br>
to generate extra work for the development team.<br>
<br>
However testing is a lot more than just bug reporting, dont get me<br>
wrong bug reports are important, but so is running a testcase and that<br>
testcase passing, especially if that testcase is linked to the proof<br>
of a requirement. I am trying to develop a qa environment that is<br>
conducive to testing and will allow the testers to shine in all their<br>
glory :) and we need different tools and methodologies.<br>
<br>
Git is too developer centric to be useful for organising testing. -<br>
however there is a large amount of software that is compatible with<br>
git, so the core development team only ever need to work with git.<br>
<br>
The linking between a bug, the requirement, the fix, the retest, and<br>
updating of regression testplan is vital. So is the ability to<br>
organise testing campaigns and assigning tests, work units and test<br>
relevant docs/scripts/ideas, etc.<br>
<br>
I hope this clears things up a bit?<br>
<br>
Cheers,<br>
<br>
steve<br></blockquote></div></div>