[pkg-wine-party] Wine for buster Re: wine plan for stretch

[Jens Reyer]

Hi Mike

On 08.04.2017 20:22, Michael Gilbert wrote:
> 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.

Generally I agree not to set up things that might proof unnecessary in
the future.  But I also favor having one logic, that can be reused
whenever something pops up (that's why I committed the change to
master).  With upstream's yearly release schedule we know that there
will be multiple major stable releases during our release cycles:
Buster will see 2.0, 3.0 and probably 4.0, which will all be packaged by
us.  (Of course nothing is 100% sure when talking about the future.)

Now, general matters aside, Wine 2.0.1 will be released in a few days.
Where should we put that?

For the packaging I already created buster-2.0, and I assume that like
tags we can't delete branches on alioth.  So I propose to continue using
that at least for the 2.0 series.  No decision taken how we continue
with 3.0.

Where do we put the upstream sources of 2.0.1?

* The 2.0 release is on "upstream", which is used by 2.x now.
* Based on my previous proposal I suggest "upstream-2.0".
* Alternatively we might use "upstream-stable", but that would be
  a non-fast-forward merge.
  My only hard opinion in this matter is to NOT do what upstream
  does, and overwrite existing branches.
* Some other name.
* I'm not totally sure about all effects, but we might merge the
  winehq tags directly in the packaging branch, instead of doing
  the 2 step approach we currently use.


>> - 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.

Fully agree.  I never wanted to suggest doing this, instead this is how
I (mis-)understood your mail from December.


>> 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.

Works for me.


>> 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.

Adding to this, I think we want to have one general installation advice:
"apt install wine"
And we want to define one specific version which will get installed then.


> 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.

Agreed.  I just want(ed) to avoid starting things which conflict with
(your) future plans.


> 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.

Thanks a lot, I really appreciate this!
And while I wasn't happy with the decision for Wine 1.8 in stretch, and
assume that this also reflected in my own communication, I'm really
looking forward to the buster development.  I definitely want to work on
this together.

Greets!
jre