Chris Travers | 2 Jan 02:55 2008
Picon

Proposal-- regular scheduling of bugfix releases

Hi all;

I have been reviewing the problematic vs less problematic releases in the past and have noticed an interesting pattern:

Releases tend to be problematic when a) they follow a long period of no releases or b) they require extensive testing to validate all features.

Obviously major releases are always going to fall under the extensive testing category and may contain new bugs (hence good beta test programs and participation in that process by a broad base of users is important).  However, one important question is how we can avoid the main traps that seem to let bugs slip into released versions  To date we have automated a lot of the cleanup which has caused packaging errors in the past.

My proposed solution is that we begin validation of bugfix releases within 2 weeks of the previous release (I am thinking the second monday after the last release).  In urgent cases, we can move that schedule up, but we should avoid moving it back.  If the number of bugfixes are small and the software is easily testable,  validation should take no more than 48 hours.

I also think that going forward, we should probably upload all validation tarballs to Sourceforge and use that as a distribution method for the validation.  Validation emails would be sent to this list so that more people could weigh in on problems that they see, concerns, and whether there is the need for more testing.  If there is, then that same sourceforge distribution can be used as a public beta.

Does this sound like a good idea?  Any other feedback or ideas?

Best Wishes,
Chris Travers

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Carl Davis | 2 Jan 14:13 2008
Picon

Non real-time synchronization

I want to synchronize (either once a day or once a month) Ledger-smb
and Billmax, which is the software I use for recurring charges within my
Wireless ISP business. I want to pull charges, payments, and credits
from Billmax into Ledger-smb according to my customers Billmax account
number. I was hoping someone could give me a head start and indicate
which table and column I would need to import the following data to:

for charge - amount and description
for payment - amount and description
for credit - amount and description

When I create customers in Ledger-smb can I use the Billmax account
number as the Ledger-smb account number? Billmax starts out at account
number 1000 and goes up from there.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Chris Travers | 2 Jan 19:57 2008
Picon

Re: Non real-time synchronization



On Jan 2, 2008 5:13 AM, Carl Davis <lists-AGFSE7XDgc30qnVlFUAYEw@public.gmane.org> wrote:
I want to synchronize (either once a day or once a month) Ledger-smb
and Billmax, which is the software I use for recurring charges within my
Wireless ISP business. I want to pull charges, payments, and credits
from Billmax into Ledger-smb according to my customers Billmax account
number. I was hoping someone could give me a head start and indicate
which table and column I would need to import the following data to:

for charge - amount and description
for payment - amount and description
for credit - amount and description

When I create customers in Ledger-smb can I use the Billmax account
number as the Ledger-smb account number?

Yes.

It seems to me that we would need to get more information about Billmax and how the data is stored in that program before we could offer any concrete suggestions.  How do you want this to work?

Best Wishes,
Chris Travers

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Jeff Kowalczyk | 2 Jan 21:48 2008
Picon

Re: Proposal-- regular scheduling of bugfix releases

Chris Travers wrote:
> If the number of bugfixes are small and the software is easily testable,
>  validation should take no more than 48 hours.

What does LedgerSMB release validation entail? I've always been curious
about that.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Chris Travers | 2 Jan 21:52 2008
Picon

Re: Proposal-- regular scheduling of bugfix releases



On Jan 2, 2008 12:48 PM, Jeff Kowalczyk <jtk-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
Chris Travers wrote:
> If the number of bugfixes are small and the software is easily testable,
>  validation should take no more than 48 hours.

What does LedgerSMB release validation entail? I've always been curious
about that.

We basically package the release and submit it for review.  In the past this has been largely been done by the core team but this was originally at least in part due to the fact that we were doing a *lot* more in the way of security releases in our early days.  There is an argument that this should be a more transparent process and I generally agree with that.

In the past this has meant that we email the release out to everyone else.  Under my proposal, it would be uploaded to a different package on Sourceforge.  We should probably append the letter 'v' for a validation upload.

Best Wishes,
Chris Travers



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Jeff Kowalczyk | 2 Jan 22:15 2008
Picon

Re: Proposal-- regular scheduling of bugfix releases

Chris Travers wrote:
> We basically package the release and submit it for review.  In the past
> this has been largely been done by the core team but this was originally
> at least in part due to the fact that we were doing a *lot* more in the
> way of security releases in our early days.  There is an argument that
> this should be a more transparent process and I generally agree with
> that.

My question was more along the lines of what the validators did with the
proposed tarball. Is validation an informal loading of real world datasets
and seeing if there are any observable defects?

> In the past this has meant that we email the release out to everyone
> else. Under my proposal, it would be uploaded to a different package on
> Sourceforge.  We should probably append the letter 'v' for a validation
> upload.

Can a proposed release simply be an svn tag URL, with validators
independently svn export'ing an tar/zipping?

Or, commit the proposed archives to the repository in a
ledgersmb/releases/ svn URL.

Send email to the validators to export and test the tag and/or release
URL, and if there are no problems reported, upload the archives to
sourceforge. If there's a problem and you don't want to increment the
version, the tag can be deleted and the branch tagged again with the name
later.

Doing it within the repository preserves the history of the validation
process.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Chris Travers | 2 Jan 22:20 2008
Picon

Re: Proposal-- regular scheduling of bugfix releases



