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 <damien.regad@merckgroup.com> 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

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.


This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
mantisbt-dev mailing list