On Tue, Oct 4, 2011 at 02:19, Lex Trotman ele...@gmail.com wrote:
[...]
Even in the case of single-commit features? I completely agree with
more-than-one-commit features because otherwise you don't know where
the feature implementation starts and ends but having it for minor
one-commit
On 3 October 2011 15:37, Matthew Brush mbr...@codebrainz.ca wrote:
Hi Lex,
Agree with everything you said except I would put #5 and #6 early in the
list since the rest of the things will probably make all the patches need a
lot of work, while they could probably be quite easily applied
On Mon, 3 Oct 2011 15:15:09 +1100
Lex Trotman ele...@gmail.com wrote:
Hi All,
Now we have 0.21 released I thought it was worthwhile looking at the
path ahead, and since we have the possibility of some quite
significant changes, maybe starting a plan of attack so that not too
much effort is
[...]
In general I'm fine with this list as goals (discussing details would
be the wrong place here), but would call it 0.9x with this changes on
next release as changes are to big to become a 1.0 directly (to keep
understanding of a 1.0 which have been posted on this list bevor)
Hi Frank,
On 3 October 2011 20:34, Frank Lanitz fr...@frank.uvena.de wrote:
On Mon, 3 Oct 2011 20:04:28 +1100
Lex Trotman ele...@gmail.com wrote:
[...]
In general I'm fine with this list as goals (discussing details
would be the wrong place here), but would call it 0.9x with this
changes on next
On Mon, 3 Oct 2011 21:05:45 +1100, Lex wrote:
Heyho,
Big new changes are actually better to go in a new version series.
I'm guessing from your proposal of 0.9 that you want to follow the GTK
method, odd point releases are unstable and even ones stable.
But I don't think that fits with Geany
On 11-10-03 02:34 AM, Frank Lanitz wrote:
I think the changes you listed, which all make sense taking the general
opinion of mailing list, but they are IMHO to big to put all in one
release and make it stable within the same one.
FWIW, a lot of the stuff in the list is already sitting around
Le 03/10/2011 06:15, Lex Trotman a écrit :
Hi All,
Now we have 0.21 released I thought it was worthwhile looking at the
path ahead, and since we have the possibility of some quite
significant changes, maybe starting a plan of attack so that not too
much effort is wasted.
The big things I
Le 03/10/2011 18:20, Jiří Techet a écrit :
On Mon, Oct 3, 2011 at 17:29, Colomban Wendling
lists@herbesfolles.org wrote:
Le 03/10/2011 06:15, Lex Trotman a écrit :
[...]
Agreed with the strong branching scheme,
http://nvie.com/posts/a-successful-git-branching-model/ feels good to me.
On Mon, 3 Oct 2011 18:20:35 +0200
Jiří Techet tec...@gmail.com wrote:
1. The split between master and develop is completely unnecessary. I
don't see a reason why there should be a separate branch for releases
(i.e. commits with tags). The post says that a merge to master is a
release by
On Mon, 3 Oct 2011 19:16:09 +0200
Jiří Techet tec...@gmail.com wrote:
2. I agree with non-fast-forward merges of feature branches. These
branches however have to be real feature branches where work
concentrates on implementing a single feature (e.g. GTK 3 support).
For instance I have a
On Mon, Oct 3, 2011 at 19:00, Frank Lanitz fr...@frank.uvena.de wrote:
On Mon, 3 Oct 2011 18:20:35 +0200
Jiří Techet tec...@gmail.com wrote:
1. The split between master and develop is completely unnecessary. I
don't see a reason why there should be a separate branch for releases
(i.e.
On Mon, 03 Oct 2011 19:27:16 +0200
Colomban Wendling lists@herbesfolles.org wrote:
Le 03/10/2011 19:20, Frank Lanitz a écrit :
On Mon, 3 Oct 2011 19:16:09 +0200
Jiří Techet tec...@gmail.com wrote:
2. I agree with non-fast-forward merges of feature branches.
These branches
On Mon, 3 Oct 2011 19:24:40 +0200
Jiří Techet tec...@gmail.com wrote:
On Mon, Oct 3, 2011 at 19:00, Frank Lanitz fr...@frank.uvena.de
wrote:
On Mon, 3 Oct 2011 18:20:35 +0200
Jiří Techet tec...@gmail.com wrote:
1. The split between master and develop is completely unnecessary.
I don't
[...]
Yep -- though I think I'm missing something ti your sentence... I don't
get the meaning of and possible changes to process that forces/enables
Apologies for the inelegant language. You said it yourself below :), I
meant things like using branches and committing to develop not master
etc.
[...]
Even in the case of single-commit features? I completely agree with
more-than-one-commit features because otherwise you don't know where
the feature implementation starts and ends but having it for minor
one-commit features seems like overkill to me.
Lets just use commonsense and
Hi All,
Now we have 0.21 released I thought it was worthwhile looking at the
path ahead, and since we have the possibility of some quite
significant changes, maybe starting a plan of attack so that not too
much effort is wasted.
The big things I see right now that have had some work are:
1.
Hi Lex,
Agree with everything you said except I would put #5 and #6 early in the
list since the rest of the things will probably make all the patches
need a lot of work, while they could probably be quite easily applied
presently. I could be wrong though, just a thought.
Cheers,
Matthew
18 matches
Mail list logo
