Proposals about gnucash-gnome2

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposals about gnucash-gnome2

Christian Stimming
Hi Developers,

two different issues just popped up about the current gnucash development.
First, some latest changes in CVS seem to have introduced unexpected
conflicts, though the changes are considered to be of lower priority by many
developers here. Second, the pressure for a gnome2-gnucash is increasing
all around. I have some proposals as a response to these points, and I'd like
to explain these here.

I think that gnucash isn't that far away from an actual gnome2 release
anymore. However, we as a developer team have been lacking a clear
communication about the current status, the currently important goals, and
the roadmap for the near-future development. I propose that we should firmly
restating the actual vision for gnucash and the current view of the  
developer team on the best roadmap to a gnome2 release. Something like: "The
gnome2 port of gnucash is under way. At first, we will try to keep all major
features of the 1.8.x release but under the new GUI toolkit. This might be
achieved in the next 2..4..6 months. Only after we achieve an initial
gnucash-gnome2 series, we will focus on improving the existing features and
add brand-new additional features to keep our status as the best free finance
manager around." As a relatively easy technical step to underline our
commitment to a gnome2 release, I would  suggest to merge back the
gnucash-gnome2-dev branch into HEAD. On IRC, David Hampton already agreed to
work on this important CVS action.

Related to this is the question about the qof-work, which is not immediately
vital for the gnucash-gnome2 port. In my opinion the work in that area is
going on well, but unfortunately the goals of the qof-work and those of other
developers silently diverged at some point. I think we should clearly confirm
that the architectural changes related to qof, including the division between
an external libqof and gnucash, are *not* immediatly the focus of the
gnucash-gnome2 port. This work should therefore (please, please) *not*
interfere with work that improves the gnome2 port and only the gnome2 port.
The technical solution to that issue is quite simple: I would suggest that
the qof-work should get its own CVS branch (qof-devel or similar), and then
those working on qof will be responsible for merging other people's changes
into that branch. This will of course be quite easy once the gnome2-branch is
merged back into HEAD, so that the HEAD branch will be the point for the
gnome2 progress.

And additionally I would again propose to have a 1.8.12 release, because it
contains numerous bugfixes which should be released (please please :). I would
volunteer in the tarball preparation and the necessary announcements.

An interesting side-effect of a 1.8.12 release is that we as a developer team
communicate the fact that we're alive and active and caring about the users,
all the while such a release is technically quite easy for us. And of course
the respective announcement can be used to communicate the active gnome2
progress.

Regards,

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposals about gnucash-gnome2

Thomas Bushnell BSG
Christian Stimming <[hidden email]> writes:

> And additionally I would again propose to have a 1.8.12 release,
> because it contains numerous bugfixes which should be released
> (please please :). I would volunteer in the tarball preparation and
> the necessary announcements.

This is a decent idea.  At the moment, there is a gnome-1
destabilization being cleaned up in Debian unstable, and a big
adapt-to-the-new-gcc-4.0 destabilization still being completed.  I
won't be packaging a new upstream gnucash until all that stuff is
done.

That need not affect the decision, but I just want to make sure that,
if it does, y'all got the facts. ;)

> An interesting side-effect of a 1.8.12 release is that we as a
> developer team communicate the fact that we're alive and active and
> caring about the users, all the while such a release is technically
> quite easy for us. And of course the respective announcement can be
> used to communicate the active gnome2 progress.

How many of the users these days get things directly from upstream
maintainers?  I have no idea.

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposals about gnucash-gnome2

Conrad Canterford
In reply to this post by Christian Stimming
On Wed, 2005-10-05 at 22:05 +0200, Christian Stimming wrote:
> An interesting side-effect of a 1.8.12 release is that we as a developer team
> communicate the fact that we're alive and active and caring about the users,
> all the while such a release is technically quite easy for us. And of course
> the respective announcement can be used to communicate the active gnome2
> progress.

