[Neos] [Team] Neos 1.2 / Flow 2.3 Feature Freeze

[Rens Admiraal]

A bit off topic:
I would just love to have the feeling we get stuff done in a positive 
way without trying to chew all the changes till we're sure the change 
will be in the review queue forever ;-)

on topic: see inline

Aske Ertmann schreef op 12/08/14 14:32:
> Hi Robert & Sebastian,
>
> Thanks for your replies. I’ll respond to Roberts comments, since it pretty much goes along with Sebastians comments.
>
>> To me it's important that we don't fix / announce release dates, but we do announce feature freeze dates (to developers). This is a big difference. You may or may not tag a first beta on the day of feature freeze, so if you don't feel comfortable releasing the beta 1 then really, feel free to schedule it so that everything is good enough for a beta.
> I fully agree.
+1 to postponing beta till we feel good about it
>
>> My point is that we must, at some point, stop producing new features for a specific release. Considering your email, I propose that you, as the release manager, create a list of features which have not been merged yet and must go into 1.2. Based on that list let's have a quick vote here to see if the team generally agrees. And then we must not add more features.
> Again fully agree to stop producing new features, that’s in no case what I’m trying to achieve with moving the feature freeze. Creating that list is definitely also what I plan on doing in any case, thinking it makes sense to do it in Jira.
+1 to a fix the list of features @ feature freeze
>
>> I really suggest to not move the feature freeze date, but rather create the list mentioned above. You can decide on a per-case basis if an additional feature is necessary to complete the major features we created, but let's not open completely new cans at this stage.
> For me this is just a subtle difference. As it seems we agree to allow certain features to be merged after the feature freeze date, but my suggestion was to move the feature freeze date to allow to groom the review queue which should happen before releasing in my opinion and not have it too strict. But if it’s preferred to keep it more strict we can also do that, although I don’t think there will be much difference in the end.
my 2 cents: probably writing all those emails will have taken the same 
time as reading over the review queue and mark the really important 
looking changes ;-) Reviewing them can still be done if they're on the list.
>
>> That's another topic - we really should have a fixed schedule for these and put that on auto-pilot. There's hardly any work involved with releasing a patch level version (and if so, let's fix that).
> It’s another topic, but a very related one. We only have a limited amount of reviewing resources available and currently that mostly the blocker for releasing the patch releases as I see it. So the more time we focus on the next release instead of existing releases, the less likely they are to be handled. I’m trying to do what’s best for the project in general, not just for this release.
>
>> we should branch out when we release beta 1 - that doesn't need to happen at the same time with a feature freeze.
> I thought a little more about this and came to the conclusion that if we keep the feature freeze date, then we should branch out today and start tagging for specifically for the releases (Neos/Flow). Otherwise some changes will be in limbo.
Probably a good point, although we might be able to wait with branching 
out and just be really picky about the releases footer
>
>> please allow me to be picky on this list. Having a feature freeze now does not exclude any of the points above. We can take all time we need to produce a stable release, a feature freeze does not imply a rushed beta phase or stable release.
> What I meant was related to the expectation of releasing within four weeks of the feature freeze date, which is just something I don’t see happening in reality unfortunately. But as long as that is not expected then sure.
>
>> The date was not really important to me, neither is sticking to principles. What I would like to achieve is that we are getting used to merging features or parts of features which are so stable that we could potentially release at any given time. And that needs practice. IMO, creating feature switches should be part of our development routine for bigger new features. It takes so much pressure out of the whole release cycle.
> I fully agree that is the goal we should be working towards, however that is not reality currently. As long as we still haven’t implemented the concept of feature switches I don’t think it makes sense to let that influence the release planning.
>
>
> So in general I’m indifferent for keeping the feature freeze date or not, in general I’d just like to make we finalize existing features already merged and include the existing features in the queue that are mainly lacking reviews.
>
> I’d be fine with creating the “list" today and branching out and announcing everything tonight.
>
> Since nobody else cared to voice their opinion yet, it looks like we’ll just stick with the date but it’s just extremely in strictly manner until the beta release which currently has a few blockers unfortunately.
>
> Cheers,
> Aske
>