Hi Lars,
As you told, we, NTT, are short of experience and skill for release, although I
hate to admit it ;-)
Our current interests are having clear release schedules, and having next
version as scheduled. It is fine if it can be achieved by current steering
members. If not, we can help out, at least, first role, actual testing.
Regards,
Tadashiro Yoshida
At Mon, 15 Oct 2007 15:33:29 +0200, [EMAIL PROTECTED] wrote in <[EMAIL
PROTECTED]>:
> To: High-Availability Linux Development List
> <linux-ha-dev@lists.linux-ha.org>,
Tadashiro Yoshida <[EMAIL PROTECTED]>
> Cc:
> Subject: Re: [Linux-ha-dev] Release 2.1.3 planned for 10 December, 2007
--------------------
> On 2007-10-15T06:53:36, Alan Robertson <[EMAIL PROTECTED]> wrote:
>
> > I have talked to Tadashiro Yoshida about his test team in NTT doing this.
> > For their own reasons his test team needs to test our releases anyway. I
> > thought it would be good to just let them be the test team, since they
> > outnumber the Novell+IBM developers anyway ;-). But, I haven't heard from
> > him on this subject in a few weeks.
>
> I think the "test team" so far mixes up some roles, ordered by increased
> requirement for understanding of the project:
>
> First, as the name suggests, the actual testing. This requires basic
> familarity with Linux, the project, and technology to be meaningful, so
> that high quality bug reports can be generated.
>
> Second, evaluating the incoming feedback (how serious is it? a
> duplicate? Requesting further information to make sure bug reports are
> complete) etcetera; commonly called "triaging".
>
> Third, providing stewardship and guidance for the release. Defining and
> shaping the test plans, and possibly adjusting the release schedule, or
> deciding that a given bug is not blocking the release.
>
>
> I think a new team is in a good position to quickly help out
> significantly with the first point, and the NTT team is already doing
> that. However, you can see from the discussions on the linux-ha list
> that the bug reports are not yet as good as they could be, and that they
> - thankfully! - ask a lot of questions regarding the impact of their
> bugs.
>
> The first point can also benefit from manpower and diversity of tests.
> Everybody is welcome to contribute here, we cannot possibly have too
> much testing.
>
> The second role already benefits more from experience and availability
> than from man power or tons of hardware. Experienced community members
> but of course also developers can fill this role.
>
> The third role benefits mostly from (release) experience, understanding
> the user base needs and deployment scenarios, consolidating the
> requirements, motivating the user base and developers etcetera; and too
> many people involved here will actually have a negative impact. (I think
> the best number is one 'release officer' with a deputy, or a council of
> three; but Linux HA is not a very large project to justify that.) This
> role should either be voted for (as many large OSS projects do), or be
> appointed by acclamation.
>
>
> At least, that is my current impression. I am very grateful for NTT's
> contributions to the project, and hope that the stewardship will make
> sure their needs are adequately met by the release, and look forward to
> their test results, but I would suggest that their interests are not a
> good match for the third role, and we would do them a disservice if we
> convinced them to take it.
>
> > Does Novell have any test resources to help with this?
>
> As I've said repeatedly, we continuously test. We're probably still the
> biggest corporate stakeholder in the Linux HA project.
>
> And as we've got a significant interest in the project, both
> professionally and personally ;-), I'd be more than happy to offer our
> help on all roles mentioned above.
>
>
> On the details:
>
> >> 2. What does the test plan look like, what target scenarios are going to
> >> be evaluated and verified? (Resource agents, architectures, system
> >> configurations.)
> > I have some ideas on this, but, I don't really know the hardware resources
> > they can bring to bear on it in the short term.
>
> A test plan should not immediately take into account the available
> hardware, in my opinion; we first ought to define what we _want_ and
> consider important scenarios for the release, and then figure out ways
> how to test that.
>
> (Or, if it turns out we cannot test it for some reason, we might be
> forced to adjust our priority and defer the test case to the next
> release.)
>
> Vision comes first ;-)
>
>
> Regards,
> Lars
>
> --
> Teamlead Kernel, SuSE Labs, Research and Development
> SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N nberg)
> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