For what its worth, from my perspective I have to say I agree with all
Christian's points. I think a 1.8.12 release is worthwhile to show that
things are still happening. I think a 1.10/2.0 release should be a
urgent priority. I'd like a target for the end of this year if at all
possible (OK, so maybe that's not realistic, but I can hope), even
though that means new stuff that we'd like to happen won't go into the
release. Splitting the CVS into a gnome-2 (version 1.10?) tree and a
future feature release (version 2.0?) tree seems like a good idea.

There is no reason why the proposed version 2.0 can not be released a
couple of months after 1.10. After all its not as though we have paying
customers who are going to get pissed off at paying for upgrades every 6
months. We do, however, have people who are losing faith in gnucash
because development appears to have slowed to a crawl in the last few
years. I think more, "smaller" releases are preferable to one or two
huge ones. Not the least because I know from prior experience that the
huge releases will also have huge numbers of bugs.

Also, can I remind people that we will need *at least* a months worth of
pre-releases for testing before the actual release. That's if I and
other testers get seriously into the testing and hammer it fairly hard.
I'd think 6 to 8 weeks would be more realistic. When thinking of when
the release is going to happen, add that time on. We're dealing with
peoples financial data here, nothing is going to destroy our reputation
quicker than releasing code that screws things up.

Conrad
Eagerly anticipating some serious pre-release testing real soon now.



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposals about gnucash-gnome2

Didier Vidal
In reply to this post by Christian Stimming
[...]
> An interesting side-effect of a 1.8.12 release is that we as a developer team
> communicate the fact that we're alive and active and caring about the users,
> all the while such a release is technically quite easy for us. And of course
> the respective announcement can be used to communicate the active gnome2
> progress.
This would be more effective if we could communicate on a target date
for a gnome2 beta version of gnucash. Preferably less than 3 month after
1.8.12

Didier.

>
> Regards,
>
> Christian
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposals about gnucash-gnome2

Andrew Sackville-West
In reply to this post by Conrad Canterford


Conrad Canterford wrote:

>
> Also, can I remind people that we will need *at least* a months worth of
> pre-releases for testing before the actual release. That's if I and
> other testers get seriously into the testing and hammer it fairly hard.
> I'd think 6 to 8 weeks would be more realistic. When thinking of when
> the release is going to happen, add that time on. We're dealing with
> peoples financial data here, nothing is going to destroy our reputation
> quicker than releasing code that screws things up.
>


Been lurking lately and wonder what is involved in testing and how can I
help? I'm a daily user running three businesses with gnucash and have
some very ancient programming experience. If I can help out by testing
and (hopefully) giving useful feedback, I'd be happy to do it.

A
>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposals about gnucash-gnome2

Chris Lyttle
In reply to this post by Christian Stimming
Well Christian, this is timely. For about the first time in 6 months or
so I have some bandwidth to be able to do some release work. I am not
sure right now that I'd be able to handle a more often release cycle
that gnucash 1.10/2.0 release would entail, but I'd certainly be willing
to devote some time towards it.
As for 1.8.12, do we still want to do the release build on rh7.3 or use
a perhaps more modern build of rh?

Chris

On Wed, 2005-10-05 at 22:05 +0200, Christian Stimming wrote:

> Hi Developers,
>
> two different issues just popped up about the current gnucash development.
> First, some latest changes in CVS seem to have introduced unexpected
> conflicts, though the changes are considered to be of lower priority by many
> developers here. Second, the pressure for a gnome2-gnucash is increasing
> all around. I have some proposals as a response to these points, and I'd like
> to explain these here.
>
> I think that gnucash isn't that far away from an actual gnome2 release
> anymore. However, we as a developer team have been lacking a clear
> communication about the current status, the currently important goals, and
> the roadmap for the near-future development. I propose that we should firmly
> restating the actual vision for gnucash and the current view of the  
> developer team on the best roadmap to a gnome2 release. Something like: "The
> gnome2 port of gnucash is under way. At first, we will try to keep all major
> features of the 1.8.x release but under the new GUI toolkit. This might be
> achieved in the next 2..4..6 months. Only after we achieve an initial
> gnucash-gnome2 series, we will focus on improving the existing features and
> add brand-new additional features to keep our status as the best free finance
> manager around." As a relatively easy technical step to underline our
> commitment to a gnome2 release, I would  suggest to merge back the
> gnucash-gnome2-dev branch into HEAD. On IRC, David Hampton already agreed to
> work on this important CVS action.
>
> Related to this is the question about the qof-work, which is not immediately
> vital for the gnucash-gnome2 port. In my opinion the work in that area is
> going on well, but unfortunately the goals of the qof-work and those of other
> developers silently diverged at some point. I think we should clearly confirm
> that the architectural changes related to qof, including the division between
> an external libqof and gnucash, are *not* immediatly the focus of the
> gnucash-gnome2 port. This work should therefore (please, please) *not*
> interfere with work that improves the gnome2 port and only the gnome2 port.
> The technical solution to that issue is quite simple: I would suggest that
> the qof-work should get its own CVS branch (qof-devel or similar), and then
> those working on qof will be responsible for merging other people's changes
> into that branch. This will of course be quite easy once the gnome2-branch is
> merged back into HEAD, so that the HEAD branch will be the point for the
> gnome2 progress.
>
> And additionally I would again propose to have a 1.8.12 release, because it
> contains numerous bugfixes which should be released (please please :). I would
> volunteer in the tarball preparation and the necessary announcements.
>
> An interesting side-effect of a 1.8.12 release is that we as a developer team
> communicate the fact that we're alive and active and caring about the users,
> all the while such a release is technically quite easy for us. And of course
> the respective announcement can be used to communicate the active gnome2
> progress.
>
> Regards,
>
> Christian
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
--
RedHat Certified Engineer #807302549405490.
Checkpoint Certified Security Expert 2000 & NG
--------------------------------------------
        |^|
        | |   |^|
        | |^| | |  Life out here is raw
        | | |^| |  But we will never stop
        | |_|_| |  We will never quit
        | / __> |  cause we are Metallica
        |/ /    |
        \       /
         |     |
--------------------------------------------

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.8.12 draft release notes (was: Proposals about gnucash-gnome2)

Christian Stimming
Hi Chris,

this is great news! Thanks for coming back on this. I don't think we
have to decide on the gnucash-gnome2 release cycle right now. Right now
it is just sufficient to make that 1.8.12 release, and then continue
coding on the gnome2 code.

Chris Lyttle schrieb:
> Well Christian, this is timely. For about the first time in 6 months or
> so I have some bandwidth to be able to do some release work. I am not
> sure right now that I'd be able to handle a more often release cycle
> that gnucash 1.10/2.0 release would entail, but I'd certainly be willing
> to devote some time towards it.

Thanks for that. In order to help out a bit, I updated the draft 1.8.12
release notes from August. See below.

As for a gnome2 release date announcement: I agree with Didier Vidal
that we should use this opportunity to announce a release date for the
very first pre-alpha pre-beta pre-whatever gnucash-gnome2 release
(called 1.9.x, the uneven number emphasizing the development nature).
IMHO the current gnome2-branch can be released for public testing
already in a few weeks -- most of the main "places for work" are only
seldomly crashing :-). I would be totally fine if we expect something
between 4-8 months of 1.9.x development releases, until we consider the
code base stable enough for a stable release. Given such a timeframe, I
think it is possible for us to make very first 1.9.x testing releases in
a few weeks, so announcing "December 2005" would be appropriate. (And
such a date is still flexible enough so that a delay into January 2006
would be tolerated as well.)

