From: Victor B. <vi...@fu...> - 2012-03-30 21:29:18
|
Hi Damien, Good points. 1. I expect each developer to do the necessary testing before checking in. 2. In case some bugs slip through, we can revert the change rather than hold off the release. 3. If a feature is done, but we find a corner / small issue (like what happens when upload of 1 of N files fails), maybe we can consider the issue done, and open a follow up bug to fix this specific case. 4. If a feature is almost done, then no need to rush it, knowing that there is another train to catch next month. Thoughts are welcome. On Fri, Mar 30, 2012 at 2:18 PM, Damien Regad <dam...@me...>wrote: > On 30.03.2012 18:13, Victor Boctor wrote: > > about a month since the release of 1.2.9 (released March 3rd), which is > > the rhythm I would like us to have going forward. > > I think that's a great idea, I've always been supporting the idea of > (even loosely) time-bound releases - even though in my opinion a monthly > cycle could be too ambitious as it would sometimes make very small > releases in terms of contents, considering on the activity of the > developers. > > How did you envision testing ? Just unit tests by the developers > authoring commits, then cut the release and fix whatever breaks in next > release ? Or something a bit more formal ? > > > Let me know if there are any blockers. > > 3 things: > > First, the fix for #11706 introduced a regression for at least 3 people > including Robert. I think the feature should be improved by introducing > a threshold to drive who can set a released version as target. This is > tracked in #14111, but I have not started any work on that yet and that > can wait for a future release. > > In the meanwhile however, maybe I should revert commit 3af57d28. What do > you think ? > > > Second, Robert took over some work I had started on #5228 (multi-file > upload), committed by work but in my opinion it's not 100% ready to go > live as there are still some issues with error handling so I reopened > the bug. > > May not be blocking as the functionality works as it is, but the > behavior is not good when one or more files fail to upload, either when > reporting a new bug or attaching files to an existing one. If we move > forward with 1.2.10 now, then I think a new bug should be opened to > track the error handling, and #5228 resolved. > > > Finally, definitely not a blocking issue, but I also have a small > feature branch nearly ready, to resolve #4465. I was only waiting for > feedback from Paul on whether the new config option should be added to > config_is_private(), and since I got the answer from him on IRC earlier > tonight, I guess that's pretty much all set now. > > I can either merge it for 1.2.10, or do it later on for 1.2.11 - just > let me know. > > > Damien > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |