[pkg-wine-party] Wine for buster Re: wine plan for stretch
jre.winesim at gmail.com
Sun Apr 9 09:42:13 UTC 2017
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
> 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
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
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
More information about the pkg-wine-party