> As for 1.8.12, do we still want to do the release build on rh7.3 or use
> a perhaps more modern build of rh?

Do you mean as a testing environment, as the build tool environment, or
as a binary package environment? IMHO you don't need to create binary
packages anyway. I saw that you faithfully created binary RPMs for all
gnucash releases that we had, but IMHO we just don't need that. We
cannot provide binary RPMs for even the major distributions because
there are just too many of them around. If at your place RH is the
single largest distributions, there will surely be other places where
other distros have the majority (e.g. suse in Germany). So given a
limited time for release work, I would definitely propose to not release
any binary RPMs but only the .tar.gz packages. The majority of users
will have to compile gnucash on their own anyway -- or they will wait
until their distributor provides the binary RPM. Of course if you really
want to compile RPMs then just go ahead, but the time consumption of the
RPM creation shouldn't be the limiting factor in making such a release.

Regards

Christian



***** draft release notes for gnucash-1.8.12 ******* DRAFT *******

The GnuCash development team proudly announces a new stable release of
the GnuCash Open Source Accounting Software version 1.8.12, which is
expected to be the very last release of the gtk1-based gnucash-1.8.x
series. The next release series of gnucash will be based on gtk2/gnome2,
and the first pre-release packages are expected to be released [e.g.]
this December [or whatever we decide to consider appropriate].

