--On March 27, 2014 7:25:20 AM -0700 John Ralls
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 important to generate lo
az) to foo->bar(baz).
> > >
> > > MVC is more of a refactoring exercise, pulling everything that
> > > doesn't immediately draw on the screen or get from the user out
> > > of the GUI code into a controller layer, the objective being to
> > > mak
yer, the objective being to make switching
> > UIs a more-or-less mechanical exercise.
> >
> > 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
ng that doesn't
> immediately draw on the screen or get from the user out of the GUI
> code into a controller layer, the objective being to make switching
> UIs a more-or-less mechanical exercise.
>
> They'll need to be frequently merged back-and-forth with master to
&g
On Thursday 27 March 2014 07:25:20 John Ralls wrote:
> On Mar 27, 2014, at 2:13 AM, Geert Janssens wrote:
> > On Saturday 22 March 2014 18:39:13 John Ralls wrote:
> > > On Mar 22, 2014, at 4:01 PM, Geert Janssens
> > > wrote:
> > > > I like the workflow as proposed in the git workflows man page
On Mar 27, 2014, at 1:47 AM, Geert Janssens wrote:
> On Tuesday 25 March 2014 09:17:29 John Ralls wrote:
> > On Mar 25, 2014, at 8:15 AM, Geert Janssens
> > 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 chang
On Mar 27, 2014, at 2:13 AM, Geert Janssens wrote:
> On Saturday 22 March 2014 18:39:13 John Ralls wrote:
> > On Mar 22, 2014, at 4:01 PM, Geert Janssens
> > wrote:
> > > I like the workflow as proposed in the git workflows man page
> > > (section Branch management for a release and following)
On Saturday 22 March 2014 18:39:13 John Ralls wrote:
> On Mar 22, 2014, at 4:01 PM, Geert Janssens 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 branch. Only when a new
On Tuesday 25 March 2014 09:17:29 John Ralls wrote:
> On Mar 25, 2014, at 8:15 AM, Geert Janssens 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
On Wednesday 26 March 2014 12:53:36 Derek Atkins wrote:
> John Ralls 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 mer
John Ralls 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 ‘master’
> dive
On Mar 25, 2014, at 11:35 AM, Dmitry Pavlov 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 change in priva
s/b$ git add a
dmitry@acernt:/tmp/git-tests/b$ git commit -m "change in master"
[master 4bfde8e] change in master
1 file changed, 1 insertion(+)
dmitry@acernt:/tmp/git-tests/b$ echo "another change" > c
dmitry@acernt:/tmp/git-tests/b$ git add c
dmitry@acernt:/tmp/git-tests/
On Mar 25, 2014, at 10:46 AM, Derek Atkins wrote:
> John Ralls writes:
>
>> On Mar 25, 2014, at 8:15 AM, Geert Janssens
>> 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
On Mar 25, 2014, at 9:52 AM, Dmitry Pavlov 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:
> http://git-scm.com/figures/18333fig0317-tn.png
> But with
On Tuesday 25 March 2014 13:46:17 Derek Atkins wrote:
> John Ralls writes:
> > On Mar 25, 2014, at 8:15 AM, Geert Janssens
> > 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 inst
John Ralls writes:
> On Mar 25, 2014, at 8:15 AM, Geert Janssens 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 Janssens
On Mar 25, 2014, at 8:15 AM, Geert Janssens 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.
Have you experimen
ee we don't need an integration branch.
> > And what names do we want to use for our public branches ? Should we
> > just stick to the git workflow examples (maint, master, next) ?
> > That would make it easier to refer to the man page as the reference
> > for our workflo
logging facility and that we 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
f those is the
> recommendation to fix bugs in the *most stable* branch and merge
> upwards. That's consistent with your 'stable' branch recommendation.
>
> There are two things about a separate release branch containing only
> the release commits that require a bit
ose commits have 3 changes: The version number in configure.ac, the git
log -> ChangeLog, and the release blurb summarizing the bug fixes and
translation updates in NEWS. One could argue persuasively that NEWS and
ChangeLog are obsolete thanks to git's vastly better logging facility and
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 thread
On Aug 11, 2013, at 12:51 PM, Christian Stimming 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 times a day.
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
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
wrote:
On Aug 10, 2013, at 4:13 PM, John Ralls wrote:
>
> On Aug 10, 2013, at 2:13 PM, Christian Stimming
> 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.
On Aug 10, 2013, at 2:13 PM, Christian Stimming 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 to be deleted manu
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 ha
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 makes
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
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 ver
;ve written a number of similar
programs before do you have much of a chance of guessing right ab initio.
So rewriting and reorganization had better 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'
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 Windo
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 i
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. T
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 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 sof
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) abou
40 matches
Mail list logo
