From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- .../20111003/ad257225/attachment-0001.html | 58 ++++++++++++++++++++++ .../attachments/20111003/ad257225/attachment.html | 58 ++++++++++++++++++++++ 2 files changed, 116 insertions(+) create mode 100644 zarb-ml/mageia-bugsquad/attachments/20111003/ad257225/attachment-0001.html create mode 100644 zarb-ml/mageia-bugsquad/attachments/20111003/ad257225/attachment.html (limited to 'zarb-ml/mageia-bugsquad/attachments/20111003') diff --git a/zarb-ml/mageia-bugsquad/attachments/20111003/ad257225/attachment-0001.html b/zarb-ml/mageia-bugsquad/attachments/20111003/ad257225/attachment-0001.html new file mode 100644 index 000000000..7f8f02f3d --- /dev/null +++ b/zarb-ml/mageia-bugsquad/attachments/20111003/ad257225/attachment-0001.html @@ -0,0 +1,58 @@ + + +

Le dimanche 2 octobre 2011 22:38:45, vous avez écrit :

+

> Op 02-10-11 22:28, Samuel Verschelde schreef:

+

> > Le dimanche 2 octobre 2011 22:24:10, Marja van Waes a écrit :

+

> >> Op 02-10-11 21:29, Samuel Verschelde schreef:

+

> >>> Le dimanche 2 octobre 2011 21:25:08, Manuel Hiebel a écrit :

+

> >>>> Le dimanche 02 octobre 2011 à 17:35 +0200, Marja van Waes a écrit :

+

> >>>>> Op 02-10-11 15:56, Samuel Verschelde schreef:

+

> >>>>>> There is something I don't know, concerning the bug team: what

+

> >>>>>> happens to bugs once they have been triaged?

+

> >>>>>> Said differently, does the bugteam work stop once the bug has been

+

> >>>>>> assigned to a maintainer, or does bug monitoring enter this team's

+

> >>>>>> work (try to contact the maintainers for stale bug reports, ask

+

> >>>>>> information again when the report hasn't answered yet, produce

+

> >>>>>> reports to monitor open bugs, then send feedback to the developers

+

> >>>>>> mailing list...)? If it's the latter, I don't see yet where this

+

> >>>>>> fits in the proposed structure, as in my opinion bug reports

+

> >>>>>> management goes farther than just "triage".

+

> >>>>

+

> >>>> Well, we must keep the bugzilla working. For example, after an update

+

> >>>> in mageia 1, sometimes the maintainer forget to reassign the bug to

+

> >>>> QA.

+

> >>>>

+

> >>>> I was planned to send weekly bug news, but I must better organise my

+

> >>>> free time. :)

+

> >>>> (And now, as we have maintenairs, this is less important. I think)

+

> >>>>

+

> >>>> For the other part I don't know.

+

