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

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.

> 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.

> 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 :-)

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.

> There should be a clear place to find out about project planning isses
> and timelines.  Web page blog gant chart etc etc. 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.

> 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.

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.) 


Attachment: signature.asc
Description: This is a digitally signed message part

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