-----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 |
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 |
-----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 |
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 |
In reply to this post by 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 |
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 |
Free forum by Nabble | Edit this page |