Please dont stick unstable, untested, or unsure code in master and ifdef
it. This is specifically what branches are for. They allow all of that
without clouding up master with a bunch of junk. I would argue that for
most of the people that you will want to test your new unstable code we
would pre
Branch development is how sane collaborative software engineering is done
when using git. Previously we, as a project, have not made effective use of
them, but we must end the practice of merging features into master "for
testing".
Testing is not what the master branch is for.
Writing effective t
This is a good point to raise, and I could probably have done a better job
explaining in order to avoid confusion.
The idea here is that during weeks 1+2, people could either begin work on a
feature (the progress of which could then be used as evidence that the
feature is feasible for this release
On Fri, 13 Jul 2018 08:16:11 +0200 Marcel Hollerbach said:
>
>
> On 07/13/2018 07:20 AM, Carsten Haitzler (The Rasterman) wrote:
> > On Thu, 12 Jul 2018 20:14:47 +0200 Marcel Hollerbach said:
> >
> >> Hello,
> >>
> >> As Mike & Stefan pointed out in the ML thread "Community Scheduling",
> >>
On 07/13/2018 07:20 AM, Carsten Haitzler (The Rasterman) wrote:
On Thu, 12 Jul 2018 20:14:47 +0200 Marcel Hollerbach said:
Hello,
As Mike & Stefan pointed out in the ML thread "Community Scheduling",
doing EFL releases is quite a pain from time to time, we have a constant
"last minute" dis
On Thu, 12 Jul 2018 20:14:47 +0200 Marcel Hollerbach said:
> Hello,
>
> As Mike & Stefan pointed out in the ML thread "Community Scheduling",
> doing EFL releases is quite a pain from time to time, we have a constant
> "last minute" discussion about what is going to be merged, and what is
> n
Hello,
Mhmm in week 1&2 no real work can be done, as the merging could be
canceled due to 2, feels like progress is on hold there a bit. I would
prefer to just "do" development there, and cleanup unfinished TODOs in 5.
Otherwise this looks good to me.
On 07/12/2018 09:02 PM, Mike Blumenkrant
I think this is a good approach for managing releases going forward. If we
have a clear idea of what large features will be added to each release
around the onset of the development window then we can more easily work
towards those goals over a given time period. I propose the following
step-by-ste
Hello,
As Mike & Stefan pointed out in the ML thread "Community Scheduling",
doing EFL releases is quite a pain from time to time, we have a constant
"last minute" discussion about what is going to be merged, and what is
not. I feel like this is stretching nerves of everyone.
However, the fr
