> I agree - there's also the possibility that there will be additional > patches needed to fix a bug in code that's just not relevant for 2.2 > (this is less likely), or an alternate fix might be needed that's > not as thorough as one in 2.2 (where there's a large fix, a smaller > workaround might be more appropriate for 2.1.2) Then I come back to my original question: What is your schedule for 2.1.2 then? I don't mind if it is either very tight or very lose, but I think there should be a schedule (which can be adjusted as needed). I think the following milestones should appear: - deadline for contributing new patches - deadline for selecting and integrating CVS mainline patches - release of a release candidate - release IMO, it isn't important that *all* patches that are desirable for 2.1.2 really get integrated by the second deadline. Instead, what gets done is done, everything else is for 2.1.3 (if there is interest in such a release). E.g. I wouldn't delay the release indefinitely just because somebody promised to indicate all, say, pyexpat patches, and never did. Regards, Martin P.S. Although I certainly do promise to indicate all pyexpat patches that should go into 2.1.2 :-)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4