[gnome-db](no subject)

[Rodrigo Moya <rodrigo gnome-db org>]

Hi all!

GNOME 1.4 is approaching, and as you may all know, GNOME-DB/libgda is
(hopefully)
going to be included as part of the "GNOME Extra Apps" Release. Due date
for 1.4
is about the end of March, but API freeze is some time in February
(don't remember
sorry).

So, I am now freezing GNOME-DB/libgda sources by creating a CVS tag,
which will
accept only bug fixes. The development would then continue on HEAD.
We're lucky that there have not been many changes since last release
(0.2.2),
so I think we can consider the current CVS sources to be quite stable
with recent
versions of GConf, OAF, Bonobo, etc, but anyway, I make a call for users
to test
this branch, and packagers to attempt making packages with that branch,
so that
we clean up all errors/bugs to leave it ready for release.

About packages: I've given up making more broken RPMs in my Debian
system, so
I won't do them anymore, Carlos, can you take the responsibility on the
RPMs?
And Akira, if you've got no time to make the Debian packages, tell me,
and I'll
do them myself, since I've got everything needed to make them.

As I'm not very experienced with CVS tags, I ask for a little help. What
I'm
going to do is to create the branch:

cvs -r "release-0-2-3" tag

and then, I'll have two separated directories (gnome-db &
gnome-db-0-2-3) to be able
to work on both tags. But, if I make a change in 0-2-3 tag, how can I do
to
reflect this change, if needed, in the HEAD tag?

I'm not proceeding with this until I get an answer about my CVS doubts,
so, in the
meantime, DO NOT check in new functionality to CVS, just bug fixes.
Please, anybody
can enlighten me on this? and correct me on the parts I'm wrong?

Also, if we find this procedure to be good, I suggest we do the same for
all future releases. Thus, once we freeze, packagers can work on the
frozen
tag, to have everybody with the same version, and also, we'll be able
to leave a certain amount of days for people to test it, so that we can
find
some bugs before actually releasing.
It would be also great to have a text describing the "release
engineering"
process on the web site, so please help me with your ideas, comments,
etc
to make this possible :)

cheers