Re: [mantisbt-dev] Staging 1.3 for release

[Victor B. <vb...@gm...>]

@paul, I saw your message to the mailing list, but I'm thinking it is good
to discuss in a dedicated thread (this thread).  We have to weigh the
benefit of merging all existing patches in 1.3, vs. some in 1.3 and some in
2.0.

@atrol, I remember your preference. I'm mainly reacting to the fact that
just earlier this year, we had a goal of releasing 1.3 beta by end of
January (with several targets before then).  I think to get it out, we have
to have a bar of what can make it into 1.3.  We seem to be in a cycle of
adding stuff and then fixing bugs introduced by the added stuff, etc.  So
whether we branch or not, we need to have such bar (e.g. functional bug
fixes or bug fixes to blocking / security bugs, etc).

As for adding new features vs. fixing bugs.  We should start with the
person who added a feature handling its bugs.  That won't cover bugs that
requires investigation of the even the area causing the issue, but should
be a good starting point.

Given history I believe a timeline of 1.3 in October and 2.0 in January is
unrealistic (impossible).  I feel we really need to schedule some hard stop
in our timeline, otherwise, we will keep going for a very long time without
releases.

Given @atrol and @dregad's preference, I'm OK with not branching until the
first beta release is out (at least), but we need to agree on the bar.

- blocking bug fixes
- functional bug fixes
- security bugs

So for submitted pull requests, we are not going to just look into whether
the change is OK, but does it just cause churn and delay 1.3.  I would
suggest applying this policy to pull requests in flight and future ones.

Once @dregad gets the source control plugin working, then we can upgrade
our instance and move forward.


On Fri, Sep 19, 2014 at 7:48 AM, Damien Regad <dr...@ma...> wrote:

> Victor Boctor <vboctor@...> writes:
> > It has become a habit to discuss this topic every couple of month.
>
> Not sure if I should :-) or :-(...
>
> > At the moment, there is a lot of churn on master that can be classified
> > as good change, but not really needed for 1.3 to go out.
>
> Fully agreed.
>
> I'd also like to point out that we have several security issues pending a
> fix since May, but the assigned developer is currently focusing on
> seemingly
> more important activities at the moment :-P
>
> Furthermore, several of the recent changes are adding instability and even
> introduced regressions. As things stand, the current continuous stream of
> changes is only delaying a potential go-live.
>
> > I would like to suggest staging 1.3 as follows:
> >
> > - Branch for 1.3
>
> Roland's answer has pretty much covered my opinion on this already, and
> perfectly outlined the consequences of doing it.
>
> Therefore, and for the same reasons, I *strongly oppose early branching*.
>
> We MUST NOT branch before at least 1.3.0b1 is out (so we can reach some
> level of stability) and SHOULD NOT do it until 1.3.0.
>
> > - Upgrade our bug tracker to 1.3 branch.
>
> As mentioned by Roland, we need to ensure our plugins have no issues with
> that.
>
> Roland Becker <roland@...> writes:
> > Did someone test that all plugins running on mantisbt.org/bugs are
> > running fine
>
> I did actually. At the moment, the *source integration* does NOT work
> properly, effectively blocking a move to mantisbt.org for now. I have a
> local work-in-progress branch where I attempt to fix the issues but I'm not
> done yet.
>
> Furthermore, before we upgrade our tracker, I would like everyone in the
> team to actually spend some time to perform in-depth "pre-alpha" tests
> locally, including coverage of upgrade scenarios, and reporting results of
> the same.
>
> > - Put this branch in bug fix only mode.
>
> This is kind of out of the equation for now considering my position above,
> but +1 on principle.
>
> > That would give us the following benefits:
> >
> > - A better chance at stabilizing (based on blocking bugs) and releasing.
> > - Ability to release 1.3 beta/alpha and get more testing.
> > - Continue doing back porting of good changes, but are not critical to
> 1.3
> release without destabilizing.
> > - Unblock 2.0 changes
>
> +1 in theory... However as Roland pointed out, I think we unfortunately
> know
> from past experience what would likely happen in such a scenario. And quite
> frankly I'm not prepared to spend the same amount of effort as I did in the
> past to maintain 1.3.x <==> 2.0.x ports.
>
> Bottomline: I propose that we
>
> - (Paul) stop submitting 5-10 pull requests per day for now,
> - focus on testing and fixing issues and stabilization instead, then
> - get alpha out the door ASAP, and
> - resume the new features fest after 1.3.0a1 is out.
>
> Damien
>
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>