Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-release, 2016-01-13

| Channels | #perl6-release index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
02:48 ilbot3 joined #perl6-release
02:48 Topic for #perl6-release is now »r̈« - Discussions about Perl 6 and Rakudo release strategies - http://irclog.perlgeek.de/perl6-release/today
08:02 _Gustaf_ joined #perl6-release
08:08 FROGGS joined #perl6-release
11:44 FROGGS joined #perl6-release
13:43 pmurias joined #perl6-release
13:47 pmurias It seems that users declaring 'use v6.c' and depending on features from a newer version is a big concern. It seem to me that CPAN Testers style testing of modules in the ecosystem to check they support what they declare would help with that a lot.
14:07 PerlJam If someone says "use v6.c", then they can't use newer features without also saying something like "use experimental :feature" and I think that's fine.  It's one when they say "use v6.d.PREVIEW" and share that code with others where there might be a problem because "v6.PREVIEW" doesn't nail down the feature set.
14:08 PerlJam Personally, I'd rather not have v6.PREVIEW at all so that they must explicitly list which experimental features they depend upon.
14:10 PerlJam s:g/v6.PREVIEW/v6.d.PREVIEW/
14:10 nine PerlJam: explicit feature flags may be nice but no one has made a good proposal yet how to actually pull that off. Especially considering the explosion of combinations to test and large scale refactorings of internals.
14:11 pmurias how will those version pragmas work with methods?
14:13 pmurias if I call $foo.foobar in v6.c mode (assuming the foobar method was declared in v6.z) will rakudo stop me at dynamic dispatch time?
14:13 jnthn No
14:13 PerlJam nine: aye, it's bound to be complicated. Even if there were no refactoring of internals, some features may have far-reaching effects.  And it would *suck* to have if statements everywhere to decide which code path to take based on which features were enabled.
14:13 jnthn I don't think we can do much about method-level versioning.
14:15 nine jnthn: fun starts when code written in 6.c uses a method of a module written in 6.d and this method returns a CORE object. The 6.c code will probably expect this to behave as in 6.c...
14:16 nine PerlJam: that's exactly why I stick with the 6.d.PREVIEW thing, because it's dead simple in comparison
14:18 jnthn There's no 100% solution, so we just need to try and pick the least bad 80% solution...
14:18 pmurias jnthn: so that would mean we can't stop code declaring 'use v6.c' from depending on v6.d features
14:19 jnthn ...and part of making it "least bad" is that we can explain it to people.
14:20 jnthn Well, we could insist that a module or script that declares "use v6.c" cannot use another that demands a higher version.
14:20 jnthn Which would cover a bunch of the cases
14:20 nine That would throw out the kid
14:21 jnthn Quite possibly so, yes.
14:21 jnthn So maybe "worse is better" :)
14:21 pmurias do we have much changes for use v6.d that break backwards compability?
14:21 jnthn I'd really hope not.
14:22 nine hoelzro++ made the interesting suggestion to define coercions of builtin objects to lower versions of themselves. But that would mean that we need to detect boundaries between caller's versions.
14:22 jnthn Though I don't know what's been discussed while I've not been here.
14:22 jnthn nine: Yeah, I'm wary of that route.
14:22 jnthn I mean, we do have the hllize thing
14:22 jnthn Where we do enforce such things.
14:23 jnthn And could use that mechanism for versioning.
14:23 nine Sounds like an intriguing reseach project.
14:23 jnthn But...inserting coercions on hot paths could be quite devestating.
14:24 nine Yeah, especially if most incompatible changes turn out to be simple additions of new methods that would not break old code anyway.
14:24 jnthn Right
14:24 jnthn I think our best hope will be automated testing though
14:24 pmurias Not breaking old code should be the main code of language versioning
14:25 jnthn That is, making sure that something that declares itself 6.c actually runs on 6.c
14:25 nine 6.d changes that come to my mind are IO::ArgFiles replacement, an extensions of the Repository API, a new DateTime constructor (and possibly fixes)
14:25 jnthn Why did we replace IO::ArgFiles?
14:26 jnthn The latter two sound largely backward-compatible?
14:26 nine jnthn: https://github.com/rakudo/rakudo/commit/630a9b20f9e829bf153590dbf75a93a37eff7304
14:27 jnthn Urgh, yes, that one really blows it.
14:28 jnthn Though I wonder how different it is from a userspace point of view
14:29 jnthn I think we'll have to discuss that patch some.
14:29 lizmat jnthn: afaik, I already reverted it for 6.c
14:30 nine Yes, it's only in the language_versions branch for now
14:30 jnthn OK
14:30 jnthn Then it's not a big deal.
14:30 lizmat from userpoint of view, there is no difference
14:30 nine It was a good testcase for the language_versions architecture.
14:30 jnthn OK. And since the symbols are a lexical visibility thing then use 6.d handles it nicely.
14:30 lizmat the only spectest that failed, was testing for the existence of the IO::ArgFiles class
14:31 jnthn lizmat: OK, that's encouraging.
14:31 lizmat I made sure it would not cause any user API changes
14:31 lizmat it was meant to generalize, not break things
14:32 jnthn In genearl, I think we both (a) have a bit more lattitude in 6.c -> 6.d to tweak things than we'll have in, say, 6.d -> 6.e, just out of userbase size, but (b) we shouldn't push our luck, because we don't want a reputation of gratuitously busting stuff.
14:32 nine If it was just about that change, I'd even say it should just go in. There is a little leniency left after the first release.
14:32 jnthn Yeah. But I agree that now is the time to start working on our approach/infrastructure to manage version issues.
14:33 jnthn Because 6.c -> 6.d upgrades will tell us how well we did at it, which is useful feedback.
14:33 nine At least the query_repos branch is waiting on it and a couple of pull requests IIRC.
14:34 jnthn The other big policy decisions will be what a script that doesn't declare a version implies about language version, and what a plain "use v6;" means.
14:36 jnthn (My feeling being "latest" and "latest so long as we can see that won't cause mass bustage" respectively)
14:36 [Coke] don't declare means whatever's easiest for us. We have to win one of these. :)
14:37 nine I think no version == highest version makes sense, especially from a "10 years later" viewpoint.
14:37 jnthn nine: Yes, exactly
14:37 nine I'm not sure how to implement that in the Grammar though :) Haven't done much in that part of the code base.
14:37 PerlJam apparently that one is easy since we all seem to agree :)
14:37 nine I've figured out enough to hack in some 6.d support for testing :)
14:38 jnthn Yeah, I don't want poor Perl conf speakers wanting to show off new features in 10 years time to have to adorn all their examples with use v6.i or so :)
14:39 nine or shell one liners ;)
14:39 nine Especially if we ever want to consider dropping support for older versions
14:40 pmurias won't people just forget to declare the version and then complain/get annoyed when things break?
14:41 PerlJam There will always be complainers
14:41 moritz ther's no "no complaints" universe thinkable :-)
14:41 nine The same people would get annoyed and complain if most documented things don't work in their script because they forgot the mandatory use v6.X
14:42 jnthn pmurias: Yes, which is why I want to have this policy from the get-go, so we get a cultural meme of "you should declare version for anything going into production" :)
14:42 jnthn (If you want to manage things that way)
14:43 jnthn (And for small things folks likely won't.)
14:43 jnthn It's just part of "make the easy things easy"
14:44 nine Detailed question: does no version also mean that PREVIEW is active?
14:44 PerlJam -1 to that
14:45 PerlJam no version should mean highest standard version.
14:45 * jnthn agrees with PerlJam
14:45 nine Great! This means that I don't actually have to figure out this highest standard version thing till 6.d is released :)
14:46 jnthn ;)
14:46 PerlJam As long as we've stacked things so that programmers are always coding to some standard and have to declare that they are doing otherwise, we're doing good
14:53 pmurias_ joined #perl6-release
15:01 nine Btw. a very nice advantage of the core.d structure is that as long as you only make changes in core.d and not in core.c the compile/test cycle is much shorter :)
15:02 jnthn :D
15:03 lizmat I feel like I'm being the spoilsport yet again, and maybe it's just because I'm depressed
15:04 lizmat but we want "use 6.c" give a set of capabilities on which a module developer can depend
15:04 lizmat how will that be working with fixes at the nqp / moarvm level ?
15:04 lizmat aka: on a 32bit machine, can you depend on large ints working if you say "use v6.c" ?
15:04 [Coke] my best thought there is "run it against roast/6.c"
15:05 lizmat so I do that, and it works
15:05 lizmat but then, as a module developer, I'm starting to get bug reports about it not working
15:05 lizmat *then* it turns out, you would need a more recent MoarVM / nqp
15:06 lizmat if you're using 2015.12, then it won't work
15:06 lizmat so, "use v6.c" in that case, is pretty worthless
15:06 lizmat as a way to make sure your module will work
15:07 lizmat So I guess I'm asking: did we think about this?  did we decide on this?
15:08 [Coke] so if it's behavior that isn't defined by the spec, and you need a specific version of rakudo to make it work, then you're back to FROGGS(?) ask for a use rakudo<2016.03>
15:08 nine Seems to me like some things work great in Firefox but break in Chrome despite both claiming to support CSS 2.1.
15:08 [Coke] lizmat: we're having the discussion in here, right now.
15:08 nine There will always be implementation bugs
15:08 jnthn The interface between Rakudo/NQP and MoarVM is far more narrow than the interface between Perl 6 programs and the Perl 6 CORE and compiler.
15:09 jnthn And so easier to keep compatibility.
15:09 lizmat [Coke]: I'm talking about behaviour that *is* defined by spec
15:09 lizmat but which isn't working for some versions of 6.c
15:10 nine for some versions of some compilers that claim to implement 6.c
15:10 lizmat how will you, as a module developers, deal with that ?
15:10 jnthn lizmat: What do you mean by "spec"?
15:10 [Coke] if the behavior is defined by spec, and we've tested it for each release, and it worked on each release, then how is there a disconnect?
15:10 jnthn Spec = the test suite
15:10 nine Spec is also rather thin in many areas
15:10 lizmat ok, defined by test-suite
15:10 jnthn Which probably needs to double (or more) in size
15:10 PerlJam lizmat's situation sounds like either a) we can't express the change in nqp/moarvm as a test or b) we forgot to write said test.
15:11 [Coke] not b, because she said it's in the spec.
15:11 [Coke] nor a, because she said it's in the spec. ;)
15:11 lizmat *or* we did write the test, and it's not working for a user of a module for whatever reason
15:11 lizmat and guess what: the spectest for it fails as well
15:11 nine tests can also be buggy :)
15:11 PerlJam then .. we shipped a buggy compiler
15:11 PerlJam (or what nine said)
15:11 jnthn I think it may help us to flesh out the various upgrade paths / combinations that might happen.
15:12 jnthn That is, list the various permutations to consider
15:12 jnthn And then we can figure out what our answer is to each of them
15:12 * PerlJam is getting a sense of deja vu
15:12 lizmat PerlJam: of what ?
15:12 [Coke] anyway, I think the answer to liz's question is frogg's ask for a specific version of rakudo.
15:13 [Coke] (assuming that we're still tying specific versions of rakudo to the identically versioned versions of nqp & moarvm)
15:13 jnthn But overall, I'm not *that* worried about the MoarVM fixes issue.
15:13 PerlJam lizmat: just like we've talked about nqp/moarvm changes affecting tests before
15:13 lizmat yes, but *that* basically means that for module developers, "use 6.c" is pretty much useless
15:14 pmurias lizmat: your are concerned about the case when the user is using the v6.c version of Perl 6 but is depending on a bug being fixed in a much latter version of Rakudo?
15:14 jnthn lizmat: You seem to be seeing something as binary that is a scale.
15:14 PerlJam I think that "use rakudo mumble" is a good alternative to "use v6.d.PREVIEW" though.
15:15 [Coke] I don't have a particular problem with being able to require certain versions of the compiler.
15:16 jnthn lizmat: That is, "use 6.c" can promise you things like "IO::ArgFiles is still there". It maybe can't promise you "bug X that you were highly unlikely to depend on got fixed"
15:16 [Coke] (ala p5)
15:16 jnthn lizmat: But to me this is mostly about risk and cost management - that is, keeping the risk of upgrading and the cost of upgrading sufficiently low that people don't worry about doing it.
15:17 [Coke] probably don't need use - if this is for module authors, they can poke in the $* variables to get the compiler version and key code off that.
15:17 lizmat [Coke]: please no, not a repeat of what $VERSION means in P5  :-)
15:18 lizmat if we're going to allow selection by compiler version, we need to provide an API for it
15:18 [Coke] lizmat: I mean, it's already out there, we can't stop them. We could put a use pragma in front of it though.
15:18 jnthn lizmat: And I don't know that we can actually solve it with broad/general rules. I fully expect there'll be times where we think we can get away with a fix, and test results from the ecosystem tell us "no".
15:18 lizmat and not let everrybody figure out their own cargo-culted way
15:19 jnthn And, in the longer run, I expect the test suite will evolve to nail things down much better than it does so far.
15:19 lizmat ok, let's shelf the underlying compiler issues
15:19 lizmat what about bugfixes that we're going to do in 6.c
15:20 lizmat if a module depends on a bugifx
15:20 lizmat it would need to do a check on compiler to ensure it runs on all versions of that language level
15:20 nine [Coke]: "require certain versions of the compiler", which "the compiler"? Just because right now there's only one doesn't mean that it will always be so.
15:21 [Coke] nine: which is why I think doing it via a conditional is easiest, yes.
15:21 lizmat so therefore I think "6.c" should be what we delivered at Christmas
15:21 jnthn lizmat: "it depends"
15:21 nine lizmat: it should actually better check for the bug being fixed. Test suits seem to be a good way to do this.
15:21 lizmat and any fixes should be done in 6.d.DEV
15:21 jnthn lizmat: Largely on where the fixes go.
15:22 [Coke] I don't want to support 6.d.DEV
15:22 jnthn If we're worried about compiler fixes there's nothing, in theory, to keep us from shipping the grammar/actions/world for 6.c
15:22 lizmat nine: so, you should simply not install on a compiler with the bug ?
15:22 [Coke] also, 6.d.DEV is far more likely to change and break until 6.d is released.
15:22 nine lizmat: yes
15:23 nine lizmat: same as if you specify a certain compiler version but much more future proof
15:23 jnthn sorry, bbi10
15:23 nine If it's a test that's specifically written for a known compiler bug, the diagnostics can even tell the user to upgrade the Perl 6 compiler to a fixed version.
15:24 nine Or switch to a different compiler.
15:24 nine And the multiple compilers issue is not even now all that theoretical. We do have two different backends with different bugs right now.
15:24 nine And one more on the way.
15:24 lizmat ok, fair enough, let's at least codify that approach in documentation
15:25 nine And now I'm getting this extremely weird deja vu like I had a simmilar discussion before FOSDEM a year ago!?
15:26 lizmat possibly
15:26 nine Btw. thank you all for having this discussion :)
15:31 pmurias nine: re which compiler you can just declare the required rakudo version
15:32 pmurias nine: it seems better than copy & pasting a bunch of tests
15:33 nine If you grow tired of testing for those bugs, make sure those tests go into the spec test suite of the next Perl 6 version and declar a dependency on that version once it's out.
15:35 nine Because: how many such bug fixes will an average module need on average? I really hope that I won't have to test for 10 compiler bugs for each Perl 6 version Inline::Perl5 is going to support.
15:35 pmurias nine: there is a recent string concatenation bug in MoarVM I don't know how to properly test
15:36 lizmat nine: it's exactly *that* what I'm worried about :-(
15:36 nine If we can't test it, how will we make sure that even if there's a fix in 2016.01, that we don't break it again later?
15:36 [Coke] lizmat: you don't have to be sad, it's ok. :)
15:37 nine If you can't test it, a minimum version of the compiler just won't do it.
15:37 lizmat well, autarch's last seemingly simple addition to Test.pm, breaks one spectest for reasons I can't seem to get behind :-(
15:37 [Coke] One thing we should also be thinking about is: what's the minimum amount we have to decide before we cut one more release. If we can avoid deciding something, that's great. (I'm not sure anything yet falls into this category, though)
15:39 lizmat so I'm about to revert autarch addition because it's a valid spectest, and I can't change that
15:40 nine I actually think it would be good to move Test.pm to the module ecosystem.
15:41 lizmat how would you do spectest then ?
15:41 lizmat you would need to install it ?
15:41 nine yep
15:41 lizmat make test also uses Test.pm
15:42 lizmat not in all of the files, but in some
15:42 nine Ok, rakudo can still ship with a Test.pm but it doesn't necessarily have to be the one that users use.
15:42 nine There's nothing forcing us to install it as part of a CORE distribution.
15:45 pmurias_ joined #perl6-release
15:46 [Coke] ISTR that TimToady also mentioned revising 6.c as we go. (perhaps with a 6.c.1 if we find we've mistakenly included things we shouldn't've, e.g.)
15:49 hoelzro nine: are you referring to my COERCE idea? or something else?
15:49 pmurias nine: re if you can't test it, why a minimum version of the compiler won't solve this issue?
15:52 pmurias nine: I view depending on a minimum rakudo version as a way of saying that's the the lowest version of it I'm supporting
15:53 nine pmurias: what about different backends? What about other compilers?
15:56 pmurias other compilers just ignore that requirement
15:58 pmurias they can just run the module test suit and see if it runs
16:01 nine rakudo-j 2016.05 may fix a bug that has been fixed already in rakudo-m 2016.02.
16:03 pmurias it should be possible to add requirements for both (in some meta data) file
16:04 pmurias so the module is not marked as failing on rakudo-j 2016.05 but as unsupported
18:29 lizmat Q: I just realized that nqp::readlink is not exposed at the P6 level.  Do I wait for 6.d to add IO::Path.readlink, or can I add it to 6.c ?
18:30 lizmat there are currently no tests for it
18:30 lizmat oops, there are
18:30 lizmat ?
18:30 lizmat ah, only indirectly, through IO::Path.resolve
18:31 lizmat so, no tests
18:32 nine If we add API to compilers claiming to provide 6.c, we tempt people to rely on those API features to be there.
18:34 TimToady an argument for 6.c.1, seems
18:34 TimToady or 6.d.MUMBLE
18:34 jnthn Indeed. API changes/additions are exactly the kind of thing we want to have as something that can be referred to under language version.
18:35 lizmat so 6.d.MUMBLE I understand ?
18:35 jnthn Well, we maybe need to think about what we consider a "major" bump to be.
18:35 * TimToady notes that 6.d.MUMBLE is before 6.d.a, 6.d.b, 6.d.c ... 6.d.0
18:36 jnthn I was pondering to use those more for "market this one!" things
18:36 jnthn And 6.c.N for incremental tweaks.
18:37 TimToady so where does exposing readlink fall in that?
18:37 TimToady that it's missing is kind of a bug
18:37 jnthn I'd hardly a headline thing :)
18:37 nine And since I've got all of you together: what should happen with a "use v6.d.PREVIEW" script on a compiler that supports the actual 6.d?
18:37 TimToady you called it without calling it
18:38 jnthn *It's
18:38 jnthn So it'd be a 6.c.1 or so thing
18:38 TimToady I wouldn't think 6.d.a, 6.d.b would be headline things eaither
18:38 jnthn Right
18:38 TimToady more like, here's the proto 6.d this particular compiler is supporting
18:39 jnthn I'd rather we avoid going down the road of people declaring dependencies on compiler versions, if we can avoid it.
18:39 jnthn But for now that means that we're going to need somewhat-frequently (every few month) incremental language releases.
18:39 TimToady well, but you want to evolve the tests in sync with the compiler, methinketh
18:40 jnthn Oh, for sure.
18:40 TimToady that's what I mean by 6.d.a
18:40 TimToady just happens to coencide with a compiler release...
18:40 TimToady *coincide
18:40 TimToady but still language related really
18:40 jnthn Ah, 'cus 6.d.a comes prior to 6.d
18:41 TimToady and after 6.d.PREVIEW :)
18:41 TimToady since we're case sensitive
18:41 TimToady PREVIEW just gets anything .a .b etc
18:42 jnthn I'm also pondering the "which are the long term support releases" question a bit
18:42 TimToady and dev vs maint is the .z to .0 transition
18:42 jnthn Trouble is that you don't tend to want to label a release as one until you've seen how it panned out in the wild :)
18:43 TimToady 6.d.0.rc1  :)
18:43 jnthn .oO( Everything can be solved by adding more parts to the version! :P )
18:43 TimToady is before 6.d.0
18:44 TimToady basically, we decided that letters were negatives compared to 0 at some point
18:44 TimToady except they're alsy relative to a rather than z
18:44 TimToady *so
18:44 nine Err...hate to interrupt, but does _every_ packaging system adhere to our ordering of versions?
18:45 TimToady most packaging systems already let you have only one version, so the point is moot
18:45 TimToady we have to bypass most packaging systems to get multiple versions already
18:46 TimToady how we do that is probably gonna vary depending on the system
18:46 TimToady but an awful lot of 'em just assume the latest is always the one you want
18:46 nine true
18:46 TimToady so our "latest" has to somehow contain everything we want to provide
18:47 TimToady basically, yet another spot where Perl has to subvert the prevailing culture, nothing new here... :)
18:48 TimToady note that the python2 vs python3 thing is this very same issue, write larger
18:48 TimToady *writ
18:49 [Coke] btw, do we need to announce somewhere other than in the docs/rel* that we're not shipping a rakudo this saturday?
18:49 [Coke] I suspect a small email to perl6-users might be in order.
18:50 jnthn Generally on versioning though, I think we need to try and be a bit more forceful about what the correct thing to call 6.d is (that is, 6.d :))
18:51 jnthn 'cus this time around we've had folks call it 6.c, 6.0.0, Perl 6 v1.0, etc.
18:52 TimToady people will still make things up out of their heads, of course
18:52 jnthn For sure, we can't stop that :)
18:52 jnthn But we can be more clear.
18:53 jnthn And we need to have a clearer story for marketing purposes too
18:54 TimToady the "6.d is like a C99 spec" meme is potentially helpful there in setting expecatations
18:54 jnthn Like, I'm currently imagining some way down the line I'll be giving a talk like "What's new in Perl 6 Devali?"
18:55 TimToady or however we end up spelling it...
18:55 jnthn TIMTOWTSI :P
18:55 TimToady well, that's one reason we went with alphas, to associate easier names
18:56 jnthn Yeah. I like it.
18:56 TimToady and picking from a wide range of festivals gives us the multi-cultural meme
18:57 TimToady so I'd be in favor of the one after that being Eid, say, provided it doesn't come off as sacriligious to the typical follower of that way of thought
18:59 TimToady though given the current generational tussle, all bets are off as to what the atypical follower might think...
19:03 PerlJam We could arrange that the Eid release happen in July too  :)
19:03 nine -1 on fixed release dates
19:04 jnthn Surely it should be based on when the release manager sees the moon? :)
19:11 TimToady well, we're not aiming to hit Diwali either
19:12 TimToady and arguably hitting Christmas on Christmas is a stunt we wouldn't want to repeat anyway
19:13 jnthn Indeed.
19:13 TimToady it was kinda fun once, but really, we'd prefer people not work on holidays...
19:13 TimToady and we kinda had to do it, because of the joke, but now that's over
19:14 jnthn Yes. I'd like to have an RC or two next time around. :)
19:47 TimToady maybe the "preview" wildcard should really be 6.d.ANY
19:49 TimToady actually, v6.d.* matches v6.d.a too
19:50 TimToady so really it depends on how much we want to propagate some MUMBLE meme or other
19:51 TimToady .PREVIEW sounds like it'll fail when we hit .0
19:54 PerlJam 6.d.DEV
19:58 * TimToady is backlogging and thinking that we need a notation for "highest standard version", which would be something like v6.*.0
19:59 TimToady oh, it already works that way, cool!
20:00 nine _Should_ .PREVIEW fail on a .0 compiler? I'm tempted to say: yes
20:00 TimToady .oO( v6.d.z- )
20:02 TimToady well, if we allow people to say v6.d.* for preview OR released, then PREVIEW could conceivably be the more specialized z- meaning
20:02 TimToady or maybe it's 0- and that excludes 0...
20:02 TimToady might be hard to teach that though
20:03 TimToady v6.d.- could mean anthing before 0, I suppose
20:04 TimToady though hyphens tend to intermix in real world versions, so probably not
20:05 * TimToady is not entirely clear about when .. snuck into version notations, or what its pervasiveness is
20:29 nine The language_versions branch now requires a use v6.d.PREVIEW for activating the core.d setting. With that I deem it mergable.
20:36 lizmat if we want a release on Sat, I guess we need to merge asap  :-)
20:37 TimToady it sounded like [Coke]++ already gave up on this Saturday
20:38 [Coke] Yes, saturday's a no go. We need to be really sure about our release plans, we're just not ready yet.
20:40 lizmat ok, but the longer we wait with a merge, the longer it's going to take to get a release, no ?
20:40 [Coke] (but I am very happy about the discussion going on, thanks everyone!)
20:40 [Coke] if we prematurely merge, it's going to take us longer to figure out how to fix things.
20:40 lizmat after a merge, how are we handling tests specific to 6.d.PREVIEW ?
20:40 [Coke] plan first, action second.
20:40 lizmat ok
20:41 [Coke] I presume 6.d.PREVIEW == roast/master
20:41 [Coke] when we cut 6.d, we cut roast/6.d
20:41 lizmat so 6.c is the version tagged for Xmas ?
20:42 [Coke] 6.c branch is what we shipped for Christmas, yes. It will also be the branch for 6.c.X if we need it, I imagine.
20:42 nine I wonder if we shouldn't do the same in roast as we plan to do with rakudo's setting
20:43 [Coke] I don't know if we think there is some level of change where we can modify those tests without calling it a new version.
20:44 nine We don't have to change them just because they're part of the same checkout. But I bet we'd run them more often.
20:44 nine Because it's more work to run only part of the spec test suite than it is to run everything while it's more work to run two branches than just the checkout
20:47 [Coke] ideally, we add 6.c test run to travis, so it's tested and reported on each commit.
21:09 jnthn Yes, one of the reasons I favored the "6.c subdirectory in roast" approach was to make it easy to always run those and easily see if we changed them.
21:12 [Coke] the branch was a stopgap to get a snapshot for the release. Not set in stone.
21:12 [Coke] (the nice thing about them being in a branch is it's hard for people to accidentally change them.)
21:12 [Coke] but if there's a better plan, by all means. I was just trying to get it out the door. :)
21:13 b2gills I was just thinking that the 6.c tests should each have a ï½¢ use v6.c ï½£
21:13 nine b2gills: that's the plan
21:13 nine Though that doesn't matter until there's a compiler that provides 6.d
21:14 b2gills There is another benefit to having the 6.c tests in a directory, it can be used on computers that don't have git installed
21:18 [Coke] git is a requirement for doing development work with rakudo.
21:18 jnthn [Coke]: It's hard for people to change them *in the branch*, but out of the branch it's really hard to know what is/isn't a test that was part of 6.c
21:18 [Coke] it's not a heavy lift. and if it is, how are people running the spectests now?
21:19 [Coke] jnthn: fair.
21:19 jnthn At least for me, it's useful to know "am I about to touch a 6.c test" (so I better think darn hard about it) or "am I touching a test that was never yet passing in an official release" (in which case I can relax, it's something we're still working on refining)
21:21 b2gills I have a project that has a data directory, and when I run a particular Perl 5 program it merges any changes into another branch containing just that dir
21:22 b2gills I wonder if we can do the same, or reverse ( sort of a best, or worse of both worlds )

| Channels | #perl6-release index | Today | | Search | Google Search | Plain-Text | summary