Commits

Georg Brandl  committed 0ccddf2

Add "open issues" section, move all XXX there, add suggestion about PEP3003-like restrictions for non-LTS.

  • Participants
  • Parent commits cfc6c9b

Comments (0)

Files changed (1)

 Normal feature versions would get either zero or at most one bugfix
 release; the latter only if needed to fix critical issues.
 
-.. XXX I think we have to discuss this: it depends on the chosen cycle
-   duration (I'd rather have X = 8 and N = 3, and for that it makes
-   sense to have bugfix releases IMO.)
-
 LTS versions would get regular bugfix releases until the next LTS
 version is out.  They then would go into security fixes mode, up to a
 termination date at the security release manager's discretion.
 The number of release candidates depends, as usual, on the number of
 last-minute fixes before final release.
 
-.. XXX I put in "two alphas"; IMO one alpha is not enough given our
-   tendency to shove in things during the alpha period -- also, Nick's
-   comments about early alphas apply
-
 
 Effects
 =======
 The same number of branches would be simultaneously open for regular
 maintenance (two until 2.x is terminated, then one).
 
-.. XXX that is true in your original proposal, but see above
-
 Effect on workflow
 ------------------
 
 period makes it less cumbersome to interact with contributors of
 features.
 
-.. XXX section "effect on distributions" is missing; but probably that
-   can come with the python-dev discussion where the responsibles for
-   the different distros can weigh in
-
 
 Discussion
 ==========
 
+These are open issues that should be worked out during discussion:
+
+* Decide on X (months between feature releases) and N (feature releases
+  per LTS release) as defined above.
+
+* For given values of X and N, is the no-bugfix-releases policy for
+  non-LTS versions feasible?
+
+* Restrict new syntax and similar changes (i.e. everything that was
+  prohibited by PEP 3003) to LTS versions?
+
+* What is the effect on packagers such as Linux distributions?
+
 A community poll or survey to collect opinions from the greater Python
 community would be valuable before making a final decision.