26.04.2011 22:10, Christian Ohm wrote:
I'd like to see a move towards a process that doesn't result in countless
started things that need to be finished before we can even begin to think
about
a release.
But isn't this one of the inherent problems of FLOSS development?
Regards
- Kreuvf
On Wednesday, 27 April 2011 at 9:53, Kreuvf wrote:
26.04.2011 22:10, Christian Ohm wrote:
I'd like to see a move towards a process that doesn't result in countless
started things that need to be finished before we can even begin to think
about
a release.
But isn't this one of the
On 2011-04-24 12:43, Christian Ohm wrote:
0. New features are developed in feature branches. Bugfixes to a specific
feature go into the feature branch as well, even after it got merged.
(Generally, merges go only in one direction, no back-merges from master into
other branches.)
1. Merge
On Wednesday, 27 April 2011 at 20:54, Fastdeath wrote:
What I do not quite understand:
(Generally, merges go only in one direction,
no back-merges from master into other branches.)
that means we are not allowed to back merge branch unrelated bugfixes?
That means that you don't
On Sunday, 24 April 2011 at 21:28, Daniel Kliman wrote:
It sounds like the development model described in
http://nvie.com/posts/a-successful-git-branching-model/
Mostly it is influenced by the Linux kernel development process (arguably the
group of users most familiar with git).
Is that what
On Sunday, 24 April 2011 at 18:55, Per Inge Mathisen wrote:
On Sun, Apr 24, 2011 at 12:43 PM, Christian Ohm chr@gmx.net wrote:
I've wondered if the concept of stable release is actually useful for us.
It is useful for users.
Hm, that was supposed to read stable release branch. We bare can
On Apr 26, 2011, at 4:10 PM, Christian Ohm wrote:
On Sunday, 24 April 2011 at 21:28, dak180 wrote:
It sounds like the development model described in
http://nvie.com/posts/a-successful-git-branching-model/
Mostly it is influenced by the Linux kernel development process (arguably the
group
On Tuesday, 26 April 2011 at 16:31, dak180 wrote:
I have yet to see a clear illustration of how the kernel development is
managed can you point to what you would consider to be the best such?
http://en.wikipedia.org/wiki/Linux_kernel#Development_model for a summary,
On Tue, Apr 26, 2011 at 10:24 PM, Christian Ohm chr@gmx.net wrote:
I think the feature branches model is our best bet to achieve that. master
won't ever have unfinished stuff delaying a release, and features can be
developed in a branch as fast or slow as wanted without delaying a release.
On Tuesday, 26 April 2011 at 23:05, Per Inge Mathisen wrote:
I still remember lua branch, qt branch, netsync branch, and terrain
branch that festered like bad wounds while we struggled with lack of
testing and little idea what to do with them until they were merged
more or less untested (less
On Sun, Apr 24, 2011 at 10:04 AM, Per Inge Mathisen
per.mathi...@gmail.com wrote:
* We merge Qt branch into master immediately.
The commit message may not have looked like much, but the merge has
now been done.
- Per
___
Warzone-dev mailing list
The attempt to do a partial merging of Qt branch into master ran into
some problems that required major surgery of master in order to work.
The question was posed if we should be spending so much time fixing up
master, when we could just be focusing our efforts on making the Qt
branch work
24.04.2011 10:04, Per Inge Mathisen wrote:
* The new map renderer should use shaders, but not require as much
hardware as the current. Consider this statement ironical? Only if you
have made a habit out of thinking that poor drivers mean weak
hardware. But lots of recent weak/cheap hardware
On Sunday, 24 April 2011 at 10:04, Per Inge Mathisen wrote:
This will have some consequences, like not being able to aim for a
stable release from master in a while,
I've wondered if the concept of stable release is actually useful for us.
Looking at 2.3, it seems to languish mostly, while
On 24/04/11 08:04 AM, Per Inge Mathisen wrote:
* We need a way for users to convert old maps to the new format. I
will write a command-line app to do it, and Fastdeath has offered to
set up a php service for it, using that app.
* Once a new map format is ready, we can start experimenting
On Sun, Apr 24, 2011 at 2:13 PM, Safety0ff safety0ff@gmail.com wrote:
Last time I checked, for Qt widgets to work properly on all platforms
with Opengl we need to use a qgraphicsview and a qglwidget subclass, and
set the glwidget as the background for the graphics view (like this:
On Sun, Apr 24, 2011 at 12:43 PM, Christian Ohm chr@gmx.net wrote:
I've wondered if the concept of stable release is actually useful for us.
It is useful for users.
We should definitely aim for quicker releases later on. Not really
sure how to do this. I think this is mostly dictated by
On 4/24/11, Kreuvf kre...@warzone2100.de wrote:
One thing is missing: a map editor. A new map format is of little value
without
an appropriate map editor or in other words: people need to be able to
switch to
the new format.
The only map editor that we have anyone maintaining is flaME.
So we
On Apr 24, 2011, at 3:19 PM, buginator wrote:
One thing is missing: a map editor. A new map format is of little value
without
an appropriate map editor or in other words: people need to be able to
switch to
the new format.
The only map editor that we have anyone maintaining is flaME.
On 4/24/11, Christian Ohm chr@gmx.net wrote:
On Sunday, 24 April 2011 at 10:04, Per Inge Mathisen wrote:
This will have some consequences, like not being able to aim for a
stable release from master in a while,
I've wondered if the concept of stable release is actually useful for us.
On 24/04/11 07:34 PM, dak180 wrote:
While it might be the only one currently maintained there is also:
https://github.com/dak180/WZME
If someone wants to resurrect it.
Unless you just want the UI layout, I wouldn't waste my time on it.
___
On Apr 24, 2011, at 6:43 AM, Christian Ohm wrote:
I've wondered if the concept of stable release is actually useful for us.
Looking at 2.3, it seems to languish mostly, while people work on new stuff.
So, proposal for a more git-like workflow:
-1. Get master into a reasonably stable
On Apr 24, 2011, at 3:40 PM, buginator wrote:
* We merge Qt branch into master immediately.
No objections from me.
Right, that is mostly what we do, or have done in the past, is it not ?
The issue(s) are that we have no good way to test things, and things
slip through the cracks.
On Apr 24, 2011, at 6:43 AM, Christian Ohm wrote:
I've wondered if the concept of stable release is actually useful for us.
Looking at 2.3, it seems to languish mostly, while people work on new stuff.
So, proposal for a more git-like workflow:
-1. Get master into a reasonably stable
24 matches
Mail list logo