On 1 December 2016 at 09:35, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
> On 30.11.2016 21:23, Emil Velikov wrote:
>> Hi all,
>> With holidays not far off, it might be a nice idea to consider the
>> branchpoint/release schedule for the next release.
> +1 on the 17.0 question.
I'd prefer to keep different things separate - scheme vs schedule ;-)
Will check with the versioning scheme thread in a day or so. Might
poke some distro maintainers for to collect some feedback (mostly
checking for objections).
>> I will be having limited internet access during 20 Dec - 7 Jan, thus
>> the I'm leaning towards following:
>> Jan 13 2017 - Feature freeze/Release candidate 1
>> Jan 20 2017 - Release candidate 2
>> Jan 27 2017 - Release candidate 3
>> Feb 03 2017 - Release candidate 4/final release
>> How does this align with people's schedules ?
>> Please let me know if you have any work we want to land before the
>> next branchpoint.
> I was hoping to get GLCTS failures for radeonsi down to 0. We're currently
> at 18 (including patches not on master and some pending LLVM changes). For
> some of the failures this may need spec clarification feedback, which tends
> to be not the fastest process in the world (e.g. I'm thinking of the
> program_interface_query stuff). Apart from those, which are a big unknown,
> the schedule is probably doable.
Ack. If there is any noticeable work needed please try to land this
before the branchpoint. This way one can toggle between codepath A and
B during the RCs ;-)
mesa-dev mailing list