Re: [pkg-wine-party] Wine for buster Re: wine plan for stretch
- To: Michael Gilbert <firstname.lastname@example.org>
- Cc: Debian Wine Party <email@example.com>
- Subject: Re: [pkg-wine-party] Wine for buster Re: wine plan for stretch
- From: Jens Reyer <firstname.lastname@example.org>
- Date: Thu, 4 May 2017 14:40:39 +0200
- Message-id: <[🔎] email@example.com>
- In-reply-to: <firstname.lastname@example.org>
- References: <CANTw=MPG3Cw551uSmc6CzF_taT9ZX4+1voK+_z5XLcH0UTYrPw@mail.gmail.com> <email@example.com> <CANTw=MP7rE_UYV5RW8foFGhpNURQoz6q8652RURXUkiyfGSToQ@mail.gmail.com> <firstname.lastname@example.org> <CANTw=MM=QqJJ=j8j9s1b6a1sj03c6GW0TeeG2ZSJ3pheUBvmbw@mail.gmail.com> <email@example.com>
On 04/09/2017 11:42 AM, Jens Reyer wrote:
> 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
>> 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 uploaded src:wine 2.0.1-1 and pushed it (to the already existing)
But for now I neither pushed my local branch upstream-2.0, nor changed
the import script in git.
For 2.0.2 I plan to change the import script on branch buster-2.0 like I
previously did in my reverted commit on branch master, and also push the
Any objections or better ideas?