On Jan 2, 2008 1:15 PM, Jeff Kowalczyk <jtk-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
Chris Travers wrote:
> We basically package the release and submit it for review.  In the past
> this has been largely been done by the core team but this was originally
> at least in part due to the fact that we were doing a *lot* more in the
> way of security releases in our early days.  There is an argument that
> this should be a more transparent process and I generally agree with
> that.

My question was more along the lines of what the validators did with the
proposed tarball. Is validation an informal loading of real world datasets
and seeing if there are any observable defects?

1)  Looking for obvious packaging errors (this was a big one).
2)  Reviewing changes to see if there were obvious problems introduced.   This works better when the number of bug fixes is small. :-)


> In the past this has meant that we email the release out to everyone
> else. Under my proposal, it would be uploaded to a different package on
> Sourceforge.  We should probably append the letter 'v' for a validation
> upload.

Can a proposed release simply be an svn tag URL, with validators
independently svn export'ing an tar/zipping?

That doesn't give us an ability to look for packaging errors.   Hopefully once we get to 1.3 (and the use of svn export), that will be feasible, however.


Or, commit the proposed archives to the repository in a
ledgersmb/releases/ svn URL.

Send email to the validators to export and test the tag and/or release
URL, and if there are no problems reported, upload the archives to
sourceforge. If there's a problem and you don't want to increment the
version, the tag can be deleted and the branch tagged again with the name
later.

Doing it within the repository preserves the history of the validation
process.

Agreed.  I think when we get to 1.3, I think we will want to do that :-)

Best Wishes,
Chris Travers

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Seneca Cunningham | 2 Jan 22:33 2008
Picon

Re: Proposal-- regular scheduling of bugfix releases

On Wed, Jan 02, 2008 at 12:52:37PM -0800, Chris Travers wrote:
> In the past this has meant that we email the release out to everyone else.
> Under my proposal, it would be uploaded to a different package on
> Sourceforge.  We should probably append the letter 'v' for a validation
> upload.

On that note, I propose that for validation tarballs we use the scheme
that I used on my validation tarball: "X.Y.Z-vN".  This accounts for the
fact that we have used multiple validation tarballs in the past and that
we don't want validation releases confused with final releases.

--

-- 
Seneca
tentra@...

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Carl Davis | 3 Jan 13:22 2008
Picon

Re: Non real-time synchronization

On Wed, 2 Jan 2008 10:57:33 -0800
"Chris Travers" <chris.travers@...> wrote:

> 
> Yes.
> 
> It seems to me that we would need to get more information about Billmax and
> how the data is stored in that program before we could offer any concrete
> suggestions.  How do you want this to work?

Billmax stores everything in a mysql database. I have already exported
a csv file of my current customers from billmax and imported into
ledger-smb using mypgadmin. I imported the Billmax customer number into
the customer number field of ledger-smb

Billmax uses a payhist table which has all credits, payments, and
charges to accounts (it has other info there but we don't use it or I
can do manually). Up until the last day of the month one can edit the
items in the payhist table, after that they are not to be edited, so
I suspect that my best course of action is to export last months Billmax
data on the first of every month.

I guess my question at this point is (unless I am missing something?)
when I export three columns into three respective csv files:

for charges - amount, account number and description
for payments - amount, account number and description
for credits - amount, account number and description

how and where do I import that into ledger-smb linking the billmax
account number to the ledger customernumber? 

I hope I am not missing anything and happy to provide more details.

--
Carl 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Chris Travers | 3 Jan 18:41 2008
Picon

Re: Non real-time synchronization



On Jan 3, 2008 4:22 AM, Carl Davis <lists-AGFSE7XDgc30qnVlFUAYEw@public.gmane.org> wrote:
On Wed, 2 Jan 2008 10:57:33 -0800
"Chris Travers" <chris.travers-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

>
> Yes.
>
> It seems to me that we would need to get more information about Billmax and
> how the data is stored in that program before we could offer any concrete
> suggestions.  How do you want this to work?

Billmax stores everything in a mysql database. I have already exported
a csv file of my current customers from billmax and imported into
ledger-smb using mypgadmin. I imported the Billmax customer number into
the customer number field of ledger-smb

Ok.  That works.

Just as a quick note, once 1.3 comes out, the customer import will need to be done a little differently.


Billmax uses a payhist table which has all credits, payments, and
charges to accounts (it has other info there but we don't use it or I
can do manually). Up until the last day of the month one can edit the
items in the payhist table, after that they are not to be edited, so
I suspect that my best course of action is to export last months Billmax
data on the first of every month.

I guess my question at this point is (unless I am missing something?)
when I export three columns into three respective csv files:

for charges - amount, account number and description
for payments - amount, account number and description
for credits - amount, account number and description


how and where do I import that into ledger-smb linking the billmax
account number to the ledger customernumber?


Ok.  Here are the tables you are going to have to hit:

ar:  This represents the transaction where the customer is charged.  customer_id links to customer.id in 1.2.x.
acc_trans:  this represents the line items in the accounting transaction.  You will need 2 entries here for a charge, and another 2 for a payment.  chart_id links to chart.id, trans_id links (in this case) to ar.id.  Do you need help determining these records and what accounts they need to hit?

Best Wishes,
Chris Travers

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Gmane