Meeting on irc.gnome.org:#gtk-devel Meeting started June 21 2004 17:02 EST (21:02 UTC) In attendence: Jonathan Blandford (jrb), Matthias Clasen (mclasen), Owen Taylor (owen), Kristian Rietveld (kris), Federico Mena Quintero (federico), Manish Singh (yosh), Anders Carlsson (andersca), Luis Villa (lu|lunch), Ray Strode (halfline), John Ehresmann (jpe), Carlos Garnacho (garnacho), Soeren Sandmann (ssp), Robert Ögren (roboros), German Poo Caaman~o (gpoo) should we begin ? One thing I forgot to put on the proposed agenda: what are the most important bugs to fix before 2.4.4 ? mclasen: I want to do a 2.4.4 release shortly after guadec, to get the fix for the libtiff loader out one bug which I want to get fixed before that is 144324, are there other urgent bugs ? hmm mclasen: You seem to be talking to yourself :-) I haven't really paid much attention to GTK+ bugs in detail; I'm trying to 1.4 and 1.5 pango releases out this week will pango 1.6 go in gnome 2.8, btw ? IIRC there is no way that gnome 2.7 is going to depend on pango 1.5 they've learned their lesson right now kris: News to me me too kris: what if pango follows the gnome release schedule? I don't think they [the gnome release team] are going to believe that kris: I don't think we've discussed it. However, Owen should really propose it, etc. kris: If the release team is going to say that I and Jody (becuase libgnomeprint depends on Pango HEAD) can't follow the gnome release schedulel, they are going to have to tell us that themselves owen: how much work remains to be done between 1.5.0 and 1.6, anyway ? owen: oh, okay jrb: Hmm, I suppose I should wave my hands and jump up and down about it, though it isn't a new module didn't know that libgnomeprint depends on pango head owen: no, but the fact it's supposed to be following GNOME instead of GTK+ is new owen: prolly good to give a heads up. mclasen: I'd be pretty happy with it as it is now. It would be sort of nice to have some interface for rendering rotated Xft text, but not essential next topic I wanted to discuss is bugzilla milestones. The current approach where we move ~200 bugs from stable milestone to next stable milestone doesn't really help with finding the important bugs... mclasen: that's because we use milestones as "this can be fixed by..." rather than "this will be fixed by..." I think milestones were more useful back in the 1.3 days were 1.3.x wouldn't be released if federico: I'm missing a way mark bugs as "fix this before the next stable release" any bugs were on that milestone andersca: Well, we do that for 2.2/2.4, etc. owen: nod mclasen: I've done that by marking priority as high mclasen: But admittedly the push-big-pile-of-bugs-ahead-of-us is not terribly useful owen: s/1.3/ unstable releases then owen: ok, I can probably adjust to that by writing a few new queries... mclasen: I wonder if we should have a "2.4 stable" milestone owen: that sounds nice if we actually take time to prioritize bugs; otherwise it becomes a wildcard for "we could fix this in the stable series" releases also come with freebie bugs fixed, when people grab low-hanging fruit federico: How does the current 2.4.2 differ? owen: it doesn't :) owen: I mean, it's ok to have a milestone that says "we can fix this in the stable branch" owen: but we also need a way to say "we absolutely must fix this for the next stable release" I guess those are blockers, eh maybe the only thing that would really help is reducing the total number of bugs. When sorting a huge number of bugs in a limited number of milestones, one is always going to be a grabbag federico: blockers are usually fixed quite fast andersca: let's make everything a blocker ;) :) I mean bugs that would otherwise be classified as blockers if clicked isn't emitted for a button for example, then that's usually fixed fast enough federico: We could use High priority, or we could *also* have the current milestones owen: I think we should try to use priority for this, and see how it works. What probably would help would be a "short guide to gtk bugs" somewhere on www.gtk.org to have some written down conventions to use for gtk bugs what happened for the file chooser bugs is this: 1. we marked really important stuff for 2.4.1, and mostly got them done 2. we marked not so important stuff for 2.4.2, and didn't get them done was I summoned? 3. now they got punted to 2.4.4 luis: sort of; we are trying to figure out a milestone/priority convention for gtk bugs luis villa. luis: we have this situation where we routinely punt a large number of bugs to the next version's milestone --- the ones that no one ever has time to fix IIRC, owen tends to use 'I've put this on a milestone' as a way of saying 'I've reviewed this bug', which isn't insane; in some ways possibly better than what the rest of gnome does. so probably you want to say something like 'no bugs with foo or higher priority can still be on the milestone when we ship', and then actually hold to it. It seems (from my limited skimming) gtk's problem is not organization- it is well organized. You just need someone actually making the organization mean something, if that makes sense. thus my proposal to write down the way organize bugs _we_ organize does this make sense: blocker/critical bugs *must* have a milestone, which is 2.4.next high priority unmilestoned bugs mean "we really need to look at this soon"; milestoned ones can become blockers if there are no other blockers for that milestone? federico: one question to consider is 'what is blocker/critical'? the definitions we give on b.g.o's defintion page are very end-user-app centric and mostly don't apply to gtk. ditto for priorities Unfortnately, I have to leave in a minute; one thing I did want to discuss is guadec schedule. Do we want to agree on a time for a "face-to-face" gtk team meeting, or would that be too formal ? there are a few free slots/rooms in the schedule you'll all be on irc during the face-to-face meeting, yea? i might but i wont be at guadec. so i would be kinda useless P: halfline: I guess it will depend on how many people meet -- the gtk team is not very big federico: yea. If you don't, it'd be great if a summary of what was discussed was posted to the mailing list. halfline: yeah federico: of course, being on IRC would be even better, since kris and possibly ssp won't be there halfline: very good point Jun 21 17:59:09 * federico hopes wifi is good federico: if you do decide to do IRC and you find out a time slot post the time slot to the list, too. halfline: sure, I'll do that, and update my webcal Jun 21 18:02:04 * federico wonders if anyone is using that thing federico: thanks Meeting ended June 21 18:02 EST (22:02 UTC)