FAQ: "Is this a gnome2 application?" A: "No." This release still belongs
to GnuCash's 1.8.x series which is not yet ported to gtk2/gnome2. Read
more below.

What's New in GnuCash 1.8.12?

* Online Banking/HBCI improvements: Debit notes are fixed again;
Bank-internal money transfers are now supported, if the HBCI bank offers
them; Setup wizard can now works with HBCI, OFX-Connect, and other
AqBanking backends; Fix character encoding issues in utf-8 locales; Fix
date interval in the import transaction matcher for OFX and HBCI import;
Fix PIN entry bug.

* New currencies added: Romanian Leu, Bulgarian Lev, Malagasy Ariary

* Fix problem with long date formats in some locales (bug#170444)

* Add configure macros for mips, mipsel, arm, and m68k; Fix compilation
on OpenBSD 64bit architectures

* Updated translations: German, Italian, Kinyarwanda

FAQ: "Is this a gnome2 application?"
A: "No." This release still belongs to GnuCash's 1.8.x series which is
not yet ported to gtk2/gnome2. In other words, this release is still
based on gtk1.2/gnome1. The developers are working on a gtk2/gnome2
version of GnuCash, but it still takes a lot of time.
See http://gnomesupport.org/wiki/index.php/GnuCashPortingStatus for the
status of the Gtk2 port. GnuCash makes use of several custom widgets as
well as the Guppi graphing library. To port to gtk2 involves rewriting
those widgets (e.g. the ledger, or the account hierarchy which uses
GtkCTree) into the appropriate GTK2 widgets and changing the graphing
code to use Jody's new gnome-office-graph code of Gnumeric (Guppi was
never ported to gtk2 and is a dead project). But given that the GnuCash
team is extremely short on programmers, the process has to exist in
parallel to existing product improvements, resulting in a very gradual
porting process.
If you can code C, by all means, volunteer your time, see
http://gnomesupport.org/wiki/index.php/GnuCashDevelopment

***** draft release notes for gnucash-1.8.12 ******* DRAFT *******
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposals about gnucash-gnome2

Conrad Canterford
In reply to this post by Andrew Sackville-West
On Wed, 2005-10-05 at 17:21 -0700, Andrew Sackville-West wrote:
> Been lurking lately and wonder what is involved in testing and how can I
> help? I'm a daily user running three businesses with gnucash and have
> some very ancient programming experience. If I can help out by testing
> and (hopefully) giving useful feedback, I'd be happy to do it.

Putting my business transactions through gnucash is pretty much the
majority of what I've done with testing in the past. I've gone about
doing my normal stuff in the new version, and seen what breaks (of
course, I had a backup copy of the datafile). Part of this process
included doing things in different ways to achieve the same results and
deliberately trying to do things that should not be valid, but
ultimately all I've been doing is trying to think of different ways
people might approach trying to do what I normally do.

The very first thing that I have done in the past has been to set up a
completely new set of accounts, and deliberately set out to try and
break bits of the code that I know have changed between versions. That
was much easier when I was actually keeping a close eye on development.
I generally used to check things which I knew had had fixes applied to
them, and things which I figured might be broken by those fixes - again
this was much easier when I actually had some idea what was going on in
the code, which I do not any more. I'll admit that I wasn't particularly
methodical or thorough, as I have subsequently had to be when doing
testing for real money.

In short, I'd encourage you to start using the pre-release versions as
soon as they become available (keeping backup copies, of course!), and
reporting anything you find that is "not right" (and may not include
bugs, as such, but may be just minor UI tweaks to make the interface
work better).

Conrad.

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposals about gnucash-gnome2

Chris Shoemaker
In reply to this post by Christian Stimming
On Wed, Oct 05, 2005 at 10:05:29PM +0200, Christian Stimming wrote:

> Hi Developers,
>
> two different issues just popped up about the current gnucash development.
> First, some latest changes in CVS seem to have introduced unexpected
> conflicts, though the changes are considered to be of lower priority by many
> developers here. Second, the pressure for a gnome2-gnucash is increasing
> all around. I have some proposals as a response to these points, and I'd like
> to explain these here.
>
> I think that gnucash isn't that far away from an actual gnome2 release
> anymore. However, we as a developer team have been lacking a clear
> communication about the current status, the currently important goals, and
> the roadmap for the near-future development. I propose that we should firmly
> restating the actual vision for gnucash and the current view of the  
> developer team on the best roadmap to a gnome2 release. Something like: "The
> gnome2 port of gnucash is under way. At first, we will try to keep all major
> features of the 1.8.x release but under the new GUI toolkit. This might be
> achieved in the next 2..4..6 months. Only after we achieve an initial
> gnucash-gnome2 series, we will focus on improving the existing features and
> add brand-new additional features to keep our status as the best free finance
> manager around." As a relatively easy technical step to underline our
> commitment to a gnome2 release, I would  suggest to merge back the
> gnucash-gnome2-dev branch into HEAD. On IRC, David Hampton already agreed to
> work on this important CVS action.

Sounds like a good plan.

>
> Related to this is the question about the qof-work, which is not immediately
> vital for the gnucash-gnome2 port. In my opinion the work in that area is
> going on well, but unfortunately the goals of the qof-work and those of other
> developers silently diverged at some point. I think we should clearly confirm
> that the architectural changes related to qof, including the division between
> an external libqof and gnucash, are *not* immediatly the focus of the
> gnucash-gnome2 port. This work should therefore (please, please) *not*
> interfere with work that improves the gnome2 port and only the gnome2 port.
> The technical solution to that issue is quite simple: I would suggest that
> the qof-work should get its own CVS branch (qof-devel or similar), and then
> those working on qof will be responsible for merging other people's changes
> into that branch. This will of course be quite easy once the gnome2-branch is
> merged back into HEAD, so that the HEAD branch will be the point for the
> gnome2 progress.

Sounds like a _great_ plan.

>
> And additionally I would again propose to have a 1.8.12 release, because it
> contains numerous bugfixes which should be released (please please :). I would
> volunteer in the tarball preparation and the necessary announcements.
>
> An interesting side-effect of a 1.8.12 release is that we as a developer team
> communicate the fact that we're alive and active and caring about the users,
> all the while such a release is technically quite easy for us. And of course
> the respective announcement can be used to communicate the active gnome2
> progress.

I agree.

-chris

>
> Regards,
>
> Christian
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Release schedule [WAS: Proposals about gnucash-gnome2]

Chris Shoemaker
In reply to this post by Didier Vidal
On Thu, Oct 06, 2005 at 01:12:28AM +0200, Didier Vidal wrote:
> [...]
> > An interesting side-effect of a 1.8.12 release is that we as a developer team
> > communicate the fact that we're alive and active and caring about the users,
> > all the while such a release is technically quite easy for us. And of course
> > the respective announcement can be used to communicate the active gnome2
> > progress.
> This would be more effective if we could communicate on a target date
> for a gnome2 beta version of gnucash. Preferably less than 3 month after
> 1.8.12

I think in the past, we've been focused on what code changes are
required for a G2 release.  But, at least for alpha releases, can't we
just release regularly and see how many releases it takes to go beta
and then final?

It's not like we're breaking stuff on purpose.  I think that right
now, any cvs snapshot that builds is suitable for release as alpha.
How hard is the release process?  Can it be automated into a, say
biweekly, release?

We could say, o.k. let's ensure that the tree builds on the 1st and
3rd Monday of the month, because someone's cronjob is sucking up the
cvs into a tgz.  What else is involved in an alpha release?  

-chris

>
> Didier.
>
> >
> > Regards,
> >
> > Christian
> > _______________________________________________
> > gnucash-devel mailing list
> > [hidden email]
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule [WAS: Proposals about gnucash-gnome2]

Derek Atkins
Quoting Chris Shoemaker <[hidden email]>:

> I think in the past, we've been focused on what code changes are
> required for a G2 release.  But, at least for alpha releases, can't we
> just release regularly and see how many releases it takes to go beta
> and then final?

That /is/ what we did for the 1.7 test releases.  We had a new release
every two weeks, approximately.

> It's not like we're breaking stuff on purpose.  I think that right
> now, any cvs snapshot that builds is suitable for release as alpha.
> How hard is the release process?  Can it be automated into a, say
> biweekly, release?

It's unclear if it can be automated...

> We could say, o.k. let's ensure that the tree builds on the 1st and
> 3rd Monday of the month, because someone's cronjob is sucking up the
> cvs into a tgz.  What else is involved in an alpha release?

You need to modify the NEWS, README, and configure.in files with the
release numbers..  This can't be easily automated, I don't think.
The release tag can certainly be automated, provided you have a
cvs writer in the cron job...

Granted, we could probably write a script that makes the necessary
modifications, commits the changes, tags the release, and runs
./autogen.sh ; make distcheck

-derek
--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule [WAS: Proposals about gnucash-gnome2]

Chris Shoemaker
On Thu, Oct 06, 2005 at 10:36:14AM -0400, Derek Atkins wrote:
> Quoting Chris Shoemaker <[hidden email]>:
>
> >I think in the past, we've been focused on what code changes are
> >required for a G2 release.  But, at least for alpha releases, can't we
> >just release regularly and see how many releases it takes to go beta
> >and then final?
>
> That /is/ what we did for the 1.7 test releases.  We had a new release
> every two weeks, approximately.

Most good ideas are not original. :)

>
> >It's not like we're breaking stuff on purpose.  I think that right
> >now, any cvs snapshot that builds is suitable for release as alpha.
> >How hard is the release process?  Can it be automated into a, say
> >biweekly, release?
>
> It's unclear if it can be automated...
>
> >We could say, o.k. let's ensure that the tree builds on the 1st and
> >3rd Monday of the month, because someone's cronjob is sucking up the
> >cvs into a tgz.  What else is involved in an alpha release?
>
> You need to modify the NEWS, README, and configure.in files with the
> release numbers..  This can't be easily automated, I don't think.
> The release tag can certainly be automated, provided you have a
> cvs writer in the cron job...
>
> Granted, we could probably write a script that makes the necessary
> modifications, commits the changes, tags the release, and runs
> ./autogen.sh ; make distcheck

Yeah, release number increments are easy to automate.  And I think the
typical alpha tester would be satisfied with a verbatim selection of
the ChangeLog since last release.

-chris

>
> -derek
> --
>       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>       Member, MIT Student Information Processing Board  (SIPB)
>       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>       [hidden email]                        PGP key available
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule [WAS: Proposals about gnucash-gnome2]

Derek Atkins
Quoting Chris Shoemaker <[hidden email]>:

>> Granted, we could probably write a script that makes the necessary
>> modifications, commits the changes, tags the release, and runs
>> ./autogen.sh ; make distcheck
>
> Yeah, release number increments are easy to automate.  And I think the
> typical alpha tester would be satisfied with a verbatim selection of
> the ChangeLog since last release.

Well, want to spend a little time to write the script that does all this?

> -chris

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule [WAS: Proposals about gnucash-gnome2]

Chris Shoemaker
On Thu, Oct 06, 2005 at 10:51:45AM -0400, Derek Atkins wrote:

> Quoting Chris Shoemaker <[hidden email]>:
>
> >>Granted, we could probably write a script that makes the necessary
> >>modifications, commits the changes, tags the release, and runs
> >>./autogen.sh ; make distcheck
> >
> >Yeah, release number increments are easy to automate.  And I think the
> >typical alpha tester would be satisfied with a verbatim selection of
> >the ChangeLog since last release.
>
> Well, want to spend a little time to write the script that does all this?

Honestly, not really.  I'm not familiar with the release process.
But, if no one else will, then I guess I can take a whack.

Can we outline the process?

* clean cvs co
* change GNUCASH_MICRO_VERSION in configure.in
* ./autogen.sh && make distcheck
* post tgz to website
* post new ChangeLog entries to website
* cvs commit
* cvs tag

what else?

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposals about gnucash-gnome2

Josh Sled
In reply to this post by Andrew Sackville-West
On Wed, 2005-10-05 at 17:21 -0700, Andrew Sackville-West wrote:
> Been lurking lately and wonder what is involved in testing and how can I
> help? I'm a daily user running three businesses with gnucash and have
> some very ancient programming experience. If I can help out by testing
> and (hopefully) giving useful feedback, I'd be happy to do it.

