Re: Proposed change of priorities for 1.4

[herman vierendeels <..hidden..>]

Hi,

I'd like to contribute more as well.
So a list with to-do's would be useful.

But i think we also need a document explaining a bit more the addons directory.
How does one start an addon?
e.g. by announcing one's intentions on development list?
How does one test addons with actual 1.3-branch code? Without too much
svn-administration overhead?
etc.

Thanks,
Herman

2011/12/11 Chris Travers <..hidden..>:
> Hi Erik;
>
> Thank you for your reply.
>
> On Sun, Dec 11, 2011 at 3:33 AM, Erik Huelsmann <..hidden..> wrote:
>> Hi Chris,
>>
>>> Due to the length of time it took to get 1.3 out I haven't had the
>>> time necessary to get 1.4 development going strong.
>>
>> Although I do understand that you're doing the most of the development
>> at this time (and have done so for quite some time), I believe we both
>> agree that that's not the desired long-term situation. I'm saying this
>> so that people reading this conversation feel invited to join the
>> effort: it's not intentionally solely yours, is it?
>>
>> As I've said in private conversations over the past months as well:
>> I'd like to contribute more as well, however, I'm unable to make
>> commitments to specific efforts as far as commitments to specific
>> release dates go.
>
> Right.  Nor do I think it proper to expect the same from any contributors.
>>
>>> Replacing the financial logic is going to be a big job.
>>
>> Agreed. Could we start working out a document which describes what
>> should happen? That way, it would be easier for other people to join
>> our effort: they'd simply have to read the document stating what we're
>> doing and how far along the effort we've gone so far.
>
> I think for GL stuff we are pretty close in the way things currently
> work.  For AR/AP I think we need two things:
>
> 1)  Discussions on -users asking the question "anything you think we
> need to change?" in affected areas.  Also we need to go through
> feature requests a few times in these areas too.
>
> 2)  After this, I think we can discuss workflows on -devel, as well as
> other stuff.  Take proposals back to -users after we have something
> generally discussed.
>>
>>>  What I don't want to see is another 4 year release cycle.
>>
>> Absolutely agreed!
>>
>>> So I am going to suggest we shift our priorities and
>>> don't tackle the financial logic yet.
>>
>> Thinking about this some more, I agree with you if you mean "don't
>> start coding" by "don't tackle". However, I'm thinking we could start
>> drawing up the impact assessment and plan-of-attack, the outline of
>> the DB stored procs, triggers and what-not. If we create a good
>> outline document with the mentioned components, I'm thinking it'll be
>> easier for others to join the effort. And I think we want to make that
>> as easy as possible: it'll be good for the community if/when that
>> happens.
>
> Technically by "tackle" I mean "don't make disruptive changes to the
> codebase in trunk."  Coding might be fine, but not for 1.4.
>
>>
>>> 1.4 should include as part of core
>>> 1)  New recurring transactions logic based on the template transaction
>>> addon in 1.3
>>
>> As we  discussed in our chat, this changes the way recurring
>> transactions are being posted; instead of copying a posted document,
>> the process will copy a valid (but not posted) accounting/invoice
>> document. The effect is that users will be able to schedule invoices
>> without being required to actually post one first. Even more, it
>> allows one to change all future invoices - which isn't currently
>> possible.
>>
>>> 2)  New trial balance module based on the enhanced_tb addon (currently
>>> under testing for 1.3)
>>
>> You tell me this module is much faster and more flexible, such as
>> allowing subsets of accounts to be selected. If we integrate the
>> change you mention under (3) - allowing account totals to be split by
>> the various classifications (departments, funds, etc) - that would
>> absolutely rock!
>>
>>> 3)  Generalizing projects, departments, funds, etc. out for reporting
>>> purposes.  Making these hierarchical
>>
>> Having hierarchical classifications as well as flexible
>> classifications sounds really good; can we take into account that
>> people may want to define multiple hierarchies for one specific class?
>> (i.e. two or three department hierarchies. Sounds ridiculous, but it
>> works great in practice.)
>>
>>> 4)  Refactoring contact logic, making it more flexible, ensuring that
>>> customers and vendors can be tracked as individuals instead of just
>>> companies.
>>
>> Personally, I'd assign a higher priority to developing (web)services
>> APIs than prioritizing this item. I'm not against this and definitely
>> see the value added as well. We do have use for this, but we're just
>> creating people as companies and setting them up as their own
>> contacts. It works well enough for now.
>
> yeah, but web service API's will be cleaner for this area if we do it.
>  I'd like to revive Jason's REST work regarding the old codebase too
> and add invoices, orders, etc. to those.  Reading the code there, that
> shouldn't be too hard.
>>
>>> Some of the work I have done on number/date formatting for 1.4 will be
>>> included and this will allow a wider range of number/date formats to
>>> be supported.
>>
>>> The goal would be to have something we could target for release in
>>> summer/fall, and get our release schedule back on track, as well as
>>> providing a basic springboard for further development into the
>>> financial logic of the software.
>>
>> As I have expressed in earlier conversations (possibly private only?)
>> I  think that's a great idea: having a dependable release cycle where
>> the functionalities which are done get released to the public. That
>> way, the part of the community which benefits from those changes
>> doesn't have to wait for some huge project to complete.
>>
>> My idea for approaching the financial logic refactoring would be to
>> determine in the assessment which bits can be done on trunk as part of
>> any release. That'll help paving the way for 'the big change'. When
>> we're done refactoring the smaller bits, we move the main refactoring
>> to a branch where we work on it at our own pace. There, the work isn't
>> blocking releases of other functionality or fixes. Working on a branch
>> until we're ready to integrate means we won't be forced to have
>> another 4-year release cycle.
>>
>>> If I have time I would be open to putting some time towards an appointment
>>> module, I would like to do that but at this point, there are no guarantees.
>>> What do people think?
>>
>> Well, if you get funding for the appointment module, I'm the last one
>> to tell you to earn money :-) However, if I look at the current
>> structure of the application, I'm not sure where it fits in. I mean,
>> other CRM software integrates with e-mail clients and agendas these
>> days. Is an appointment module good enough?
>
> It's good enough for some use cases.  Those use cases can bring
> additional projects later.
>
>
> Also want to integrate the work I have been doing on payroll.
>
> best Wishes,
> Chris Travers
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel