On Wednesday 26 March 2014 12:53:36 Derek Atkins wrote:
John Ralls jra...@ceridwen.us writes:
It will be. When we’re ready to release 2.8, the ‘maint’ branch will
be renamed to ‘2.6’; when we release 2.8.3, we’ll create a new
‘maint’ branch from ‘master’. We could even do that at 2.8.0,
On Tuesday 25 March 2014 09:17:29 John Ralls wrote:
On Mar 25, 2014, at 8:15 AM, Geert Janssens janssens-ge...@telenet.be wrote:
If no one beats me to it I'll try to adapt the git wiki page with
this info in the coming days.
OK. The main change seems to me to be that instead of making a
On Saturday 22 March 2014 18:39:13 John Ralls wrote:
On Mar 22, 2014, at 4:01 PM, Geert Janssens janssens-ge...@telenet.be wrote:
I like the workflow as proposed in the git workflows man page
(section Branch management for a release and following). They
propose a long-term maintenance
On Mar 27, 2014, at 2:13 AM, Geert Janssens janssens-ge...@telenet.be wrote:
On Saturday 22 March 2014 18:39:13 John Ralls wrote:
On Mar 22, 2014, at 4:01 PM, Geert Janssens janssens-ge...@telenet.be
wrote:
I like the workflow as proposed in the git workflows man page
(section Branch
On Mar 27, 2014, at 1:47 AM, Geert Janssens janssens-ge...@telenet.be wrote:
On Tuesday 25 March 2014 09:17:29 John Ralls wrote:
On Mar 25, 2014, at 8:15 AM, Geert Janssens janssens-ge...@telenet.be
wrote:
If no one beats me to it I'll try to adapt the git wiki page with
this info in
On Thursday 27 March 2014 07:25:20 John Ralls wrote:
On Mar 27, 2014, at 2:13 AM, Geert Janssens janssens-ge...@telenet.be wrote:
On Saturday 22 March 2014 18:39:13 John Ralls wrote:
On Mar 22, 2014, at 4:01 PM, Geert Janssens janssens-ge...@telenet.be
wrote:
I like the workflow as
.
They'll need to be frequently merged back-and-forth with master to
keep everything in sync. Do you think that will add too much extra
work and that we should just do everything in master as we have been?
The branching strategy in git will be an experiment for me as I never worked in
an environment
have been?
The branching strategy in git will be an experiment for me as I never worked
in an environment before that used git and a true git workflow. So my opinion
on this is mostly academic.
Having said that would definitely do such big refactorings on one or more
separate feature
think that will add too much extra
work and that we should just do everything in master as we have
been?
The branching strategy in git will be an experiment for me as I
never worked in an environment before that used git and a true git
workflow. So my opinion on this is mostly
--On March 27, 2014 7:25:20 AM -0700 John Ralls jra...@ceridwen.us
wrote:
Changelog may be more difficult though we'll have to run a test to
be sure. The main question for me here is whether or not our code to
generate the Changelog file can properly handle multi-parent commits
? This is
John Ralls jra...@ceridwen.us writes:
It will be. When we’re ready to release 2.8, the ‘maint’ branch will
be renamed to ‘2.6’; when we release 2.8.3, we’ll create a new ‘maint’
branch from ‘master’. We could even do that at 2.8.0, because merging
‘maint’ into ‘master’ isn’t a big deal until
strategy to start with. If we find
details later on that
don't work very well we can always adjust.
If no one beats me to it I'll try to adapt the git wiki page with this info in
the coming days.
Geert
___
gnucash-devel mailing list
gnucash-devel
On Mar 25, 2014, at 8:15 AM, Geert Janssens janssens-ge...@telenet.be wrote:
If no one beats me to it I'll try to adapt the git wiki page with this info
in the coming days.
OK. The main change seems to me to be that instead of making a '2.6' branch
next week I'll be making a 'maint'
Branch is just a pointer to head of revisions list (node in revision tree)
.
So if you merge private branch in branch that is then pushed to public, it
will be visible like this:
http://git-scm.com/figures/18333fig0317-tn.png
But without pointer to iss53
On Mar 25, 2014, at 8:15 AM, Geert
John Ralls jra...@ceridwen.us writes:
On Mar 25, 2014, at 8:15 AM, Geert Janssens janssens-ge...@telenet.be wrote:
If no one beats me to it I'll try to adapt the git wiki page with
this info in the coming days.
OK. The main change seems to me to be that instead of making a '2.6'
branch
On Tuesday 25 March 2014 13:46:17 Derek Atkins wrote:
John Ralls jra...@ceridwen.us writes:
On Mar 25, 2014, at 8:15 AM, Geert Janssens janssens-ge...@telenet.be
wrote:
If no one beats me to it I'll try to adapt the git wiki page with
this info in the coming days.
OK. The main
On Mar 25, 2014, at 9:52 AM, Dmitry Pavlov zeldi...@gmail.com wrote:
Branch is just a pointer to head of revisions list (node in revision tree) .
So if you merge private branch in branch that is then pushed to public, it
will be visible like this:
On Mar 25, 2014, at 10:46 AM, Derek Atkins warl...@mit.edu wrote:
John Ralls jra...@ceridwen.us writes:
On Mar 25, 2014, at 8:15 AM, Geert Janssens janssens-ge...@telenet.be
wrote:
If no one beats me to it I'll try to adapt the git wiki page with
this info in the coming days.
OK.
@acernt:/tmp/git-tests/b$ git commit -m another commit in master
[master ebe2dec] another commit in master
1 file changed, 1 insertion(+)
dmitry@acernt:/tmp/git-tests/b$ git merge private
Merge made by the 'recursive' strategy.
b |1 +
1 file changed, 1 insertion(+)
dmitry@acernt:/tmp/git-tests/b
On Mar 25, 2014, at 11:35 AM, Dmitry Pavlov zeldi...@gmail.com wrote:
As I said, you'll just see a fork and merge but without identification of
private branch. I made a small local example and the result:
* 124d38e (HEAD, origin/master, master) Merge branch 'private'
|\
| * cbcff86
This topic has been brought up before but we never really came to a consensus
on how we
want to organize our branches in the official git repository. Yet I want to get
a final decision on
this before we open a master for feature development again.
To refresh memory here is a link to the
should just remove them. If we decide not to do that, we'll need to figure
out a branching strategy that carries them into new release branches.
Regardless, the 'stable' branch needs to have *something* in AC_INIT. What
should that be?
2. The release tags will be on the release branch, so `git
should just remove them. If we decide
not to do that, we'll need to figure out a branching strategy that
carries them into new release branches. Regardless, the 'stable'
branch needs to have *something* in AC_INIT. What should that be?
2. The release tags will be on the release branch, so `git
. If we decide
not to do that, we'll need to figure out a branching strategy that
carries them into new release branches. Regardless, the 'stable'
branch needs to have *something* in AC_INIT. What should that be?
2. The release tags will be on the release branch, so `git describe
As a non- (or not-yet-) developer who has tinkered with several pages
in the GnuCash wiki over several years I hope you don't mind if I
weigh in briefly on this discussion... [My password database says I
created the twt username in 2008.]
On Sat, Aug 10, 2013 at 4:13 PM, Christian Stimming
Am Samstag, 10. August 2013, 16:13:30 schrieb John Ralls:
Christian,
I get notified of changes via RSS to
http://wiki.gnucash.org/wiki/Special:NewPages rather than RecentChanges,
and I check my RSS reader 2-3 times a day.
I don't remember seeing any spammer-user who'd created a user page,
On Aug 11, 2013, at 12:51 PM, Christian Stimming christ...@cstimming.de wrote:
Am Samstag, 10. August 2013, 16:13:30 schrieb John Ralls:
Christian,
I get notified of changes via RSS to
http://wiki.gnucash.org/wiki/Special:NewPages rather than RecentChanges,
and I check my RSS reader 2-3
Hi John,
I noticed you regularly delete spam pages in our wiki, which is a very good
thing to do. As you and I and hopefully others have noticed, we now get
approx. 1-5 spam pages created every day, which have to be deleted manually.
This is even though new pages can be created by users who
On Aug 10, 2013, at 2:13 PM, Christian Stimming christ...@cstimming.de wrote:
Hi John,
I noticed you regularly delete spam pages in our wiki, which is a very good
thing to do. As you and I and hopefully others have noticed, we now get
approx. 1-5 spam pages created every day, which have
On Aug 10, 2013, at 4:13 PM, John Ralls jra...@ceridwen.us wrote:
On Aug 10, 2013, at 2:13 PM, Christian Stimming christ...@cstimming.de
wrote:
Hi John,
I noticed you regularly delete spam pages in our wiki, which is a very good
thing to do. As you and I and hopefully others have
Am Samstag, 3. Dezember 2011, 16:40:07 schrieb Donald Allen:
I've been watching with interest the messages flying by from various
people that confirm the impression (from just trying to build it) that
Gnucash has become a gigantic hairball. John Ralls has been saying a
number of things that
I can tell you that GnuCash is rock solid and reliable. It may be
boring, but it is really stable and really good. To some degree, as
long as it continues to be this good, it really doesn't matter what is
in the hairball, it must be good too :) Think about how many flawless
backups GnuCash
Better to either imbed Guile in the executable or start replacing it piece
by piece.
Too many dependencies on other peoples work.
Mentor Graphics faced the same problem with 16,000,000 lines of source code
for one product written in several languages.
They laid off the US help and sent the code
On 03 Dec 2011, at 11:40 PM, Donald Allen wrote:
Gnucash has been around
for a long time, and its life-span covers the development of a lot of
tools. If you were going to start with a blank sheet of paper today, I
doubt very much whether you would do a lot of the system as it is
today. The
As with Donald, I haven't contributed any code, but I would tend to agree
that there is a problem.
A rewrite from scratch is a drastic solution to that not quite as drastic
problem.
The roadmap on the Wiki is more like a wishlist, and the schedule is, well,
non existent. Sorry, I see that there
This is becoming a good, healthy discussion, with a variety of
viewpoints that make for interesting reading.
But to those who seem to think that starting over is *always* a bad
idea, I'd ask you if you'd like to be running Windows 3.1.14159/MSDOS
19 on your PCs, instead of something based on
be part of ones' strategy all
along.
Keep in mind that if you did start over, the current system
wouldn't be a total loss. I'm sure there is a lot of value in things
like accounting rules that it enforces, and other knowledge embedded in
the code. Some of it might be salvageable by lifting parts
On Sun, 04 Dec 2011 18:35:08 +0200, Graham Leggett wrote:
On 03 Dec 2011, at 11:40 PM, Donald Allen wrote:
Gnucash has been around
for a long time, and its life-span covers the development of a lot of
tools. If you were going to start with a blank sheet of paper today, I
doubt very much
I've been watching with interest the messages flying by from various
people that confirm the impression (from just trying to build it) that
Gnucash has become a gigantic hairball. John Ralls has been saying a
number of things that sound smart (I'll tell you later where to send
the check, John)
On Sat, 2011-12-03 at 16:40 -0500, Donald Allen wrote:
The big question is, when is it worth it to cut your losses and
start over?
I don't have strong opinions, but others do, in the opposite direction:
Joel Spolsky says (in the context of Netsape)
single worst strategic mistake that any
40 matches
Mail list logo
