[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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
>>> 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 uploaded src:wine 2.0.1-1 and pushed it (to the already existing)
branch buster-2.0.

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
branch upstream-2.0.

Any objections or better ideas?


Reply to: