Re: [G2R] Re: gtk+ 2.0.4 release?

[Michael Meeks <michael ximian com>]

Hi Mikael,

On Thu, 2002-06-13 at 12:55, Mikael Hallendal wrote:
> Michael, first of all, Gtk+ isn't GNOME. I can't see why Gtk+ should be
> restricted by the GNOME freeze. It's like freezing glibc just because we
> want to get our release out.

	I imagine that glibc doesn't have several critical, Gnome blocker bug
fixes pending over the last released version.

	Also, making arbitrary divisions inside the platform isn't that
helpful; is 'linc/ORBit2' Gnome ? it has a community of non-Gnome users,
it's used in non-Gnome projects - all the same stuff applies. How about
Gconf - is that Gnome ? it doesn't seem clear to me that simply because
other people use Gtk+ that they should not work with the agreed process,
having a stable branch for Gnome 2.0.0, and abiding by the rules
everyone else has to.

> We already have Glib/Gtk+/Pango/... that is Good Enough for GNOME 2.0.0.

	As Louis says, it's just not true.

> If the Gtk+ theme breaks something by accident in 2.0.X we have 2.0.3
> which is already tested and works fine. So it's not as big a problem as
> if gnome-panel 2.0.0 breaks something. There already are stable releases
> of all of the Gtk+ packages.

	Yes - it's true that we could revert to an older version without the
blocker bug fixes we worked on; but then - why did we bother working on
them ?

> Gtk+ is widely used outside GNOME and they have to meet demands on bug
> fixes from those users too.

	It's a matter of release management; we're simply asking for a deep
frozen release, that follows the agreed process, and a branch - that
contains only critical bug fixes from the branch point.

> I don't think those users would much appreciate the answer, "We can't
> fix it because a big user of ours is in deep freeze."

	Who is going to tell them that ? of course the bug can be fixed, on the
main stable branch, and released at the next release.

	Ultimately if people are going to do their own thing, plan to not work
with the release team, not tell them that, and just do their own thing
we might as well give up trying to work together and go home.

	I think what saddens me most is that no-one said "this process sucks,
lets do XYZ instead", they just silently didn't work with it. I
personally think that is one of the most destructive things people can
do, I do understand people are busy, but it's extremely unfair both to
software and process projects if they are silently ignored.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot