Re: RFC: time for a new mingwrt/w32api release?

On 5/16/2016 11:14 AM, Keith Marshall wrote:
> On 15/05/16 22:50, Cesar Strauss wrote:
>> Em 05-12-2016 18:40, Keith Marshall wrote:
>>> To prepare for this, I'm considering:
>>>
>>> 1) Rename the existing "5.0-dev" branch as "5.0-deferred". 2)
>>> Create a new "5.0-dev" branch, based on the tip of "legacy".
> 
>> Anyone who is tracking locally the old "5.0-dev" branch, and tries
>> to pull, will get conflicts, as git tries to merge the two
>> branches.
> 
> I know; I hoped that might provoke a reaction.  It's also why I didn't
> just go ahead and do it -- right now, in my hg clone, I have:
> 
>   $hg bookmarks
>      4.0-dev                   148:6878646b9e6d
>      4.1-dev                   139:ef755022d08c
>      5.0-active                253:2c9a07dbfed6
>      5.0-deferred              81:723274c6d978
>    * cygwin-updates            257:f3d34694666a
>      legacy                    252:7c13c3b4989e
>      master                    118:821fbe0e4347
> 
> (Mercurial's bookmarks are the equivalent of git's branches; hg's
> branches are altogether more concrete entities).
> 
> FWIW, the conflicts would only arise for a user who actually has a
> local reference for 5.0-dev, prior to a pull; easily avoided, by a git
> remote prune, (to update the remote references), and a local rename of
> the offending 5.0-dev branch, *before* the pull.
> 
>> On the other hand, there is a good chance that the number of
>> affected people, actively tracking the "5.0-dev" branch, is
>> actually zero.
> 
> That's a metric I hope we might be able to establish, at least as it
> relates to participants on this list.  I'd like to think that it *is*
> zero, since there seems to be no actual head branching from that
> label; it appears to be no more than a place holder, currently
> referring to the same location as 4.0-rc1, (which begs the question:
> why was it designated as 5.0-dev in the first place?)
> 
>   $ hg heads
>   changeset:   257:f3d34694666a
>   bookmark:    cygwin-updates
>   tag:         tip
>   ...
> 
>   changeset:   253:2c9a07dbfed6
>   bookmark:    5.0-dev
>   ...
> 
>   changeset:   148:6878646b9e6d
>   bookmark:    4.0-dev
>   tag:         default/4.0-dev
>   ...
> 
>   changeset:   139:ef755022d08c
>   bookmark:    4.1-dev
>   tag:         default/4.1-dev
> 
>   $ hg tags
>   tip                              257:f3d34694666a
>   default/legacy                   252:7c13c3b4989e
>   mingwrt-3.21.1-release           189:283116261e25
>   mingwrt-3.21-release             182:e6ff0d91cb50
>   default/4.0-dev                  148:6878646b9e6d
>   default/4.1-dev                  139:ef755022d08c
>   default/master                   118:821fbe0e4347
>   4.0.2                            116:d85ed4c5f45a
>   4.0.1                            113:2c3b39234ed9
>   4.0.0                            112:f6babc931a5d
>   default/5.0-dev                   81:723274c6d978
>   4.0-rc1                           81:723274c6d978
> 
>>> 3) Implement an integrated build infrastructure, preserving the 
>>> existing separate package configuration, but building both 
>>> together, with enforced version number synchronization.
> 
>> Interesting. Will there be only one source tarball?
> 
> No.  One common repository, but "make dist" would preserve the two
> distinct source tarballs, (for now).  We could consider augmenting,
> (or replacing), those with an additional integrated tarball, later.
> 
>> Will "make install" create a mix of the two packages in 
>> $prefix/include
> 
> Yes, (if a common prefix is used for "make install" in both package
> sub-directories) ... and
> 
>> and $prefix/lib, which the packager will have to untangle later?
> 
> no, "make dist" will install into two distinct staging prefixes, so
> maintaining integrity of the two separate binary distributions.  FWIW,
> my first step in integration is specified by the attached patch.
> 

I've no objections to any of this.

-- 
Earnie

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j