Re: GEP-4 : Versioning and branching rules proposal

[Michael Meeks <michael ximian com>]

Hi Owen,

	Given that I'm assuming that your buy-in to the GEP for Gtk+ still
stands, I'm interested to see how you engage with this. I personally see
my pre-eminant aim of the GEP, as better engagement between gtk+ and
gnome, and as well to bring Gnome up to the standard of open design and
discussion that we see in 'gtk+ land'.

	Furthermore, I think there are many flawed things with this particular
GEP, as discussed - mostly it's lack of focus on the abstract
requirements, which (I can only assume) none of us would argue about,
such as increasing clarity, helping translators, improving versioning
etc. Presumably gtk+ shares these requirements.

On Mon, 2002-09-02 at 14:16, Owen Taylor wrote:
> GTK+ simply can't use these rules, because GTK+ versioning won't
> always correspond to GNOME versioning.... it more-or-less does right
> now. But that's coincidence.

	I must say, every time I have to say "Gnome 1.4, Gtk+ 1.2" -> "Gnome
2.0 / Gtk+ 2.0" at a conference [ it's suprising how often that needs
clarifying ], I dislike this somewhat artificial barrier.

	In my ideal world, we would have co-ordinated timescale, that treated
the whole development platform as a single 'block' in some sense. Can
you see any disadvantages to that ? can you see any arguments (apart
from historical ones) that would militate against it ? Who would have
the authority to make that sort of long term decision ? Who decides the
future of Gtk+ now (in real terms) ?

	I can understand that in the new world of ABI compatibility, the
boundaries can be blurred, and a mix-and match approach to versioning
becomes perhaps more attractive.

> (Also, we would have a hard time changing practices that we've
> followed consistently for 5 years now)

	Nonsense ;-) I don't believe you're getting old and inflexible;
certainly not personally as a hacker, and hardly as a project.

> But I don't that invalidates the idea of having a set of common rules;
> though perhaps "guidelines" would be a better term.

	Of course - there is great merit in a sub-set of projects having a set
of common rules; but greater in us all sharing them. Whether that's
right for gtk+ I don't know.

> That is, what is approximately the same is best to be exactly the
> same; but it doesn't necessarily make sense for all the modules we
> ship with GNOME to have even approximately the same guidelines.

	I'm interested in specifically why it doesn't make sense. What is it
about gtk+ that makes it different ? in what ways is it different ? can
we expect it to be similar in some ways, and not others ? who creates
and maintains the guidelines for Gtk+ ? how can dialog and compromise be
entered into with those people ? or is compromise not possible for the
sake of greater simplicity ?

	I can believe that in this instance gtk+ should be a special case, what
I'm most interested in - is the areas where you believe gtk+ is not a
special case, and why.

	Ultimately I'd hope that if the GEP process means anything at all,
everyone will abide by it, if certain people have a "Imunity in the
International criminal court" card ;-) [cough], I'm just worried when it
would be played. Then again, clearly in the absence of consensus it's
hardly worth having the process - so I personally have no real desire to
make anyone do what they don't want to, just to get them to compromise
happily.

	Is there any room for compromise ?

	Thanks,

		Michael.

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