Re: What if "blocker" meant "blocker"?



(1) this is a great start.

(2) this discussion should be happening on bugmaster@ or
gnome-bugsquad@, most likely- I think in general the right procedure
here is for the bug team to be figuring out what is or isn't a
stopper, and presenting the list to the release team basically as a
fait accompli. Delegation, not centralization.

Luis

On 1/9/06, Ryan Lortie <desrt desrt ca> wrote:
> On Sat, 2006-07-01 at 12:54 -0700, Elijah Newren wrote:
> > Shorter version this time...
> >
> > On 1/6/06, Ryan Lortie <desrt desrt ca> wrote:
> > > Hello Release Team.
> > >
> > > For next release cycle, I have a simple suggestion to improve the
> > > release process:
> > >
> > <snip>
> > > When you can go on Bugzilla right now and see "Blocker bugs:
> > > GNOME 2.12.x (these must be fixed before/in the specified GNOME
> > > version)" with a list of open bugs under it something is wrong.
> >
> > So, I talked to Olav and I don't think we have enough time to send out
> > the occasional blocker summary emails.  So we do need a new volunteer
> > to do it.  Can we get you to do this Ryan?  It'd be great if you could
> > go over the list and send out an summary/update every couple weeks.
>
>
> Ok.  As discussed on IRC I'm emailing a preliminary version of the list
> to this mailing list.  I've removed most of the "blocker" bugs that were
> really obviously not blockers by removing the blocker designation or
> convincing the person who set it to remove it.
>
> Here's what's left.  A lot of these are not legitimate blockers in my
> opinion but I'm not interested in stepping on everyone's toes.
>
> #122688: modal dialog popup + drag in progress = mouse freeze
>
>   If the user is dragging an icon or rubberbanding in nautilus at
>   the time that a modal window pops up then the entire desktop
>   freezes.  The only way to unfreeze the desktop is to kill off
>   nautilus.  mclasen says that GTK has a mechanism to recognise and
>   avoid this situation but nautilus doesn't use it.  Huge user
>   impact and no reason it can't be fixed.
>
> #125364: vte screens are black when initially shown
>
>   Low user impact and easy to fix (just refresh the screen).
>   Probably should not be on the list.
>
> #133815: keys refuse to "unbind"
> #135476: Setting a key combination doesn't work multimedia keys
>
>   Evil twins.  #133815 is very evil because it causes you to
>   lose the use of a key on your keyboard until you restart the
>   session (should be a blocker).  #135476 is less evil since
>   it merely restricts you from using, for example alt+p for "play".
>   Luis "tentatively mark"ed it as a 2.12 blocker but it doesn't seem
>   bad enough to block a release for.
>
> #157941: Help browser content is inaccessible [REGRESSION]
>
>   The screenreading software can't "see" the text in the help browser.
>   You can make a reasonable argument that if the help isn't accessible
>   then the desktop itself is not accessible.  Probably a good blocker.
>
> #170207: Slow, incorrect rendering of this pdf file
>
>   Some (rare) files render very slowly in evince.  Luis marked it as a
>   2.12 blocker because "it is going to look terrible if 'our new
>   awesome pdf reader! look how awesome it is!' in 2.12 is slow like a
>   turtle on downers".  The bug is in fact a problem with libpoppler
>   (not Gnome) but remains open in the Gnome bugzilla due to its direct
>   impact on evince.  This is probably not a show-stopper.
>
> #302096: Crash while trying to burn a CD
>
>   Nautilus crashes when trying to burn a CD.  This happens an awful
>   lot (from the number of dups) but nobody seems to be able to get
>   a good stack trace.  This is a great candidate for a blocker
>   because it's serious and common.  There seems to be very little
>   traction, on the problem, though.
>
> #303280: evolution-plugin email receipt
>
>   A crash that was fixed but then not fixed....?  In any case it's
>   caused by a very infrequently used feature.  I'd have removed this
>   from the blocker list myself if it wasn't a crasher.
>
> #310153: crashes on attempt to use in libgnomeui
>
>   This one is a keeper.  Somehow an invalid URI is getting into the
>   bookmarks file and causing libgnomeui to crash on reading it.  At
>   the very least we can work around this problem very easily and
>   hopefully it will be easy to fix properly.
>
> #312171: hal/non-hal incoherence: gnome_vfs_drive_get_activation_uri ()
>
>   This one is probably not a keeper.  I'm not sure why it was
>   added to the blockers list but I'm not really sure I understand
>   the consequences of it and I don't want to step on toes by
>   removing it.
>
> #313047: Evolution Mail Account Settings need some UI love
>
>   Oh boy do they ever.  Set as a show-stopper by a Novell employee
>   but I disagree.  As bad as it is, it's not stop-the-release bad.
>
> #314137: 'open folder' icon never reverts to closed after window is
> closed
>
>   Luis marked this as a 2.12 show-stopper because of its high
>   visibility.  Even if it is highly visible, the user impact is
>   very small.  Not sure if this is a good candidate for actually
>   blocking a release (it certainly didn't last time...).
>
> #314774: [patch] xrdb called needlessly multiple times
>
>   Fixing this bug would improve our login time.  Slightly slow login
>   time is no reason to stop the show, though, is it?
>
> #317312: [CAN-2005-0023] gnome-pty-helper writes arbitrary utmp records
>
>   We have an open security advisory and nobody has even touched it.
>   Even though the results of this attack are minimal (faked log
>   files) this needs to be looked into and fixed ASAP.
>
> #318951: Links breaks the spatialness of Nautilus
>
>   If you have a symlink to a folder and you open it it opens in a
>   separate spatial window from if you open the folder itself.  This
>   really does confuse the user rather substantially and ruins their
>   idea of folders as objects.  It should be reasonably trivial to
>   fix this.  I think this is a reasonable blocker.
>
> #319308: Accessibility: Folder name does not exist in canvas
>
>   Marked as a blocker, it really isn't.  It has a patch attached
>   and needs a bit of attention (probably a quick close).
>
> #319549: gnome.ui.icon_lookup() segfaults on weird filenames
>
>   This bug causes segfaults when rendering icons for odd
>   filenames.  I've tried to trigger this by creating some of these
>   weird filenames and wandering into a directory containing them
>   with nautilus.  This does *not* trigger the crash.  As such,
>   I'm guessing the user impact of this problem is probably small.
>   Probably not a good blocker.  It has a patch that claims to fix
>   the problem so it should get some attention.
>
> #320217: recoursive copy & replace fails and all files are deleted
>
>   'gnomevfs-copy foo foo' erases foo.  This is a disaster but it
>   looks like it's going to be fixed.  An appropriate blocker.
>
> #324406: "Open Location" autocompletion truncates filenames
>
>   Autocompletion in the nautilus location dialog truncates
>   filenames due to utf8 vs. byte length confusion.  Not a
>   blocker but I've attached a patch to fix it and it needs
>   attention.
>
> #325737: Nautilus crashes after adding files to burn area
>
>   Nautilus crashes when you drag files into the burn folder on
>   Solaris.  This is obviously a big problem for Solaris users
>   and a fix is attached.  An appropriate blocker.
>
> #325861: gnome_vfs_async_xfer reports wrong GnomeVFSXferProgressInfo in
> the callback for http method
>
>   I don't really understand this problem but it's well on it
>   affects end-user applications in a visible way and is well
>   on its way to being fixed.  It was also marked as a blocker
>   by people who know what they're talking about :)
>
> #325988: text files listed as application/octet-stream on non local
> system
>
>   This is a fairly significant problem for people who are
>   browsing files on a SMB (or some other) remote filesystem.
>   Should stay as a blocker.
>
> #326323: Crashes on login with a11y enabled
>
>   Gnome-session crashes on startup if a11y stuff is enabled.  This
>   is a no-brainer blocker.
>
>
> If some release-team or "senior-ish" bug people could go over some of
> the bugs that I've cast doubts on in this email and remove them from the
> blocker list it would be appreciated.  At that point I'd be able to take
> the ones that remain and write an email to desktop-devel-list with the
> list along with some information about what "Gnome target" means (and
> when to use it).
>
> Cheers.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iQG5AwUAQ8LLXJ96IjKvqm/2AQKYOA0fZ/lnJYMOVlKy8fJKxuNfIK4Yh/tfd2S7
> yyRI2VbKgdbydzMWPbIM9uaUwJnhUYX6rK0CSXZ40NPaZPYnzCFB/olMo+BQePeU
> QtcnWeVoQzXzMhstQHub4DcbhH+nJmpYhX/3vXsLMlqkKDF20i4OyNLjJ6csOz5b
> yoKlNGWMh5KX7Y20J9lH/OI0csT0S0TBR4yqIavR2PRek0ZTuHHf7MwdGADCT0cj
> VemgC6J06rRvjj0Lz/q+FS/wm0RIbZ7hrrZwwSmwxYufukGm3SkhcHXm/qyNjuXc
> zKtml7J3/DKT00CvACh+QcyaJ8tfUv4bDxLM/45d2QOh8gLGCUaIrVFKkiDyBokw
> cMoIVnvJHmdhWgn3Y15D3ufaG8smxrgf4+73WWFQzz+eVBMA6wQeMxfuFHBjJDXa
> w2MxhQetJpLRivv34uOETXUKDZbJqrMMhFo2YWElcj9PY+ATSQ+LcTE6n+RfiG23
> 9BxHK1dAEel9ZXuByyl+0bOUmux9ZjTrRDVhUoFiff9kEorBuWQXjKm6TJQxiNjm
> GG/ZS4aSQGnB3diN
> =g6o2
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> release-team mailing list
> release-team gnome org
> http://mail.gnome.org/mailman/listinfo/release-team
>
>
>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]