- side-by-side comparisons of 1.8 and G2 looking for bugs, differences
  and regressions.  This can happen at any point... including now so we
  have a good handle on how much work is left.  Anything noted should
  go into GNOME2_STATUS (rather than bugzilla).

- a canonical set of test data files would be invaluable as people come
  on board and want to test or report issues.  While we also want to
  encourage people to use their own, real, data to expose the code to
  variety, it's nice to have a known set of data to share, reproduce,
  converse-about and synchronize against.

  My ideal version of these files would include the minimum number of
  cases to test every feature, account-type, default- and
  secondary-commodity, reconciliation scenario, and situation.  
  Obviously this is impractical, but we can at least hit the major ones
  pretty easily.

  We'd also want a set of fairly regular data to test reporting,
  balance-computation, &c.  One could probably script-generate some QIF
  transactions to import (or maybe an XML datafile directly) or get
  creative with their system clock and the scheduled transactions, to
  create a year's worth of data with computable properties (all
  expenses should sum to $20,000; the Expenses:Rent should have 12 txns
  of $1000 ea., &c.)

- test instructions or scripts for other/new people to execute against
  in different environments... including us. :)  Especially with all
  the UI work done, we're going to need to test actually stepping
  through a set of interactions with the UI to make sure things work as
  expected.  The other side is that if people are stepping through the
  same set of instructions, you're only testing that one path through
  the UI and missing other cases... but I still think there's value
  here.

...jsled
--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule [WAS: Proposals about gnucash-gnome2]

Derek Atkins
In reply to this post by Chris Shoemaker
Quoting Chris Shoemaker <[hidden email]>:

>> Well, want to spend a little time to write the script that does all this?
>
> Honestly, not really.  I'm not familiar with the release process.
> But, if no one else will, then I guess I can take a whack.

Hehe...

> Can we outline the process?
>
> * clean cvs co
> * change GNUCASH_MICRO_VERSION in configure.in

You also need to change the AC_INIT setting in configure.in and the
NEWS file.

> * ./autogen.sh && make distcheck
> * post tgz to website
> * post new ChangeLog entries to website

This can just be the NEWS file...

> * cvs commit
> * cvs tag
>
> what else?

I can't think of anything else offhand.

> -chris

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule [WAS: Proposals about gnucash-gnome2]

Christian Stimming
Hi,

Derek Atkins schrieb:
>> Can we outline the process?
>>
>> * clean cvs co
>> * change GNUCASH_MICRO_VERSION in configure.in
>
> You also need to change the AC_INIT setting in configure.in

Really? I would say the modification belongs in AM_INIT_AUTOMAKE and
thankfully this already uses GNUCASH_MICRO_VERSION. So changing
GNUCASH_MICRO_VERSION IMHO is enough.

>> * ./autogen.sh && make distcheck
>> * post tgz to website
>> * post new ChangeLog entries to website
>
> This can just be the NEWS file...
>
>> * cvs commit
>> * cvs tag
>>
>> what else?

You might want to add an entry to the ChangeLog, "released 1.9.bla".
Other than that, I think for such automated alpha releases it is
sufficient to expect that people look into the ChangeLog themselves.

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule [WAS: Proposals about gnucash-gnome2]

Derek Atkins
Quoting Christian Stimming <[hidden email]>:

> Hi,
>
> Derek Atkins schrieb:
>>> Can we outline the process?
>>>
>>> * clean cvs co
>>> * change GNUCASH_MICRO_VERSION in configure.in
>>
>> You also need to change the AC_INIT setting in configure.in
>
> Really? I would say the modification belongs in AM_INIT_AUTOMAKE and
> thankfully this already uses GNUCASH_MICRO_VERSION. So changing
> GNUCASH_MICRO_VERSION IMHO is enough.

in configure.in in g2:

