On 03/28/2014 06:40 AM, Vincent van Ravesteijn wrote:
On Fri, Mar 28, 2014 at 11:10 AM, Jürgen Spitzmüller <sp...@lyx.org
<mailto:sp...@lyx.org>> wrote:
2014-03-28 10:56 GMT+01:00 Vincent van Ravesteijn:
Do you prefer workflow as:
new -> fixed in master -> fixed in master and stable ->
closed(fixed)
new -> fixed in stable -> closed(fixed)
new -> fixed in stable -> fixed in master and stable ->
closed(fixed)
new -> fixed in master -> closed(fixed)
In the current workflow, we can't specify whether something is
stable-only or master-only (one has to guess from milestone).
If we do it like this:
new -> fixed in master -> fixed in master and stable -> closed(fixed)
new -> fixed in stable (stable-only) -> closed(fixed)
new -> fixed in stable -> fixed in master and stable -> closed(fixed)
new -> fixed in master (master-only) -> closed(fixed)
we have this info available.
Besides we can have a correct percentage in the roadmap.Then, "fixed
in master and stable", "fixed in stable (stable-only)", "fixed in
master (master-only)" all define the end-state, while "fixed in
master", "fixed in stable" do not. Otherwise, different milestones
(stable or unstable) have a different definition on what the end-state is.
Also, "fixed in stable (stable-only)", "fixed in master (master-only)"
can be merged into a single status: "fixed (this milestone-only)". If
the bug has a minor release milestone, it is branch-only, if it has a
major release milestone it is master-only.
new -> fixed in master -> fixed in master and stable -> closed(fixed)
new -> fixed in stable -> fixed in master and stable -> closed(fixed)
new -> fixed (this milestone only) -> closed(fixed)
Unfortunately, it is not (yet) possible to offer options only with
respect to the major/minor milestone set.
I think this one that you had earlier:
new -> fixed in master -> fixed in master and stable -> closed(fixed)
new -> fixed in stable -> closed(fixed)
new -> fixed in stable -> fixed in master and stable -> closed(fixed)
new -> fixed in master -> closed(fixed)
is complicated enough. The difference between "stable-only" and
"master-only" can be indicated differently.
First, if a bug is master-only and is fixedinmaster, then it can be
closed. The bug was only ever in the development branch, and was never
released. This is current policy.
Second, if a bug is stable-only, then it can be marked fixedinstable,
with milestone set to the next release. This indicates that it does not
need to be fixedinmaster.
Third, if a bug is in stable and master, but is for some reason fixed
first in stable, then a separate bug should be opened and marked as a
high priority regression in master. The stable release maintainer (new
name) will otherwise have a problem when the next stable version is
released: The bug should be closed at that point, but it is still in master.
Richard
