BugSquad/Meetings/Minutes/2008-12-17: Difference between revisions

(8 intermediate revisions by 4 users not shown)

Line 1:

* Agenda at http://sugarlabs.org/go/BugSquad/Meetings/Agendas/2008-12-17

* Logs: http://~~meeting~~.~~laptop~~.org/~~sugar-meeting~~.log~~.20081210_1206.html~~

* Logs: http://shell.sugarlabs.org/~erikos/bugsquad_17_12_2008.log

Line 22:

* Do we need a dedicated mailing list?

** No, we mostly have announcements and use tags ~~if that is not the case, questions~~ like (I was triaging bug #567 but didn't know what to do.)

** No, we mostly have announcements and use tags for cases like: "I was triaging bug #567 but didn't know what to do?"

** sugar-devel - [bugsquad] and [bugsquad][announce]

** "you can always triage at any time, and if you'd like to schedule your own sugar triage sprint, please do and announce it $here! if you're new and want help getting started but can't make a sprint, ask $here_2."

** wiki note: "you can always triage at any time, and if you'd like to schedule your own sugar triage sprint, please do and announce it $here! if you're new and want help getting started but can't make a sprint, ask $here_2."

** irc questions at #sugar

* Create a list of concrete tasks we expect the BugSquad to do regularly

** solicit distributions for testing of new releases

** maintain the BugSquad wiki pages (especially with policies like "we use #sugar for discussion, tag your ~~iaep~~ posts this way")

** maintain the BugSquad wiki pages (especially with policies like "we use #sugar for discussion, tag your sugar-devel posts this way")

** add components, tags, milestones

** triage tickets

Line 39:

*** bug squad make the bug nice (a well-written bug report, a suggestion on the next step to push it to developers for fixing - who to talk to, etc.), assign to maintainer

*** maintainer assign a milestone

*** the dev does fix it :)

*** the dev does fix it

** What needs to be happen to mark a ticket as fixed?

*** ~~downstream takes~~ the ~~patch and puts it into their version and verifies and tests downstream, as needed~~

*** not fully discussed the policy

* Action items:

** #ACTION: marcopg to look at the upstream/downstream interaction fedora+GNOME

** #ACTION: mungwell to look at the upstream/downstream interaction ubuntu+GNOME

** #ACTION: mungwell to look at the upstream/downstream interaction ubuntu+GNOME (launchpad)

** #ACTION: erikos clean up wiki with today's info

** #ACTION: erikos work on trac with marcopg

@@ Line 1: / Line 1: @@
 * Agenda at http://sugarlabs.org/go/BugSquad/Meetings/Agendas/2008-12-17
-* Logs: http://meeting.laptop.org/sugar-meeting.log.20081210_1206.html
+* Logs: http://shell.sugarlabs.org/~erikos/bugsquad_17_12_2008.log
@@ Line 22: / Line 22: @@
 * Do we need a dedicated mailing list?
-** No, we mostly have announcements and use tags if that is not the case, questions like (I was triaging bug #567 but didn't know what to do.)
+** No, we mostly have announcements and use tags for cases like: "I was triaging bug #567 but didn't know what to do?"
 ** sugar-devel - [bugsquad] and [bugsquad][announce]
-** "you can always triage at any time, and if you'd like to schedule your own sugar triage sprint, please do and announce it $here! if you're new and want help getting started but can't make a sprint, ask $here_2."
+** wiki note: "you can always triage at any time, and if you'd like to schedule your own sugar triage sprint, please do and announce it $here! if you're new and want help getting started but can't make a sprint, ask $here_2."
 ** irc questions at #sugar
 * Create a list of concrete tasks we expect the BugSquad to do regularly
 ** solicit distributions for testing of new releases
-** maintain the BugSquad wiki pages (especially with policies like "we use #sugar for discussion, tag your iaep posts this way")
+** maintain the BugSquad wiki pages (especially with policies like "we use #sugar for discussion, tag your sugar-devel posts this way")
 ** add components, tags, milestones
 ** triage tickets
@@ Line 39: / Line 39: @@
 *** bug squad make the bug nice (a well-written bug report, a suggestion on the next step to push it to developers for fixing - who to talk to, etc.), assign to maintainer
 *** maintainer assign a milestone
-*** the dev does fix it :)
+*** the dev does fix it
 ** What needs to be happen to mark a ticket as fixed?
-*** downstream takes the patch and puts it into their version and verifies and tests downstream, as needed
+*** not fully discussed the policy
 * Action items:
 ** #ACTION: marcopg to look at the upstream/downstream interaction fedora+GNOME
-** #ACTION: mungwell to look at the upstream/downstream interaction ubuntu+GNOME
+** #ACTION: mungwell to look at the upstream/downstream interaction ubuntu+GNOME (launchpad)
 ** #ACTION: erikos clean up wiki with today's info
 ** #ACTION: erikos work on trac with marcopg