[pkg-wine-party] wine plan for stretch

[Michael Gilbert]

On Fri, Apr 7, 2017 at 8:44 AM, Jens Reyer wrote:
>> I'm not seeing the need for different branch names.  What am I missing?
>
> - If we need to update wine-development during freeze and already went
> ahead with newer upstream versions on master, we need a branch name for
> that.

Hi Jens,

The solution to that problem is pretty simple, only create the branch
when it's actually needed, rather than as a precaution affecting the
usual non-freeze work flow.

> - During the buster release cycle we'll probably have an update from
> 3.0.7 to 4.0.  Overwriting (git push --force) the old branch is
> definitely not an option.  Merging "theirs" might work (I would still
> spend lots of time to verify if this is true), but wouldn't provide a
> helpful logical git history.

Again, a new branch when needed solves this.

> - I assumed (before getting your answer) we were to go with several
> versioned packages, e.g. 3.0, 4.0 and 4.x.

That gets out of hand way too quickly.  My position is two src
packages at most in any given suite.

> For buster I think it's important to check upstream's plans in time
> (maybe 6 months before our freeze), and then come up with a plan and
> start implementing it.  If we wait too long in order to see which Wine
> releases are available, it would be too late to change the packaging logic.

I was going to wait to take into account what happens about a year
from now to figure out what's needed for freeze time two years from
now, that's my basic plan.

> I wonder how this would help with the original problem of
> choosing between upstream's oldstable and its brand new stable.

Here is the problem statement, there are two stable packages included
with stretch, but one is called a development version.  I'm not sure
right now exactly where the ideal solution resides, but the problem is
that the binary packages get a -development appendage in such a
situation.

Thank you for getting this process started, but I think we should take
the time to get the solution right, rather than rushing into something
that increases maintenance burden.

Thanks also for the work you've been doing to support the packages
lately.  I realized later my previous messages could have come across
too terse, but I do appreciate the work you're doing.

Best wishes,
Mike