public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mark Friedenbach <mark@monetize•io>
To: steve <steve@mistfpga•net>
Cc: Bitcoin Development List
	<bitcoin-development@lists•sourceforge.net>,
	Bill Hees <billhees@gmail•com>
Subject: Re: [Bitcoin-development] Bitcoin Testing Project
Date: Wed, 26 Sep 2012 09:06:41 -0700	[thread overview]
Message-ID: <CACh7GpHFY_KUhhtk09H_oCzBtRh66artDCqz8pXNTh_ZzkAABg@mail.gmail.com> (raw)
In-Reply-To: <506301AC.90101@mistfpga.net>

[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3149 bytes --]

  reply	other threads:[~2012-09-26 16:59 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-25 18:32 steve
2012-09-25 20:41 ` Matt Corallo
2012-09-26  5:49   ` Wladimir
2012-09-26 11:41     ` Daniel F
2012-09-26 12:00       ` Luke-Jr
2012-09-26 12:28   ` steve
2012-09-26 12:49     ` Wladimir
2012-09-26 13:22       ` steve
2012-09-26 16:06         ` Mark Friedenbach [this message]
2012-09-26 17:10           ` Jeff Garzik
2012-09-26 17:44           ` steve
2012-09-26 18:09             ` Gavin Andresen
2012-09-29 18:26               ` steve
2012-10-01 13:52                 ` Arklan Uth Oslin
2012-10-01 14:28                   ` steve
2012-10-01 16:52                     ` Peter Vessenes
2012-10-03  1:15                       ` steve
2012-10-03  2:02                         ` Gregory Maxwell
2012-10-03  3:00                           ` steve
     [not found]                         ` <CAMGNxUu=LTZyAxKt3pAYSVxyhHBU9pyJPCiFs-tA_weYNNXbtw@mail.gmail.com>
     [not found]                           ` <CAMGNxUuHRBkE_MbmY=A0vQvq=gMfzCFG8Us7SdBn-14KiKMaNg@mail.gmail.com>
2012-10-03  5:04                             ` Peter Vessenes
2012-10-03 16:06                             ` steve
2012-10-03 16:11                               ` Arklan Uth Oslin
2012-10-03 16:15                           ` [Bitcoin-development] Fwd: " steve
2012-10-03 17:09                             ` Peter Vessenes
2012-10-03 17:30                               ` Gavin Andresen
2012-09-27  0:53     ` [Bitcoin-development] " Matt Corallo
2012-09-27  2:29       ` Gregory Maxwell
2012-09-25 20:49 ` Daniel F
2012-09-25 21:25   ` Gary Rowe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACh7GpHFY_KUhhtk09H_oCzBtRh66artDCqz8pXNTh_ZzkAABg@mail.gmail.com \
    --to=mark@monetize$(echo .)io \
    --cc=billhees@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=steve@mistfpga$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox