git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Testing 4.0 Post-Freeze


tl;dr: +1 for committing to testing + bugfixing after feature freeze, but I
can't really see how changing the branching strategy is going to have any
impact at all.

I really don't think it's a big deal. People will work based on whatever
priorities they've been assigned, regardless of what you do to the
branching. That's essentially just red tape and adding unnecessary
complexity to an already established process. Granted, you'll have to do
one less merge, but it should be an effortless merge, and it saves there
being any confusion about what people should do with features. If someone
decided to commit a feature, they could, and we wouldn't have to be all
over every ticket making sure people don't commit things that shouldn't be
committed.

Cutting to the point, all we're really aiming for here is a commitment from
the community to only dev on bugfixes, only review bugfixes, and
testing/validation during the freeze period. That's not going to be
enforced by a change in branching strategy, it's going to be enforced by
the contributors themselves (and their respective priority-setters).
The best we can do is encourage a commitment to testing and bugfixing for
the freeze period. This is a volunteer based project after all, so we can't
really force anyone to do anything. If contributors make proposals for
features in the freeze period we can just tell them that there is a focus
on 4.0 testing and it's unlikely to be reviewed until 4.0 is released at
best.

On another note, we are still planning on accepting/reviewing bug fixes for
previous versions as well correct?  Just to clarify because it doesn't seem
to be mentioned here and we don't want people getting in arguments over
reviewing patches that only affect older releases.

I think not having your patch reviewed for months is more
> discouraging than following the community and helping with stability of
> 4.0.

Patches not getting reviewed for months on end already occurs. Changing how
we branch isn't going to change this or make anyone feel better about it.
The best we can do is communicate why their patches aren't getting
reviewed, and we should be doing this on individual feature tickets that
get raised and on the ML.

On 4 July 2018 at 00:44, Mick Semb Wever <mick@xxxxxxxxxxxxxxxxx> wrote:

> >
> >
> > We propose that between the September freeze date and beta, a new branch
> > would not be created and trunk would only have bug fixes and performance
> > improvements committed to it.
> >
>
>
> +1, like really yes!! because it's a step towards a more stable-master
> project.
>
> If trunk is focused on stabilising (which ideally it shouldn't have to, if
> stable-master were true) then new features remaining in their respective
> branches shouldn't be a big cost or risk (nor seen as anything negative).
> And hopefully any additional practices/lessons learnt from during the
> freeze period get carried on for good.
>
> Although, and unfortunately, there's just not the testing infrastructure
> available to the public to ensure feature branches are solid before
> merging. But I struggle to see that as an excuse to only "stabilise" on
> release branches.
>
> 2¢,
> mick
>