On Tue, Mar 17, 2009 at 11:32:46AM -0400, Eric S. Raymond wrote: > Nils Kneuper <crazy-ivano...@gmx.net>: > > Personally I think we are basically in a good shape for a release right now > > already. If the AI testsuite finds some bigger problems, they will have to > > be > > fixed in later 1.6.x releases anyway. > > Wouldn't that be contrary to policy for the 1.6 line, though? The AI is > the *last* thing we really want to mess with in a stable release.
Choosing between fixing it now and do the final release in a week or fix it in 1.6 and trunk and have it a while tested in both I prefer the latter. (I see it as picking the lesser evil.) I also think this is a symptom of a bigger problem, the development versions are not tested enough, which causes problems to pop up very late in the development cycle (same for 1.4). So maybe we should look at how to give the next development releases a better testing earlier in the cycle. Preferably I'd like to see more user testing starting in the middle of the cycle so we still have time to do more intrusive changes. > > A more problematic thing is that the orgs that participate in summer of code > > will be announced on Wednesday evening. If we are accepted there (which I > > think > > we will be), we will have some students submitting patches. Those will most > > likely be some small new features which could not be committed right away > > because of the 1.6 preparations. > > An issue, yes -- but let's try holding for a week or until the first patches > arrive, then, whichever is sooner. You should check with fendrin, but > I think we're in a place where a day or two could make a significant > difference > in our confidence level about the AI. Assuming we get into gsoc; the patches don't need to be applied directly in fact I assume most patches need a few review + cleanup/fix cycles before we can commit them. So I don't think Wednesday should be a hard date if there are good reasons to delay it a few days, however I'd like to have the announcement as planned on Sunday. I only have one bug [1] left which should be fixed before tagging, I expect to do that this evening. I've an ugly fix that needs some polishing and some more testing, but I'm quite sure I'll be ready this evening. Would it be an idea to fork 1.6 about a day after tagging so commits which are needed in both trunk and 1.6 can be applied to both without merging? [1] https://gna.org/bugs/index.php?13203 -- Regards, Mark de Wever aka Mordante/SkeletonCrew _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev