MIME-Version: 1.0
In-Reply-To: <506301AC.90101@mistfpga.net>
References: <5061F8CC.9070906@mistfpga.net>
	<1348605677.2284.2.camel@localhost.localdomain>
	<5062F4F8.6040504@mistfpga.net>
	<CA+s+GJBM4DwDoqT8RC0+SyrLYrLGZuGZSuoj7zbHunQa3kFoRA@mail.gmail.com>
	<506301AC.90101@mistfpga.net>
Date: Wed, 26 Sep 2012 09:06:41 -0700
Message-ID: <CACh7GpHFY_KUhhtk09H_oCzBtRh66artDCqz8pXNTh_ZzkAABg@mail.gmail.com>
From: Mark Friedenbach <mark@monetize.io>
To: steve <steve@mistfpga.net>
Content-Type: multipart/alternative; boundary=e89a8fb1fa0a26098404ca9d0235
Cc: Bitcoin Development List <bitcoin-development@lists.sourceforge.net>,
	Bill Hees <billhees@gmail.com>
Subject: Re: [Bitcoin-development] Bitcoin Testing Project
Precedence: list

--e89a8fb1fa0a26098404ca9d0235
Content-Type: text/plain; charset=UTF-8

Running a concurrent Mantis tracker would be confusing and fragment the
development pathway. We have an issue tracker; it's on github.

What'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.

Github is our issue tracker. Github, and only github, is where new issues
should be reported (unless it's security related, in which case an email
should be sent to the core devs directly).

Certainly developers should be responsible for making sure that regression
tests for bugs they fix make it either into the unit tests or Matt's
functional test repository. QA should hold them accountable for that
(re-opening tickets for bugs that have been fixed but without regression
tests).

The other thing we'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'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.

Just my 0.002BTC
Mark

On Wed, Sep 26, 2012 at 6:22 AM, steve <steve@mistfpga.net> wrote:
>
> I think you might be misunderstanding a little. I am not trying to
> replace the current system, I need to make sure that what I do will be
> compatible with it (seamlessly so for the developer). I do not want this
> to generate extra work for the development team.
>
> However testing is a lot more than just bug reporting, dont get me
> wrong bug reports are important, but so is running a testcase and that
> testcase passing, especially if that testcase is linked to the proof
> of a requirement. I am trying to develop a qa environment that is
> conducive to testing and will allow the testers to shine in all their
> glory :) and we need different tools and methodologies.
>
> Git is too developer centric to be useful for organising testing. -
> however there is a large amount of software that is compatible with
> git, so the core development team only ever need to work with git.
>
> The linking between a bug, the requirement, the fix, the retest, and
> updating of regression testplan is vital. So is the ability to
> organise testing campaigns and assigning tests, work units and test
> relevant docs/scripts/ideas, etc.
>
> I hope this clears things up a bit?
>
> Cheers,
>
> steve
>

--e89a8fb1fa0a26098404ca9d0235
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Running a concurrent Mantis tracker would be confusing and fragment the dev=
elopment pathway. We have an issue tracker; it&#39;s on github.<div><br></d=
iv><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, i=
s 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 t=
hat regression tests for bugs they fix make it either into the unit tests o=
r Matt&#39;s functional test repository. QA should hold them accountable fo=
r that (re-opening tickets for bugs that have been fixed but without regres=
sion 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 an=
d 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 sui=
te missed. You sound more qualified than me for coming up with a process, b=
ut in the end discovered issues should be reported to github, the final rep=
ository 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 clas=
s=3D"gmail_quote">On Wed, Sep 26, 2012 at 6:22 AM, steve <span dir=3D"ltr">=
&lt;<a href=3D"mailto:steve@mistfpga.net" target=3D"_blank">steve@mistfpga.=
net</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"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>

--e89a8fb1fa0a26098404ca9d0235--