Further Ledger Development

[Alexis]

Hello everyone,
lately I have been providing some patches to Ledger and John was
kind enough to help out with valuable feedback, insightful conversations,
and allow me access to the official Ledger repository. Thanks John!

I am committed to do what I can to move Ledger forward, my main focus
is getting rid of the segmentation faults, adding more tests, improving
the documentation by covering all available options, and expanding the
Python module.

John and I have been talking about various aspects and which need
more work and I am currently planning what issues should be addressed
for the next release (3.1.1).
I am uncertain who has a say (apart from John ;) in deciding what bugs
should be fixed and which features implemented, so make yourself
heard and let's talk about important issues to plan a roadmap.

John and I agreed to keep all P1 bugs (8 in total) and moved all P2 bugs
to P3, so I can move bugs I feel should be addressed for Ledger 3.1.1
back to P2 and start working on it.
Since I'm not yet too familiar with all aspects of Ledger I will
also address minor bugs that I think will help me in digging deeper
into Ledger's code.

I found 23 segmentation fault related bugs in Bugzilla and I would like
to set their Status to UNCONFIRMED, then go through them one by one
and schedule the ones that can be reproduced with a master build for
3.1.1 and set their Status to CONFIRMED.

John and I agreed to follow the git-flowน model for development, which
means the master branch will only see updates when a new version is
released as of now and development will happen on the next branch, so
please make pull request against next from now on.

You're more than welcome to help out if you can by contributing patches,
going through Bugzilla verifying that bugs are still reproducible,
sharing your knowledge so you or someone else can document it, add
tests, tell your story with Ledger, share ideas or cool things you've
done with Ledger, the community and Ledger will benefit from you contribution.

It would be great if we can coordinate our work to gain the most from
our joint effort and I invite you to talk to me; I'm afh in #ledger.


Thanks,
Alexis


น http://nvie.com/posts/a-successful-git-branching-model/
https://github.com/nvie/gitflow

[Craig Earls]

Nice to have you aboard Alexis! I have no suggestions on bug fixes as my workflow doesn't expose any. 

--

---
You received this message because you are subscribed to the Google Groups "Ledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Craig, Corona De Tucson, AZ
enderw88.wordpress.com

[John Wiegley]

>>>>> Alexis <surr...@gmail.com> writes:

> John and I agreed to follow the git-flowน model for development, which means
> the master branch will only see updates when a new version is released as of
> now and development will happen on the next branch, so please make pull
> request against next from now on.

Thanks for all your hard work, Alexis! The only thing I wanted to mention
about git-flow, and the reason it was abandoned previously: is that releases
were far and few between, and so master was stagnating and everyone was
starting to use the next branch directly anyway (thus next became the new
master).

So I think that if we want git-flow to be successful for us, we should be
committed to fairly frequent releases on the master branch, which may likely
mean we move to a four-point version number and do point releases on a weekly
or semiweekly basis. How does that sound? Essentially, any time you have a
build which passes all tests and you think is sane, it's a candidate for a
mini-release to master.

John

[Simon Michael]

That's exciting news, great work Alexis.

[Eric Abrahamsen]

Alexis <surr...@gmail.com> writes:

> Hello everyone,
> lately I have been providing some patches to Ledger and John was
> kind enough to help out with valuable feedback, insightful conversations,
> and allow me access to the official Ledger repository. Thanks John!
>
> I am committed to do what I can to move Ledger forward, my main focus
> is getting rid of the segmentation faults, adding more tests, improving
> the documentation by covering all available options, and expanding the
> Python module.

Not very sexy but... more docs! More reporting syntax examples, and
real-world scenarios. The docs are a little bit wrong in a few places,
but mostly they just need more examples. Larger tutorials (keeping track
of stock, working in multiple currencies, etc) would be great, as many
of the questions on this list are about that stuff.

And thanks for working on it! Coincidentally, my ledger-git Arch package
is updating as I type this...

Eric

[Alexis]

Hi John,
the way I understand git-flow is that for frequent pre-releases the
release branches are used, so master always points to the last stable release,
currently this would be release/3.1.0 (created from the v3.1 tag).

As development on 3.1.1 begins a branch named release/3.1.1 is created
from next, and as development on next comes along every 'stable' state
(meaning all the tests run) of next is merged into release/3.1.1.

Once the official 3.1.1 version is tagged and released the release/3.1.1
branch is merged into master and the release/3.1.1 branch becomes
'stale' and only important bugfixes are merged into it from that point on.

How does this sound?


Cheers,
Alexis

[Alexis]

Thanks all for the warm welcome =)

Eric, I agree Ledger can you more documentation, I think the
Ledger Cookbookš could use many more examples.
If you have any gems you'd like to share please do so and
if you know of any conversations on the list please share a
link so we can include that knowledge into the manual.

š http://ledger-cli.org/3.0/doc/ledger3.html#Cookbook


Cheers,
Alexis

[Martin Blais]

Actually, the command-line accounting cookbook uses Beancount for its example syntax but applies to Ledger just as well (which is why I called it the "command-line accounting cookbook" and not the "Beancount cookbook'):

http://furius.ca/beancount/doc/cookbook

http://furius.ca/beancount/doc/trading

I have more example use cases written up and on the way.

[Alexis]

Hi Martin,
oh wow, can't wait to read through those and try them!

Maybe it's a good idea add the links to the ledger-cli.org/docs.html,
what do you think? John, Simon?


Cheers,
Alexis

[John Wiegley]

>>>>> Alexis <surr...@gmail.com> writes:

> Maybe it's a good idea add the links to the ledger-cli.org/docs.html, what
> do you think? John, Simon?

Sounds good!

John

[John Wiegley]

Yes, I understand that, what I mean is perhaps as we move along during the
development of 3.1.1, we also put out quick releases of 3.1.1.1, 3.1.1.2,
etc. These wouldn't necessitate creating a new release branch, but would
rather be interim merges of release/3.1.1 into master, plus a tag.

This way, people consuming from master don't have to wait very long. My only
fear with git-flow is that if master gets really slow (say, a release every
few months), either people will think the project has stagnated, or everyone
will switch to cloning from 'next', and then our work to maintain the
integrity of 'master' won't mean a whole lot (which is what happened last
time). We need to keep all the branches relevant to the users who track them.

John