Menu
▾
▴
lua-users-stdlib
|
From: Reuben T. <rr...@sc...> - 2013-03-23 13:38:55
|
[Gary: you're not yet subscribed. In the interests of long-term sanity, please do!] Some of the package tests are currently failing. Please can we have those fixed so we can release v34, which I need for another project? Feel free to push the changes to make modules other than package not perturb the global environment if they're ready; it'd be nice (but hardly essential) to get all the modules sorted in the same release. -- http://rrt.sc3d.org |
|
From: Gary V. V. <ga...@gn...> - 2013-03-24 11:56:38
|
Hi Reuben, On 23 Mar 2013, at 20:38, Reuben Thomas <rr...@sc...> wrote: > [Gary: you're not yet subscribed. In the interests of long-term sanity, please do!] Done, although it took me a minute to find the listserv. Might be worth advertising the list in README? > Some of the package tests are currently failing. Please can we have those fixed so we can release v34, which I need for another project? How about I tag the revision just before I introduced those failures, and release that as v34? I have about a dozen pending patches, all under revision, and requiring specs to be written to make sure they continue to work. I don't want to rush them and make a half baked release of these changes, so I'd rather take the time to finish and verify that everything was done correctly even if that means they don't get in until v35. > Feel free to push the changes to make modules other than package not perturb the global environment if they're ready; it'd be nice (but hardly essential) to get all the modules sorted in the same release. They're not, and I'm not confident enough that the changes I have completed already are optimal just yet, sorry :( Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) |
|
From: Reuben T. <rr...@sc...> - 2013-03-24 20:34:52
|
On 24 March 2013 11:37, Gary V. Vaughan <ga...@gn...> wrote: > Done, although it took me a minute to find the listserv. Might be worth > advertising the list in README? > A thought before I do that: maybe it would be better just to encourage the use of the github issue tracker? Otherwise we're basically saying "you need a github account AND a sourceforge account if you want to play with us" which seems mean. > > Some of the package tests are currently failing. Please can we have > those fixed so we can release v34, which I need for another project? > > How about I tag the revision just before I introduced those failures, and > release that as v34? > That would be nice, provided my recent patch to getopt goes in. In fact, preferably everything up to 47d51c718ce. Is that possible without messing with history? -- http://rrt.sc3d.org |
|
From: Gary V. V. <ga...@gn...> - 2013-03-25 01:44:42
|
Hi Reuben, On 25 Mar 2013, at 03:34, Reuben Thomas <rr...@sc...> wrote: > On 24 March 2013 11:37, Gary V. Vaughan <ga...@gn...> wrote: > Done, although it took me a minute to find the listserv. Might be worth advertising the list in README? > > A thought before I do that: maybe it would be better just to encourage the use of the github issue tracker? Otherwise we're basically saying "you need a github account AND a sourceforge account if you want to play with us" which seems mean. Well, you don't need a sourceforge account to sign up to the mailing list. However, I for one don't think much of sourceforge... it's littered with advertising, and slow as hell. I'd be very happy indeed to pretend they do not exist. If the github issue tracker is sufficient to your needs, then I see no reason to keep a sourceforce mailing list around too... > > Some of the package tests are currently failing. Please can we have those fixed so we can release v34, which I need for another project? > > How about I tag the revision just before I introduced those failures, and release that as v34? > > That would be nice, provided my recent patch to getopt goes in. In fact, preferably everything up to 47d51c718ce. Is that possible without messing with history? No it's not. And github (rightly) don't allow rewinding on master, so I just committed a revert for the premature branch merge. master builds and meets specs using both Lua 5.1 and 5.2 for me. Feel free to release, or ping me if you like me to do it. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) |
|
From: Reuben T. <rr...@sc...> - 2013-03-25 01:49:05
|
On 25 March 2013 01:44, Gary V. Vaughan <ga...@gn...> wrote: > > > > > That would be nice, provided my recent patch to getopt goes in. In fact, > preferably everything up to 47d51c718ce. Is that possible without messing > with history? > > No it's not. And github (rightly) don't allow rewinding on master, so I > just committed a revert for the premature branch merge. master builds and > meets specs using both Lua 5.1 and 5.2 for me. Feel free to release, or > ping me if you like me to do it. > > I'm unclear why you couldn't just tag before the bit you reverted? But fine, making a release now is good. Note that I changed the release source check-in scheme to work the same as that for luaposix, i.e. it expects to find a checkout of master next to a checkout of the release branch, the latter named stdlib-release. This avoids nuking files in the master checkout (in my case I found I was nuking all my release-notes-* files, which is not a disaster, but is a bit annoying). -- http://rrt.sc3d.org |
|
From: Gary V. V. <ga...@va...> - 2013-03-25 08:12:53
|
Hi Reuben, On 25 Mar 2013, at 08:48, Reuben Thomas <rr...@sc...> wrote: > On 25 March 2013 01:44, Gary V. Vaughan <ga...@gn...> wrote: > > That would be nice, provided my recent patch to getopt goes in. In fact, preferably everything up to 47d51c718ce. Is that possible without messing with history? > > No it's not. And github (rightly) don't allow rewinding on master, so I just committed a revert for the premature branch merge. master builds and meets specs using both Lua 5.1 and 5.2 for me. Feel free to release, or ping me if you like me to do it. > > > I'm unclear why you couldn't just tag before the bit you reverted? But fine, making a release now is good. So that the commits you made to master after the premature merge (particularly changes to the release rule) are available while making the release. > Note that I changed the release source check-in scheme to work the same as that for luaposix, i.e. it expects to find a checkout of master next to a checkout of the release branch, the latter named stdlib-release. This avoids nuking files in the master checkout (in my case I found I was nuking all my release-notes-* files, which is not a disaster, but is a bit annoying). Ack. No worries... I'll make another clone of the git repo, and fire off the release later this afternoon. Cheers, -- Gary V. Vaughan (gary AT vaughan DOT pe) |
|
From: Reuben T. <rr...@sc...> - 2013-03-25 13:10:40
|
On 25 March 2013 08:12, Gary V. Vaughan <ga...@va...> wrote: > Hi Reuben, > > On 25 Mar 2013, at 08:48, Reuben Thomas <rr...@sc...> wrote: > > On 25 March 2013 01:44, Gary V. Vaughan <ga...@gn...> wrote: > > > That would be nice, provided my recent patch to getopt goes in. In > fact, preferably everything up to 47d51c718ce. Is that possible without > messing with history? > > > > No it's not. And github (rightly) don't allow rewinding on master, so I > just committed a revert for the premature branch merge. master builds and > meets specs using both Lua 5.1 and 5.2 for me. Feel free to release, or > ping me if you like me to do it. > > > > > > I'm unclear why you couldn't just tag before the bit you reverted? But > fine, making a release now is good. > > So that the commits you made to master after the premature merge > (particularly changes to the release rule) are available while making the > release. > Ah, the reason I was puzzled is that the changes I mentioned I need in the release were all before the mistaken branch merge. |