AC_INIT(gnucash, 1.99.0,
http://bugzilla.gnome.org/enter_bug.cgi?product=GnuCash)
AM_INIT_AUTOMAKE(AC_PACKAGE_NAME, AC_PACKAGE_VERSION)

So, yes, I think you need to change this in addition to GNUCASH_MICRO_VERSION.

>>> * ./autogen.sh && make distcheck
>>> * post tgz to website
>>> * post new ChangeLog entries to website
>>
>> This can just be the NEWS file...
>>
>>> * cvs commit
>>> * cvs tag
>>>
>>> what else?
>
> You might want to add an entry to the ChangeLog, "released 1.9.bla".
> Other than that, I think for such automated alpha releases it is
> sufficient to expect that people look into the ChangeLog themselves.

True, good point.

> Christian

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposals about gnucash-gnome2

Andrew Sackville-West
In reply to this post by Josh Sled
I'll be honest that I don't have time to do direct side-by-side
comparisons or use a canonical set of test data (I've got too much real
book-keeping to do...). But I'm more than happy to check out a new
version every couple of weeks, and use it and report back. Obviously,
there are parts of the program that I don't use, or rarely use, but I do
  regularly use a/r and a/p, many different reports, and .qif imports
and maintain three different data files with transaction counts from 30
or so a month to upto say 250 a month. So my question is, what version
would you like some testing on, and when should I start? Can you make an
announcement on -user that such-and-such version is ready for pre-alpha
testing, buyer beware ;), and then some of us can jump in?

I think, and hope you realise, that you guys have a fantastic program
and the users are very loyal and more than willing to help out to the
extent they can and I suspect you'd have plenty of testers.

As far as backups go, its as simple as a script to copy or rdiff the
datafiles to another directory before opening gnucash --nofile. At least
that's what I'd do so I would never lose more than one session's work
(not that hard to duplicate) in event of catastrophic failure.

A

Josh Sled wrote:

> On Wed, 2005-10-05 at 17:21 -0700, Andrew Sackville-West wrote:
>
>>Been lurking lately and wonder what is involved in testing and how can I
>>help? I'm a daily user running three businesses with gnucash and have
>>some very ancient programming experience. If I can help out by testing
>>and (hopefully) giving useful feedback, I'd be happy to do it.
>
>
> - side-by-side comparisons of 1.8 and G2 looking for bugs, differences
>   and regressions.  This can happen at any point... including now so we
>   have a good handle on how much work is left.  Anything noted should
>   go into GNOME2_STATUS (rather than bugzilla).
>
> - a canonical set of test data files would be invaluable as people come
>   on board and want to test or report issues.  While we also want to
>   encourage people to use their own, real, data to expose the code to
>   variety, it's nice to have a known set of data to share, reproduce,
>   converse-about and synchronize against.
>
>   My ideal version of these files would include the minimum number of
>   cases to test every feature, account-type, default- and
>   secondary-commodity, reconciliation scenario, and situation.  
>   Obviously this is impractical, but we can at least hit the major ones
>   pretty easily.
>
>   We'd also want a set of fairly regular data to test reporting,
>   balance-computation, &c.  One could probably script-generate some QIF
>   transactions to import (or maybe an XML datafile directly) or get
>   creative with their system clock and the scheduled transactions, to
>   create a year's worth of data with computable properties (all
>   expenses should sum to $20,000; the Expenses:Rent should have 12 txns
>   of $1000 ea., &c.)
>
> - test instructions or scripts for other/new people to execute against
>   in different environments... including us. :)  Especially with all
>   the UI work done, we're going to need to test actually stepping
>   through a set of interactions with the UI to make sure things work as
>   expected.  The other side is that if people are stepping through the
>   same set of instructions, you're only testing that one path through
>   the UI and missing other cases... but I still think there's value
>   here.
>
> ...jsled
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposals about gnucash-gnome2

Josh Sled
In reply to this post by Christian Stimming
On Wed, 2005-10-05 at 22:05 +0200, Christian Stimming wrote:
> developer team on the best roadmap to a gnome2 release. Something like: "The
[deletia]
> manager around." As a relatively easy technical step to underline our
> commitment to a gnome2 release, I would  suggest to merge back the
> gnucash-gnome2-dev branch into HEAD. On IRC, David Hampton already agreed to
> work on this important CVS action.

+1 on the statement, and +1 on the branch-collapse plan.


> The technical solution to that issue is quite simple: I would suggest that
> the qof-work should get its own CVS branch (qof-devel or similar), and then
> those working on qof will be responsible for merging other people's changes

+1 here too.


> And additionally I would again propose to have a 1.8.12 release, because it

+0; no objection.

...jsled
--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
12