RFC: time for a new mingwrt/w32api release?

[Keith Marshall-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guys,

It's been a long time since we last released an update for this pair
of packages.  I'd like to prepare a new combined release, preferably
with synchronized version numbers, but given the problems inherent in
the last combined release, (v4.0), I think that any new release should
be derived from the current "legacy" branch, and should skip
immediately to a synchronized version number of 5.0.

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".
3) Implement an integrated build infrastructure, preserving the
   existing separate package configuration, but building both
   together, with enforced version number synchronization.
4) Create an early 5.0 release, substantially unchanged from
   the current "legacy" tip, (possibly with a few new features
   which are already "good to go").

Any thoughts?  Objections?

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJXNPhiAAoJEMCtNsY0flo/eJAP/3TmB73IRUMbuGf7jzMDzrxG
m50njM3TNHx0lv9mFsLZBSdlc4xPl2MXQt60wk6vp3bH3Sug0fsooykCh6RHdOWb
N9nrR+W/HuoIT4tATrByqP5bHMIuGX0iwMN21rvecSyAtBiG8SZV57Z00+7kmW7/
upY37sl5tFE/m5fzjdiRdvB6ieK1afeIrtI60LkA86JsuuuRqgkSHjnz34HLzlPX
Ix3fXU3W6feX7FxDRN2SEySUNDXdoq7EubhFrv3hZGwXs+VjWSt08uFfJMvy5/Hm
iYmDMJo0KLmy7WC5p3LT8/BvQSV6h8nOImWdkBD56hR7eL7y6Vi4g+i32BKuVtog
uJs5GHcOfxpg3kFELJXbuYLKkI60+WztZtBB/Ou4CMgSD/quEJXaqzbkiCaEZLsA
p0UI7lCmC1qkhR0r8lw8IdTDQZVH5nz++XSe2B+4xz4QiaarrAUuhvvebFyFDD9u
y/GzEH135/Tl2XbO/54ige0D2IZreywW9+j6L5Xggab7HIsYYXNBmn2dGYvFxar7
dZHtYWUhLcokSdOPmWTaDnZRdnPa1WOqWk9O9TxDeuBOdbSHTN4regr/b7OIn6pG
7EnwafSwNShQ40fC3Yf2TQ7j609H+Wn3Cx4j/0qI8+pEBgcvQYiVfSzXdcWsqY4X
DLZXNKndwiO6VE2vGYxV
=+8jD
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Cesar Strauss-2]

Em 05-12-2016 18:40, Keith Marshall wrote:
> It's been a long time since we last released an update for this pair
> of packages.  I'd like to prepare a new combined release, preferably
> with synchronized version numbers, but given the problems inherent in
> the last combined release, (v4.0), I think that any new release should
> be derived from the current "legacy" branch, and should skip
> immediately to a synchronized version number of 5.0.

OK.

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

> 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? Will "make install"
create a mix of the two packages in $prefix/include and $prefix/lib,
which the packager will have to untangle later?

> 4) Create an early 5.0 release, substantially unchanged from
>    the current "legacy" tip, (possibly with a few new features
>    which are already "good to go").

Sure.

Regards,
Cesar

