On Mon, Jan 16, 2006 at 02:44:29PM -0500, Josh Sled wrote: > On Mon, 2006-01-16 at 12:08 +0100, Christian Stimming wrote: > > > Proposed DRAFT schedule: > > All dates are the Sunday of a weekend. It is proposed to have a release > > every three week interval; we might shorten that to shorter intervals > > (every other week, maybe). > > > > * 1.9.0 January 29th; Initial announcement and call for venturous > > testers > > * 1.9.1 February 19th; bugfixes > > * 1.9.2 March 13th; String freeze; call for translations; call for > > more testers > > * 1.9.3 April 2nd; bugfixes > > * 1.9.4 April 23th; bugfixes > > * maybe? 2.0.0 May 7th; big party at German LinuxTag (cstim will > > probably give a GnuCash presentation there) > > I think the 1.9.0 date might be a bit aggressive, but maybe not ... I > certainly doubt we'll be at a "all pieces ported fully to g2" state, but > as you mentioned in IRC you're not suggesting that, exactly. :)
Hmm... I have a different concern. I think we could basically start rolling tarballs as soon as distcheck works, but I don't know if the 2.0.0 date is reasonable or not. I just don't have a feeling for what the state of g2 is right now. Probably we won't know until we start getting wider testing. So, I think we should release something soon. I don't think we need to advertise a rigid release schedule. I think we should aim for at least every three weeks, but we should feel no hesitation to release *before* three weeks if we feel we need to. As for the first release, I still see this as labor driven though. I've been trying to get distcheck to work for a long time, and it's still not there yet. The problems are obscure and tedious and very time-consuming to test because a distcheck takes ~20 minutes to fail (mostly spent converting translation files). I end up doing most of my development *during* distcheck runs. And by the types of problems I'm fixing, I can tell that no one else is running these. I'd be a bit more optimistic about the release schedule if distcheck consistently passed. If anyone want to work on this, I an report that the most recent failure is: /bin/sh ../../../../libtool --tag=CC --mode=link gcc -I.. -I../.. -DLOCALE_DIR=\""/home/chris/svn/trunk/gnucash-1.9.0/_inst/share/locale"\" -I../../../../../lib/libqof/qof -I/usr/include/libxml2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -Wall -Wunused -Werror -Wdeclaration-after-statement -Wno-pointer-sign -o libqof-backend-qsf.la -rpath /home/chris/svn/trunk/gnucash-1.9.0/_inst/lib qsf-backend.lo qsf-xml-map.lo qsf-xml.lo ../../../../../lib/libqof/qof/libqof.la -pthread -lgthread-2.0 -lgobject-2.0 -lglib-2.0 -lxml2 -lpthread -lz -lm -lpopt -lm -lm libtool: link: cannot find the library `../../../../../lib/libqof/qof/libqof.la'make[8]: *** [libqof-backend-qsf.la] Error 1 make[8]: Leaving directory `/home/chris/svn/trunk/gnucash-1.9.0/_build/lib/libqof/backend/file' > > As for additional issues that need to be solved for these 1.9.x releases: > > Also, to publicize the discussion in #gnucash from a few minutes ago, it > seems like: > > 1/ The TODO section of the wiki should be for release-related stuff, > though it's unclear what, exactly. > > 2a/ We should re-assert using Bugzilla for 1.9.x/2.x issue-tracking. > > 2b/ We should move the remainder of GNOME2_STATUS into Bugzilla. > > This last part is the one that I wanted to get sync on. I'm proposing > that I will move the GNOME2_STATUS line-items into Bugzilla and remove > the file from SVN (clean up Wiki references to it, &c) on, let's say, > Thursday night (19 Jan). Objections? Devs, please flush any > un-committed GNOME2_STATUS changes. No objection. How well-maintainted is the bugzilla? Are there some bugzilla-masters out there? -chris _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
