Christian Stimming <[EMAIL PROTECTED]> writes:
> I see that http://wiki.gnucash.org/wiki/Development_Process has been started
> to collect the final agreement.
Yeah. Chris and I worked out our differences in irc. Basically, he
thought that I wanted the release branch to only contain already-t
Am Donnerstag, 13. Juli 2006 01:33 schrieb Derek Atkins:
> > Instead, if the fixes are made on /branches/2.0, then the branch can
> > be repeatedly pulled into trunk. Essentially, /trunk is constantly
> > being rebased off the tip of /branches/2.0. This won't suffer any
> > divergence, because al
On Thu, Jul 13, 2006 at 11:40:55AM +1000, Conrad Canterford wrote:
> On Wed, 2006-07-12 at 20:26 -0400, Chris Shoemaker wrote:
> > On Wed, Jul 12, 2006 at 07:33:55PM -0400, Derek Atkins wrote:
> > > Then how do we get a proposed change audited before it's commited to
> > > the 2.0 branch?
>
> Woul
On Wed, 2006-07-12 at 20:26 -0400, Chris Shoemaker wrote:
> On Wed, Jul 12, 2006 at 07:33:55PM -0400, Derek Atkins wrote:
> > Then how do we get a proposed change audited before it's commited to
> > the 2.0 branch?
Would a 2.0-testing branch solve this issue? We keep a pristine, tested
and approve
On Wed, Jul 12, 2006 at 07:33:55PM -0400, Derek Atkins wrote:
> Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
> >I don't see any need to "backport" changesets at all.
>
> Then how do we get a proposed change audited before it's commited to
> the 2.0 branch?
FTR, my counter-proposal is:
We commit
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
> I think we can just agree that /trunk is for development and
> /branches/2.0 is for bugfixes only.
Yes, but an attempted bugfix IS development. How are you supposed to
get it tested /before/ it gets into the branch if you don't commit it
somewhere?
On Wed, Jul 12, 2006 at 02:54:04PM -0400, Derek Atkins wrote:
> Hi,
>
> I'd like to propose a change process for making changes to the 2.0
> release branch. The goal of this proposal is to limit the number of
> potential bugs that enter the 2.0 branch due to changes made to the
> sources. Consid
Quoting Josh Sled <[EMAIL PROTECTED]>:
> On Wed, 2006-07-12 at 14:54 -0400, Derek Atkins wrote:
>> 2) Any other changes must first be committed to trunk and then
>>vetted/audited by at least one other developer before the changeset
>>is "allowed" to be merged into branches/2.0. In other w
On Wed, 2006-07-12 at 14:54 -0400, Derek Atkins wrote:
> 2) Any other changes must first be committed to trunk and then
>vetted/audited by at least one other developer before the changeset
>is "allowed" to be merged into branches/2.0. In other words,
>developers should not commit code
Hi,
I'd like to propose a change process for making changes to the 2.0
release branch. The goal of this proposal is to limit the number of
potential bugs that enter the 2.0 branch due to changes made to the
sources. Considering we're going to try to get a 2.1 series in the
fall and 2.2 by the en
10 matches
Mail list logo