------------------------------------------------------------------------------
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
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Keith Marshall-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJXOePsAAoJEMCtNsY0flo/RegP/Rq+u4tYVzi/JctdEprs8P0F
IDltja14/Lu3GNcojBJSm4Z3Ry1lp7h91GHyfaKnTJkkMpmozOUoKVkal/pwkd8E
0EeJI/ai8edeK0GY5KEslpBljIjAKjNC2aoLRBfUw968mNt9Tyj6LeOxKTcdt0am
An6IpblHOlOVBb8RgyF9XqEqcO0f9mRrsyUUmuSZkAi256UXd7DWZOVLVwrEDdX2
QP3TcoQKOUJD/CZq0LmSeK8ezj7xR1+HeZLvKQZ8b6aKC8n0eLwxdcGMO9eTgPgd
LFd6hopSnm8XvLGicAzZnhmNt5+92zjBn91j2Vi/elTBfICu3afvjviDDwwYJjcg
jk1NJfWOD16jBf3hidUQSUQOS+klbbcNOtU7f/Il5enfo4dBYuZNyP7xTVzhknrS
SF1A+pu2rxwyJ1Cgl92+UxKsxH76sc+gcNDJuksNCl7Ks9Cr37eW1UAbvEOM21X2
IYaatPnk4Tx+VzJx+WcKv1T13DJNuNmgHLkjM3/VdhlLZtihD+lLi3tz3CXUJE2M
3zV61iSjwfNMy43M7GFJInYDNEaX+BdtztRgWBSYkDVc6/YTE8bIkPiDB79v55q2
pZDc7rWJ3voE74KmoKfQ581fagMluoCTuWB1RzVhA+fRJ5JImoyIfRqpTfifFeuW
2BT/Qqd0PaHY0wsgiWJJ
=oJV8
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Earnie Boyd]

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
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Keith Marshall-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/05/16 16:14, Keith Marshall wrote:

>> 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?)

Given that the branch point was named, but no actual branch was ever
created, is there any *real* justification for keeping that original
(virtual) branch ... especially since the 4.0-rc1 tag marks the self
same point?  I'm thinking we might just as well delete this spurious
branch, without bothering to

> 1) Rename the existing "5.0-dev" branch as "5.0-deferred".

since there's no deferred development sitting on that branch anyway.

Thoughts?

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJXPIFxAAoJEMCtNsY0flo/CFgP/A8kVNuAZTsv+gHdI6QMZanU
RkIKg7Q4OKYDsvFdCGtWS/8wMcxeRD5b2PDeK3N5aKcQOZQgBArIJ5gDAwazuFg0
5cnSkeo5L3cdBVaxiFJ3tj+kKrJO0Zhox2Z86aAxfBlH37csYY2jIT735rgNMn9Z
UFTG+JIDk1Pf1oIjNob2xH8G2AcTF+xO3HVvlu76wtnoQeweluo7QsN+g9DPwjhO
8jjV2vvLC8gV62xQhw0h4YVrzsLLqCVy4M5dUEfyRJagB1xFj/lW3c5KLKCz3gRm
l3GbGpnooFWdjEXjbfM9HJQKm5R4CLyx7pnsfdzyBeiPBkuLMAqEJgS/WVoqlk7x
/Ye8EvbnwwEV5bQdoXivk7Cggt01srwQp0nZfpuCYFAc6BrhsA2gZ90/i+VxKvDH
0cx7LFWysTRz62Z8qQvqS+/DSw3j8Ff6iMDba8qeeIgS1tKdu3qNoMwA/21N0EwM
PUSsK2RD2ya7QCr6Lcd+o8/03BslShDa+Grnigqa7vJd574e3mHxj/lqhShZuApb
EOg7ORC6l3CCNzXPnTiZVUxWnYzv0romuYOdxnwyjRFyVjcZ7y8pz5zb8z2mAbF2
i4zrNnygsVtigayXKoQr3qxtbcsUVpzTmaOxeuaE7OQfgsvMz4NsyNW+BrSPD6jw
96EL7WXxBm47tOXkY+mY
=KkPQ
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Earnie Boyd]

On 5/18/2016 10:51 AM, Keith Marshall wrote:

> On 16/05/16 16:14, Keith Marshall wrote:
>>> 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?)
>
> Given that the branch point was named, but no actual branch was ever
> created, is there any *real* justification for keeping that original
> (virtual) branch ... especially since the 4.0-rc1 tag marks the self
> same point?  I'm thinking we might just as well delete this spurious
> branch, without bothering to
>
>> 1) Rename the existing "5.0-dev" branch as "5.0-deferred".
>
> since there's no deferred development sitting on that branch anyway.
>
> Thoughts?
>

Go ahead and remove it.  If someone needs it they can always recreate
it.  As you know I'm not currently developing on it anyway.

--
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
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr