>
>
> >> I already mentioned above, but this can cause misunderstanding. We want
> all
> >> driver implementation to be ready for proposal deadline, same as other
> patches.
> >> But because of its reduced scope (they don't affect all project but only
> >> specific vendor), we are flexible to get driver features for -rc2 and
> -rc3 too.
> >
> > -rc3 really? It should be exceptional so not mentioned here.
>
Agree. Let's keep it to -rc2.


> >
>
> In practice we are having it, but agree to have it exceptional and not
> mention
> in the guide.
>
> >> Please check number of driver patches merged for a release, it is
> impossible to
> >> manage them within period between -rc1 & -rc2.
> >> Also some driver features are complex and big, they should be sent
> before
> >> proposal deadline so that they can be reviewed for the release.
> >
> > Yes sooner is better. The doc is about deadline + priorities,
> > showing the no-go limits, without warranty of merge if all good.
> > Is there a contradiction?
> >
>
> My concern is document can be read as, it is normal/expected to send driver
> patches after -rc1, because this documents as -rc2 task is driver patches.
>
> I am OK with it if it is clear that deadline is -rc2, but normal/expected
> is to
> have driver patches also before proposal deadline.
>
+1


>
>
>
>