Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)

[Mike Emmel <mike emmel gmail com>]

First I want to say I hope I'm helping. I think by "recording" my
observations they can be helpful.  I know I've learned more about GTK
in Owens response then in a months of reading the mailing list and web
site.

On 6/9/05, Owen Taylor <otaylor redhat com> wrote:
> On Thu, 2005-06-09 at 19:10 -0400, Mike Emmel wrote:
> > And cairo and atk and I need to share all these dates with several people.
> > It can be done I'm not saying it can't I'd just love a real tag across
> > all the various pieces to get a repeatable build out that more people
> > can work on.
> >
> > I think your far enough along for a tag and I think a 2_7 tag would be
> > of intrest to more people then just me.  The gtk development plan
> > indicated you would be tagging the tree and approaching stability now.
> > If thats true then just tag it so its easy for me and others to get a
> > snapshot.  Are they also going to tag cairo to match the gtk tag ?
> 
> I think you work a little different with CVS than GTK+, GNOME, or
> open source developers in developers. We make releases, we don't "tag
> the tree". (Though we "tag the tree" when we release).
> 
> There will be a GTK+ release within the next week. If that doesn't
> work with Cairo-0.5.0 we'll make a new Cairo release as well.
> 
Ahh now this is a new one for me actually I've been using Cairo CVS I
did not know that GTK was  working with 0.5.  Pango checks for version
number greater then 0.2.0.  I have know idea where it is documented
that your not tracking cairo cvs. This type of information is very
useful.


> > The directfb gdk backend is invasive  If I had cvs acccess I would
> > have tagged the tree for this type of work.  The fact that your not
> > tagging makes it difficult for me. I don't feel that trying to do a
> > timestamp based checkout is the right answer sorry.
> 
> A tag just identifies a bunch of file versions, just like a timestamp.
> without any correlation to quality control or branching, the tag offers
> no advantages, and is just noise.
> 
> > The real problem is it seems to me that open cvs trees  have a lot of
> > problems if someone actually wants to do work on the source and is not
> > a blessed developer.
> >
> > 1.) No stable tags or no way to tag off a fork for development
> 
> We try very hard to make the tree *always* stable in the sense
> of "compiles and works". I've always had a very dim view of
> projects that have to tell people to go back to an older tag
> to get a working version.

This is fine good information if that the way GTK work I'm the one
that needs to adapt.  I accept that.  The problem is till you
responeded to the email I had no idea how you used gtk cvs I did not
see a lot of tag on one hand but I also saw developers doing branches
so its not obvious the intent from the cvs logs.
> 
> > 2.) No easy access to the "current" plan for the main tree
> 
> Not sure what this means.
> 
> > I'm sure there more but these two are the ones that have bugged me the most.
> >
> > There should be a way for people to request a tag of the cvs tree for
> > a project thats off the mainline without them being cvs committers.
> 
> I'm really not sure what the point of the tag is for this. We could
> certainly blindly.
> 
>  cvs rtag GTK_MIKE_EMMEL_20050609 gtk+
> 
> But that doesn't provide anything to you that -D 2005-06-09 doesn't.
> 
> Doing a little bit of minimal checking, seeing that 'make distcheck'
> passes and tagging the tree is what we call making a release, and
> the resulting tarball is then placed on the FTP site as well :-)
> 
Actually its still quite useful esp for me.I'm assuming it passes
simple automated tests. I'd urge you to consider doing snapshot
releases agian. That timestamp is  enough for me to do cvs checkouts
agianst or just point people to the tarball. Note also because of the
dependencies its not just gtk but cairo pango atk etc etc that need to
be snapshots so its non trivial.

> We should be doing that for 2.7.0 within the next week.
> 
> Would it have been useful to do 2.7.0 two months ago? My experience
> is generally no ... until you have some degree of stability,
> a release point doesn't mean much. Before the days of ready CVS
> access and bandwidth, snapshot tarball releases were more important,
> but these days, working from CVS is easier for someone who does
> really want to track unstable development.
> 
As I said above there still quite useful please consider them they
give points of at least known stability.

> > There should be a clear place to find out about project planning isses
> > and timelines.  Web page blog gant chart etc etc.
> 
> gtk.org/plan/2.6/ is where we put our schedules and plans. If there
> is insufficient data there, we'd invite you to come to our well-
> publicized weekly meetings, ask questions, and tell us what is missing.
> 
I did not start really bitching till 2.7 was seven days late and the
irc logs mailing lists etc etc had no mention of the status :)

> > My point is that I think a lot of opensource developers have CVS
> > access and they don't quite realize how little there providing to
> > people that want to work on the source for  other projects but don't
> > want to become project members.  The barrier to entry seems pretty
> > high.  I don't think it should be since these  people are prob people
> > thay may later join the project.
> > Sorry to talk so much but I really feel there is a intrinsic problem
> > here that I think a lot of the open source leaders have no idea
> > exists. I've found my own "entry" into opensource to be quite
> > unpleasant in a lot of ways.  I don't think it should be, education or
> > reasonable newbie support for developers should be important.
> 
> Various projects are now experimenting with distributed version control
> systems (arch, baz, monotone, etc.) These systems should make it easier
> to just start developing on a project and get a full set of version
> control system.
> 
Yes the core issue is related in my opinion to short comings in CVS.

> But it's certainly possible to work on something like GTK+ without
> CVS access even for major changes. (And most new GTK+ developers don't
> start with rewriting a backend.)

True I think in this case its the tool i.e CVS that not the best
suited for the invasive work I'm doing.  When you consider another
tool consider its abilities to handle these types of situations it
makes life easier and brings in more developers. I think whats really
needed is some sort of sandboxed
work area support where developers can work on there own branch but
not touch the mainline. I've seen this done with CVS hacks but I've
been using subversion lately its a lot better I'll ping them and see
if they are intrested in supporting "sandboxes" dunno about the other
tools bitkeeper supported it but bitkeeper is bad now :)

As far as the backend goes yes its a big project and its one of the
reasons that I don't want to be a "gtk" developer I need to
concentrate my limited  time on getting that to work I don't really
want nor have the time right now to get involved in main gtk
development. I'd like to later but not now.  Also I've got similar
problems with cairo in the case of cairo I maintain a copied cvs
repository its not worked out that well either. Cairo is a lot smaller
and easier to deal with then gtk though. Plus your on both lists so I
might as well bitch here :)

Thanks for your response I learned a lot consider adding it to a web
page for new developers if you think its generally useful.

> Regards,
>                                         Owen
> 
> 
> 
> BodyID:87155345.2.n.logpart (stored separately)
> 
>