> >>>> (I'am also a new bug man)

+

> >>>

+

> >>> Also, to be written somewhere, was never done in Mandriva but in my

+

> >>> opinion *must* be done in Mageia, is set the "cauldron" version to

+

> >>> "Mageia 2" the day it is released.

+

> >>

+

> >> Do you mind explaining? I see various interpretations of this sentence.

+

> >

+

> > A bug reported against cauldron and still valid becomes a bug reported

+

> > against Mageia 2. If we don't change the Version field from cauldron to

+

> > Mageia 2, we risk having some bugs fixed only in cauldron without an

+

> > update being issued in Mageia 2.

+

>

+

> And copying it, so that there is the same report against cauldron as

+

> against Mageia 2?

+


+

Maybe. It could be a lot of work to maintain 2 versions of the same bug report.

+


+

> Bugs on different releases should go into seperate Bug

+

> reports, according to our manual. The Mageia 2 one is then set to depend

+

> on the cauldron one, and the cauldron one is set to block the mageia 2

+

> one (because a patch is, of course, going to be tested in Cauldron first)

+


+

I'm not sure. A bug could have been fixed in cauldron by updating to a newer version (independently of the bug report), but still remain in Mageia 2. And I've seen many bugs fixed in Mageia 1 before or at the same time as in cauldron.

+


+

It's not an easy subject, the solution must be thinked of, taking every case into account.

+


Samuel

\ No newline at end of file diff --git a/zarb-ml/mageia-bugsquad/attachments/20111003/ad257225/attachment.html b/zarb-ml/mageia-bugsquad/attachments/20111003/ad257225/attachment.html new file mode 100644 index 000000000..7f8f02f3d --- /dev/null +++ b/zarb-ml/mageia-bugsquad/attachments/20111003/ad257225/attachment.html @@ -0,0 +1,58 @@ + + +

Le dimanche 2 octobre 2011 22:38:45, vous avez écrit :

+

> Op 02-10-11 22:28, Samuel Verschelde schreef:

+

> > Le dimanche 2 octobre 2011 22:24:10, Marja van Waes a écrit :

+

> >> Op 02-10-11 21:29, Samuel Verschelde schreef:

+

> >>> Le dimanche 2 octobre 2011 21:25:08, Manuel Hiebel a écrit :

+

> >>>> Le dimanche 02 octobre 2011 à 17:35 +0200, Marja van Waes a écrit :

+

> >>>>> Op 02-10-11 15:56, Samuel Verschelde schreef:

+

> >>>>>> There is something I don't know, concerning the bug team: what

+

> >>>>>> happens to bugs once they have been triaged?

+

> >>>>>> Said differently, does the bugteam work stop once the bug has been

+

> >>>>>> assigned to a maintainer, or does bug monitoring enter this team's

+

> >>>>>> work (try to contact the maintainers for stale bug reports, ask

+

> >>>>>> information again when the report hasn't answered yet, produce

+

> >>>>>> reports to monitor open bugs, then send feedback to the developers

+

> >>>>>> mailing list...)? If it's the latter, I don't see yet where this

+

> >>>>>> fits in the proposed structure, as in my opinion bug reports

+

> >>>>>> management goes farther than just "triage".

+

> >>>>

+

> >>>> Well, we must keep the bugzilla working. For example, after an update

+

> >>>> in mageia 1, sometimes the maintainer forget to reassign the bug to

+

> >>>> QA.

+

> >>>>

+

> >>>> I was planned to send weekly bug news, but I must better organise my

+

> >>>> free time. :)

+

> >>>> (And now, as we have maintenairs, this is less important. I think)

+

> >>>>

+

> >>>> For the other part I don't know.

+

> >>>> (I'am also a new bug man)

+

> >>>

+

> >>> Also, to be written somewhere, was never done in Mandriva but in my

+

> >>> opinion *must* be done in Mageia, is set the "cauldron" version to

+

> >>> "Mageia 2" the day it is released.

+

> >>

+

> >> Do you mind explaining? I see various interpretations of this sentence.

+

> >

+

> > A bug reported against cauldron and still valid becomes a bug reported

+

> > against Mageia 2. If we don't change the Version field from cauldron to

+

> > Mageia 2, we risk having some bugs fixed only in cauldron without an

+

> > update being issued in Mageia 2.

+

>

+

> And copying it, so that there is the same report against cauldron as

+

> against Mageia 2?

+


+

Maybe. It could be a lot of work to maintain 2 versions of the same bug report.

+


+

> Bugs on different releases should go into seperate Bug

+

> reports, according to our manual. The Mageia 2 one is then set to depend

+

> on the cauldron one, and the cauldron one is set to block the mageia 2

+

> one (because a patch is, of course, going to be tested in Cauldron first)

+


+

I'm not sure. A bug could have been fixed in cauldron by updating to a newer version (independently of the bug report), but still remain in Mageia 2. And I've seen many bugs fixed in Mageia 1 before or at the same time as in cauldron.

+


+

It's not an easy subject, the solution must be thinked of, taking every case into account.

+


Samuel

\ No newline at end of file -- cgit v1.2.1