Camelia, the Perl 6 bug

IRC log for #parrot, 2009-03-03

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 Infinoid I should rephrase that to say: parrot's string constants have always confused me.
00:01 cotto pmichaud, do you think it's worth digging into, or should I just leave the code as-is and assume that pointer comparison dtrt?
00:02 pmichaud I'd leave it as-is, personally.
00:03 cotto I'll go with that approach, then.
00:09 AndyA joined #parrot
00:16 alvar_ joined #parrot
00:22 tetragon joined #parrot
00:29 Limbic_Region joined #parrot
00:39 dalek rakudo: 4ec17da | pmichaud++ | docs/ChangeLog:
00:39 dalek rakudo: ChangeLog update.
00:39 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​ec17da9880835e5447a98a25f0e707f04c0e624
00:39 shorten dalek's url is at http://xrl.us/beh357
00:41 nopaste "kid51" at 71.247.39.200 pasted "Am I calling these tests correctly?" (10 lines) at http://nopaste.snit.ch/15758
00:52 Hunger joined #parrot
00:52 baest joined #parrot
00:53 rg joined #parrot
00:55 namenlos joined #parrot
00:57 baest joined #parrot
00:59 Coke kid51: no. -j is no longer a valid option
00:59 Coke You need --runcore=jit or -R jit now.
00:59 Coke (which 'make testj' should use)
01:01 kid51 Would it have been a valid option as of, say r37039?
01:01 omega joined #parrot
01:10 skv joined #parrot
01:55 cognominal joined #parrot
01:58 Tene_ joined #parrot
02:17 kid51 Coke:  You said earlier that -j is no longer a valid option to t/harness.  If so, then the POD to t/harness is out-of-date.
02:20 kid51 Does anyone know if, in Trac tickets, the 'Cc:' pane actually works?
02:20 rg yes, it does.
02:20 * purl stays quiet
02:20 kid51 I've added myself as a Cc to certain tickets, but not gotten any mail.
02:20 rg did you add your full email address?
02:21 kid51 No, based on previous instances, I just used my login.
02:22 rg since coke++ was kind enough to give me more trac privileges, i even have a checkbox that allows me to add myself at cc. works like a charm.
02:22 kid51 But there's a javascript popup on that pane that says:  "Space or comma delimited email addresses and usernames are accepted."
02:23 rg in fact, i can only add or remove myself, not edit the cc
02:24 rg but it's showing my full email to add, not my login.
02:24 rg maybe the usernames part is broken?
02:24 kid51 Quite possibly.
02:26 kid51 Let me use an email address in TT 385.  Then, rg, could you post a test message to TT 385?
02:26 rg you should already get the cc added as an email
02:27 kid51 You are correct.
02:27 kid51 Which means that the 'username' aspect of that is probably broken.
02:28 kid51 Which calls for a new TT!
02:28 rg :)
02:31 cotto The GSOC 2009 wiki page is very lonely.
02:33 kid51 link?
02:34 rg kid51: look, my first solaris smolder: http://smolder.plusthree.com/app/pu​blic_projects/report_details/18495
02:34 shorten rg's url is at http://xrl.us/beh4n2
02:36 rg hmm we really need to be more specific with the platform/architecture there. you can't tell that this is a 64bit build.
02:36 kid51 rg:  terrific!
02:36 kid51 I, too, have been using make smolder_coretest.  On my iBook, which is slow.
02:36 rg Duration   48:17 ... this thing is sloooooooow
02:37 kid51 Gawd, that's even slower than my iBook!
02:38 kid51 Vastly slower, in fact.  The duration on http://smolder.plusthree.com/app/pu​blic_projects/report_details/18491 was 17:04.
02:38 shorten kid51's url is at http://xrl.us/beh4oe
02:38 rg if i'm going to run smolder for all 4 combinations of cc/gcc and 32/64 bit or even 2 more with 64bit+long double, i can restart the whole procedure once one cycle is through ;)
02:40 rg i'm so happy for the am64 platform i'm usually working on. regular smolder in under 5 mins ;)
02:40 rg *amd64
02:40 kid51 So what you just posted is not from your regular platform?
02:41 rg no, that's a sparc so we can build big endian native_pbc files
02:41 kid51 k
02:44 rg i wonder, is sun4u known widely enough to tell it's 64bit?
02:45 rg but then the default build on those is still 32bit
02:45 * kid51 knows little about Sun/Solaris
02:46 kid51 rg:  If you're looking at a Sun box, can you add anything to https://trac.parrot.org/parrot/ticket/205
02:46 rg i wonder who's the poor soul who submitted http://smolder.plusthree.com/app/pu​blic_projects/report_details/18490
02:46 shorten rg's url is at http://xrl.us/beh4ps
02:48 cotto kid51, https://trac.parrot.org/pa​rrot/wiki/GSOC2009Tasklist
02:49 rg i think that's the atan2 problem with gcc. there's a note in the hints about that.
02:52 rg do you think i should copy the note to the ticket?
02:53 HG` joined #parrot
03:06 kid51 Why not?  I just added some speculation thereto.
03:15 rakudohudson joined #parrot
03:18 * kid51 must sleep
03:18 purl $kid51->sleep(8 * 3600);
03:28 * rg must sleep, too
03:28 Khisanth joined #parrot
03:30 mikehh what happened to dalek
03:32 dalek parrot: r37085 | coke++ | failed to fetch changeset:
03:32 dalek parrot: Update harness testing to account for mapping of harness options to
03:32 dalek parrot: actual parrot options. (TT #394)
03:32 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37085/
03:33 DietCoke joined #parrot
03:42 janus joined #parrot
03:49 HG` joined #parrot
03:54 Coke doing a bisect over a range of commits that involve deleting lots of directories sucks.
03:55 japhb joined #parrot
03:58 * Coke finds a good rev for bisecting #390
04:35 tetragon joined #parrot
04:59 Tene joined #parrot
05:12 masak joined #parrot
06:06 cotto trac++
06:30 Theory joined #parrot
06:31 Ademan joined #parrot
07:05 uniejo joined #parrot
07:16 slavorgn joined #parrot
07:29 Ademan joined #parrot
07:54 riffraff joined #parrot
08:26 dalek parrot: r37086 | fperrad++ | trunk/lib/Parrot/Configure/Compiler.pm:
08:26 dalek parrot: [makefile] use simply expanded variable ':=' only with gmake (see TT #382)
08:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37086/
08:40 Nom joined #parrot
08:48 rblackwe_ joined #parrot
09:20 bacek joined #parrot
09:43 dalek parrot: r37087 | fperrad++ | trunk (2 files):
09:43 dalek parrot: [rand] apply a patch from TT #392 (fix on 64bit platform)
09:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37087/
10:03 dalek parrot: r37088 | fperrad++ | trunk:
10:03 dalek parrot: svn:ignore pirc
10:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37088/
10:28 dalek rakudo: e2ee4c7 | (Moritz Lenz)++ | src/ (2 files):
10:28 dalek rakudo: remove trailing spaces
10:28 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​2ee4c79e2604fbcd02cab77fd209aac5ba0c311
10:28 shorten dalek's url is at http://xrl.us/beh5j6
10:34 namenlos joined #parrot
10:34 dalek parrot: r37089 | fperrad++ | trunk/config/gen/makefiles/root.in:
10:34 dalek parrot: [install] set *nix rights after a copy
10:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37089/
10:51 cotto That commit seems to make some unwarrantedly unixy assumptions.
10:59 cybertom joined #parrot
11:05 cybertom left #parrot
11:32 nopaste "bacek" at 123.243.38.218 pasted "string.pmc.vcs" (16 lines) at http://nopaste.snit.ch/15760
11:32 bacek This is fix for memory leak in string.pmc
11:50 kid51 joined #parrot
11:54 bacek ok. My attempt was incorrect. But why we need copy of string here? Isn't s->strstart enough here?
12:22 gryphon joined #parrot
12:33 rg1 joined #parrot
13:06 tetragon joined #parrot
13:23 Coke cotto: CHMOD is probably extutils.
13:23 Coke which I would expect to DTRT.
13:40 Coke bacek: I don't know the context of your question, but in general, no, strstart isn't necessarily a valid string.
13:40 Coke valid c-string, that is.
13:57 dalek parrot: r37090 | fperrad++ | trunk (2 files):
13:57 dalek parrot: [install] install install_config.fpmc instead of runtime/parrot/include/config.fpmc
13:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37090/
14:04 Tene joined #parrot
14:06 Whiteknight joined #parrot
14:20 jan joined #parrot
14:22 rg1 cotto: that commit must be only temporary anyway
14:39 dalek parrot: r37091 | fperrad++ | trunk (5 files):
14:39 dalek parrot: [install] runtime/parrot/library/config.pir is now generated, and can work on installed tree
14:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37091/
14:43 dalek parrot: r37092 | fperrad++ | trunk/config/gen/makefiles/root.in:
14:43 dalek parrot: [install] build the correct installable_pbc_to_exe (see TT #345), and fix dependencies
14:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37092/
14:46 jan joined #parrot
15:12 alvar joined #parrot
15:42 khatar joined #parrot
15:45 dalek parrot: r37093 | rurban++ | trunk/MANIFEST.generated:
15:45 dalek parrot: [install] MANIFEST fixes
15:45 dalek parrot: - add missing parrot_debugger
15:45 dalek parrot: - delete old pdb, pirc
15:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37093/
15:47 cas joined #parrot
15:49 NotFound bacek: What memory leak?
15:49 purl i guess memory leak is http://blogs.sun.com/roller/pag​e/kto?entry=the_art_of_leaking or http://blog.jrock.us/categories/Catalyst/2007/9/2
15:49 jrockway wow, that is a terrible link
15:50 particle1 joined #parrot
15:50 jrockway purl, memory leak?
15:50 purl i guess memory leak is http://blogs.sun.com/roller/pag​e/kto?entry=the_art_of_leaking or http://blog.jrock.us/articles/P​lugging%20a%20leaky%20whale.pod
15:50 jrockway fixed ;)
15:50 * jrockway un-delurks
15:53 dalek parrot: r37094 | fperrad++ | trunk/config/gen (2 files):
15:53 dalek joined #parrot
16:07 khatar joined #parrot
16:10 davidfetter joined #parrot
16:25 khatar joined #parrot
16:28 Whiteknight_ joined #parrot
16:35 dalek parrot: r37095 | NotFound++ | trunk/src/pmc/string.pmc:
16:35 dalek parrot: [pmc] Fix String.set_string_native
16:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37095/
16:47 dalek rakudo: 688f9a2 | pmichaud++ |  (3 files):
16:47 dalek rakudo: Modernizing some code. Eliminated globals from Configure.pl.  Error checking on file closes.
16:47 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​88f9a2f8626c893b529994ed4c241d12a63e6ee
16:47 shorten dalek's url is at http://xrl.us/beh6hg
16:48 dalek parrot: r37096 | NotFound++ | trunk/examples/pir/interlangs.bas:
16:48 dalek parrot: [examples] fix interlang.bas instructions, PacoLinux++
16:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37096/
16:48 Patterner joined #parrot
16:53 Khisanth joined #parrot
17:00 dalek parrot: r37097 | NotFound++ | trunk/examples/pir (2 files):
17:01 dalek parrot: [examples] fix interlang.bas and interlang.pir instructions, PacoLinux++
17:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37097/
17:14 dalek rakudo: 868c638 | bacek++ | build/gen_metaop_pir.pl:
17:14 dalek rakudo: Implement [Rop]
17:14 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​68c63865dcaa8a7281aa922fcf1ba1652eaee30
17:14 shorten dalek's url is at http://xrl.us/beh6k6
17:40 pmichaud #ps in 50
17:44 particle1 joined #parrot
17:45 dalek rakudo: c08b9bd | pmichaud++ | docs/spectest-progress.csv:
17:45 dalek rakudo: spectest-progress.csv update: 315 files, 7087 passing, 0 failing
17:45 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​08b9bd36a68de80abf8b61d41838a3b2a59b583
17:45 shorten dalek's url is at http://xrl.us/beh6qa
18:07 barney joined #parrot
18:11 Psyche^ joined #parrot
18:12 dalek parrot: r37098 | fperrad++ | trunk/config/gen/makefiles/root.in:
18:12 dalek parrot: [build] partial revert of r37016, please don't introduce dependents in inference rule. NOT SUPPORTED by all make.
18:12 dalek parrot: Previous r37040, fix only MSVC nmake (inference rule cannot have dependents).
18:12 dalek parrot: BSD make has similar issue (see TT #382).
18:13 dalek parrot: Apply patch from rg++.
18:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37098/
18:25 dalek parrot: r37099 | Util++ | trunk (32 files):
18:25 dalek parrot: [cage] (TT #397) PDD07 enforcement for Parrot_str_not_equal(foo,bar)==0
18:25 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37099/
18:27 allison joined #parrot
18:31 rurban joined #parrot
18:47 davidfetter rurban, ping
18:48 davidfetter oops. nm. let's wait until after parrotsketch
18:49 kj joined #parrot
18:53 Tene_ joined #parrot
18:55 davidfetter what's the authoritative scm? i'm getting wacky troubles with building make rpm from the git repo
19:16 Theory joined #parrot
19:19 Whiteknight joined #parrot
19:23 rurban allison: cygwin trunk builds fine, esp dynpmc and dynoplibs
19:24 mikehh joined #parrot
19:25 allison rurban: okay, great
19:37 estrabd joined #parrot
19:54 dalek pipp: b9baec4 | (Bernhard Schmalhofer)++ | t/php/type.t:
19:54 dalek pipp: Pipp::Test doesn't support $TODO.
19:54 dalek pipp: review: http://github.com/bschmalhofer/pipp/commit​/b9baec4fc44aa65c7a3238c7f84f834ad5dcd106
19:54 shorten dalek's url is at http://xrl.us/beh7b6
19:55 Util davidfetter: the authoritative repo is git://github.com/rakudo/rakudo.git , as described in Moritz's post  http://perlgeek.de/blog-en/pe​rl-6/where-rakudo-lives.html .
19:55 Util As evidence, see also http://github.com/rakudo/rakudo/ , which shows the official "Public Clone URL".
19:55 Util In addition to the two methods described by Moritz, a third method has been added. Clone Rakudo, then `perl Configure.pl --gen-parrot`. This will auto-download-and-build the version of Parrot that is *known* to work with Rakudo.
19:56 Coke (third method) - that's the recommended method.
19:56 davidfetter Util, for parrot, too?
19:57 Util Do you mean "what is the authoritative SCM for Parrot"?
19:58 Util If so, then `svn co https://svn.parrot.org/parrot/trunk/ parrot`
20:03 Coke left #parrot
20:07 dalek pipp: 1ae73de | (Bernhard Schmalhofer)++ | t/php/relops.t:
20:07 dalek pipp: Parrot::Config might not be available
20:07 dalek pipp: review: http://github.com/bschmalhofer/pipp/commit​/1ae73dece050dca3193a87ae8b7644810a87a82e
20:07 shorten dalek's url is at http://xrl.us/beh7ds
20:08 nopaste "rurban" at 93.210.224.72 pasted "support_policy" (41 lines) at http://nopaste.snit.ch/15762
20:10 pmichaud rurban: except I really want to avoid the term "milestone release" as used in support_policy.pod
20:10 rurban B<deprecation point> is bettrr?
20:14 pmichaud rurban: no, according to #parrotsketch, it's now "stable release"
20:14 Infinoid allison: You've answered my website questions, thanks.
20:18 allison Infinoid: okay
20:18 allison Infinoid: I was going to give you a list of redirects, but I think they are mainly clear from comparing the document titles of the two sites
20:20 nopaste "rurban" at 93.210.224.72 pasted "support_policy #2" (41 lines) at http://nopaste.snit.ch/15763
20:27 Infinoid allison: I've just been working through a list of pages on parrotcode.org and verifying they exist on parrot.org.  Once I got rid of the irc logs, the list isn't very big.  But if you have a better list, I can look at it
20:43 allison Infinoid: that sounds like an ideal list
20:44 cotto Util, I'll look at TT #398 later today.
20:47 Util Thanks, cotto
20:48 baest joined #parrot
21:12 pmichaud looking at TT #398 now.  Looks like a couple of errors were introduced since the original.
21:12 pmichaud Agreed that the indentation in the original was incorrect.
21:17 Util Thanks, pmichaud
21:25 rdice joined #parrot
21:26 donaldh joined #parrot
21:36 chromatic joined #parrot
21:37 chromatic Fixing bugs and releasing a new version of the January release when it's June is *stupid* and *wrong* and *expensive*.
21:37 chromatic We already have a perfectly good way to release a new version of Parrot for people to use.
21:37 chromatic We've done it for more than two years now.
21:38 rurban the term "stable release" in the support_policy?
21:39 chromatic Making any release more magical than any other release.
21:39 rurban but .0 and .6 should be makred as deprecation points somehow
21:39 chromatic The entire *point* of using time-based releases is that no release is more magical than any other release.
21:39 chromatic I can point to an entire shelf of books in my library which all say the same thing.
21:39 allison chromatic: we have to face the fact that we have users. Either that, or we have to face the fact that we'll never have users. I prefer the former.
21:40 chromatic allison, I'm not going to debate non-sequiturs.
21:40 pmichaud the thought I had while walking today is that we should reserve the release numbers for our special releases, if we're to have them.
21:40 rurban so the deprecation policy needs to be changed in the text? from future 6 releases to 2 as now?
21:40 allison if we have users, then we have to release bug and security fixes for them
21:40 pmichaud thus, what allison calls "development releases" we simply identify by month.
21:40 dalek parrot: r37100 | pmichaud++ | trunk/src/sub.c:
21:40 dalek parrot: [core]: Clean up code format issues identified in TT #398 (Util++)
21:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37100/
21:40 chromatic We *do* release bug and security fixes.
21:41 allison but, we don't have to release bug and security fixes for every monthly release
21:41 chromatic We have a damn fine release policy to release bug and security fixes.
21:41 pmichaud the other "stables releases" we give numbers like 1.0, 1.5, 2.0, 2.5, etc.
21:41 allison ah, right this is back to the question of "how long to we support a release"
21:41 pmichaud That eliminates a lot of the confusion surrounding 1.1, 1.2, 1.3, etc.
21:41 allison nothing to do with what we call them
21:41 chromatic No, that's not it at all.
21:42 chromatic The real question is "Why bother releasing software we tell people not to use?"
21:42 chromatic I prefer to keep exercises in masturbation out of my software devevelopment processes.
21:42 allison my original proposal was to stop the monthly releases, but you and others convinced me otherwise
21:42 chromatic Because monthly releases *work*.
21:43 particle1 monthly user upgrades don't.
21:43 chromatic If our software gets better every month, it's worth releasing every month.
21:43 allison I do think it's valuable for training new release managers and for a bugfix cycle
21:43 allison chromatic: monthly releases work for *us*, for the developers, they don't work for users
21:43 chromatic Users don't *have* to upgrade monthly.
21:43 chromatic Users who *want* to upgrade monthly have that option.
21:43 allison right, so we have to tell them which versions to upgrade to
21:44 particle1 users *have* to get critical security fixes, without deprecations.
21:44 allison and which versions we'll be providing bug/security fixes for
21:44 particle1 microsoft used to bundle features with bugfixes. that sucked.
21:44 allison we can't afford to provide bug/security fixes to all monthly releases, that would kill us
21:44 chromatic Okay, so you want to predicate the whole release structure around the exceptional possibility that there will be a critical security fix.
21:44 particle1 perl 5.8 hashes.
21:45 chromatic The nice thing about critical security fixes and monthly releases is that you *can* make an exception.
21:45 allison chromatic: what piece of software do you know that has never had a critical bug/security fix?
21:45 particle1 notepad.
21:45 purl notepad is the worst. or a piece of shit or to vi what garlic chicken salad is to a flamethrower.
21:45 chromatic allison, what piece of software do you know that has more critical bug/security fixes than monthly releases?
21:46 allison chromatic: we already said that average users can't upgrade on a monthly cycle, so "use the next monthly" isn't an option for them
21:46 chromatic I'm not fixing ancient bugs for free.
21:46 chromatic I'm not fixing bugs twice, in two different releases, for free.
21:46 chromatic I'm not supporting code that I can't see and don't know even exists.
21:46 chromatic I'm *not* letting you tell volunteers that they have to do that.
21:46 allison chromatic: that's fine, but as a project, we have to support users
21:46 chromatic If you want to do it, fine.
21:47 chromatic See p5p for the inevitable results of *that* decision.
21:47 allison we never tell volunteers that they *have* to do anything
21:47 allison we already had this conversation
21:47 chromatic *What* makes a 1.1 release not worth releasing?
21:47 chromatic Why do we imply it's not stable?
21:47 allison we're not talking about making bug/security releases for 8 year old version of Parrot
21:47 chromatic Do we not have a test suite?
21:48 chromatic Do we not run the test suite?
21:48 chromatic Do we not fix bugs in it?
21:48 allison we're talking about 2 years, tops
21:48 chromatic Do we deliberately have regressions from 1.0?
21:48 allison in an ideal world, that's great, but real software is not like that
21:48 rurban stable is about API decisions, not about bugs
21:49 chromatic You're going to have to be more specific about "real software", because that's a very abstract category.
21:49 allison rurban: yes, that's another important factor
21:49 chromatic Frankly, "real software" doesn't fit in the "stable API" nonsense either.
21:49 allison chromatic: planning our release structure around the idea that we'll never have bugs or security problems is not reasonable
21:49 chromatic That's just another example of magical version number thinking.
21:50 rurban with our super-fast cycles deprecations might  happen too often
21:50 chromatic allison, I already said I'm not interested in debating non-sequiturs.
21:50 chromatic If you think my point is that we'll never have bugs of security problems, then we have a REAL problem communicating.
21:51 allison maybe I misunderstood you, but as far as I know I was only directly answering your statement
21:51 allison try explaining more?
21:52 allison or, perhaps I should ask, what is your point?
21:52 chromatic Maintaining a 1.0 branch is a mistake.
21:52 allison chromatic: well, hopefully we'll never have to create one
21:52 chromatic Backporting the most *critical* of fixes for crashes, data losses, and exploitable security fixes is fine.
21:53 allison hopefully we'll never have critical bug and security fixes
21:53 chromatic Anything else is madness.
21:53 allison but, when we do, we need to have a plan in place for how to handle them
21:53 allison oh, yes, we already agreed it's only critical bug and security fixes that get a 1.0.1 or whatever release
21:53 chromatic We continue to release monthly releases with the most boring, unimaginative, non-magical version numbering scheme imaginable.
21:53 rurban but calling every monthly release "stable" is even more weird then
21:54 chromatic What makes the monthly releases anything *but* stable?
21:54 allison the non-magical numbering has also already been decided
21:54 chromatic Do we wave magnets over our hard drives before releasing them?
21:54 rurban the need to branch it and maintain it
21:54 chromatic We don't branch for releases.  No.  That's nuts.
21:54 allison the monthly releases go on exactly as they have done
21:54 rurban 1.0.1, 1.1.2 ...
21:55 allison 1.1.0 is no different than 0.9.1
21:55 pmichaud I think my point is that it should be.
21:55 chromatic We *don't* suggest that there's any difference in stability between 1.0 and 1.1.
21:55 allison chromatic: that's where the difference enters
21:55 rurban so we should just explain that int the policy document
21:55 chromatic *What* difference?
21:56 pmichaud actually, retract that -- I'm deciding to completely stay out of this topic.
21:56 allison 1.0 we offer as the preferred release for people who can't upgrade to monthly releases, and also as a point where we'll do bug/security fixes
21:56 chromatic NO.
21:57 allison 1.1 we won't do bug/security fixes on
21:57 chromatic No bug fixes.
21:57 rg1 the big difference i see are deprecations. you can't drop in a newer release and expect older pbc to work.
21:57 allison for bug/security fixes to 1.1, you upgrade to 1.2
21:57 allison or 1.3, or...
21:57 chromatic People are not going to understand that magical numbering system.
21:57 chromatic No magical numbers.  Please.
21:58 allison rg1: yes, that's also part of making it possible for users to only upgrade to January/July
21:58 rurban no immediate out-of-monthly bugfix release for *critical* of fixes for crashes, data losses, and exploitable security fixes?
21:58 chromatic Oh look, another strawman.
21:58 chromatic Yay.  It's *FUN* to be misquoted.
21:58 allison chromatic: the current numbering scheme was chosen exactly because you wanted no magical numbers
21:58 rurban sorry.
21:58 allison chromatic: is there a less magical scheme we could pick?
21:58 chromatic And yet, 1.0 and 1.6 *are* magical version numbers.
21:59 allison rurban: I mean there will be no 1.1.1, 1.2.1, etc
21:59 allison 1.0 and 2.0 are magical
22:00 chromatic What's magical about them?
22:00 rurban so use only x.0 as magical number and set milestones to any arbitray number?
22:00 allison and pretty obvious to anyone
22:00 chromatic If there's magic, I want to be able to *measure* the magic.
22:00 chromatic I don't want it to be magic, even.  I want it to be scientific.
22:00 chromatic I want it to be so utterly boring and reproducable, it's the opposite of magic.
22:00 rurban and major deprecations as now, not every 6 months?
22:00 allison it's deprecation cycles and whether they get bug/security fixes, that's the cold, hard difference
22:01 chromatic Okay.  Good.  We can *measure* that.
22:01 chromatic I mean, the deprecation points.
22:01 allison yes, the january/july releases
22:01 NotFound Are you debating about numbers, or about the concept of having 1 or 2 releases a year that have bug fixes?
22:02 chromatic I'm debating the idea that no one in their right minds would ever possibly conceive of using our crappy, broken down, don't even work monthly unstable releases.
22:02 allison NotFound: that's a very good question, I'm still not clear on where the difference of opinion lies
22:02 allison (we keep running into points where we violently agree)
22:03 allison chromatic: production users shouldn't use the monthly releases
22:03 allison chromatic: developers might
22:03 Whiteknight joined #parrot
22:03 chromatic What kind of production users of a virtual machine and compiler toolkit aren't developers?
22:04 NotFound So the point is to not having monthly releases with version numbers, just svn release numbers?
22:04 allison chromatic: it sounds like Rakudo will be tracking arbitrary points on trunk, but some language developers will track monthly releases
22:04 chromatic End-users of *Parrot* will use whichever version their *language* requires.
22:04 allison chromatic: if the only people who ever use parrot is compiler-developers, we're dead
22:05 allison chromatic: production users are people who have parrot installed running production software
22:05 chromatic Raw Parrot, with no other constraints on what has to run with Parrot.  Running production software written in PIR, I assume.
22:05 chromatic Talk about a DarkPAN.
22:05 allison chromatic: and yes, what they'll install is "parrot-php" or something like that
22:06 chromatic Seems to me the constraint there is which version of Parrot that "parrot-php" supports.
22:06 allison but, parrot has to provide the sane points for the languages to support
22:06 NotFound I disagree. We talk a lot about language interoperability, we can't say that you just need to care about the version required for just one language.
22:06 allison because you need to synchronize between languages
22:07 particle1 chromatic: if a parrot instance isn't shared across high-level languages, what is the point of using parrot?
22:07 pmichaud Rakudo tracks arbitrary points on trunk because the monthly release points (and soon to be longer six-monthly points) aren't sufficiently advanced for us to use.
22:07 chromatic Okay.  In other words, if you want to run N languages on Parrot, the support policy of the Parrot developers is that N language developers have to support the most recent biannual release *and* the most recent monthly release?
22:07 allison particularly, if someone goes to ubuntu and types "apt-get install parrot-python" and then does parrot-php, both have to work on the installed parrot packages
22:08 allison chromatic: no, they only have to support the most recent biannual release
22:08 chromatic If Ubuntu decides to skip the most recent biannual release, the Parrot support policy makes Parrot-using developers support the most recent biannual release, the Ubunut-supported biannual release, and the monthly stable release?
22:08 allison chromatic: that right there is the fundamental reason for adding biannual releases
22:08 chromatic allison, they have to track the latest monthly release if they have any hope of keeping up to date with the upcoming biannual release.
22:08 allison what? I don't understand taht last question?
22:09 NotFound If ubuntu or any other doesn't upgrade, they must assume that they must fix his own problems.
22:09 allison chromatic: they don't have to, they can wait for the biannual release, make the necessary changes, and then release their new version
22:09 chromatic NotFound, I agree, but that's not the impression allison gave me last week.
22:09 chromatic Why can't they do the same for monthly releases?
22:09 pmichaud (and hope that the biannual release hasn't broken anything)
22:10 chromatic And hope that users didn't upgrade to the biannual release.
22:10 allison chromatic: because then they spend all their time updating to monthly releases
22:10 allison chromatic: it's slowing down our language developers
22:10 chromatic As opposed to all their time updating to biannual releases.
22:10 allison yes, we had that conversation too
22:11 allison I know you believe it's easier to constantly update your software for the underlying interpreter
22:11 Tene_ So if I want my language packaged in ubuntu, I have to track parrot-biannual?
22:11 chromatic Predicated on the assumption that the amount of work I can do in one six month chunk is about the same as the amount of work I can do in six one month chunks.
22:11 pmichaud Tene_: or package your own copy of parrot.
22:11 allison but it's horribly discouraging to have your language be broken every time to have a Saturday to work on it
22:11 chromatic Which, as it turns out, is just about the only assumption you can make for software project management.
22:12 chromatic Let's do an experiment then.
22:12 chromatic I'll pick a bug in Parrot.
22:12 allison the cost of context switching comes into play
22:12 chromatic I'll pick two ranges of commits.
22:12 chromatic One has 20,000 commits.
22:13 chromatic One has 200 commits.
22:13 chromatic We'll see who finds the bug more easily with a bisect.
22:13 chromatic Actually, let's make the numbers more realistic.
22:13 chromatic Change that to 9000 and 1300.
22:13 purl chromatic: that doesn't look right
22:13 allison but, even if it is the same overall amount of time, spending two saturdays a year updating for the current version is less discouraging than spending the first several hours of every saturday
22:14 chromatic How do you know we'll break every language every Saturday?
22:14 pmichaud I'm not sure I agree with allison's point (more)
22:14 chromatic Do we not mark deprecations early and often?
22:14 allison chromatic: because we already are, and we're not planning to slow the pace of development
22:15 pmichaud Spending a long slog Saturday going through and trying to figure out all of the things that aren't working (and wondering if there are odd interactions) is much more stressful than doing it periodically in small batches.  See "branch+merge often".
22:16 allison pmichaud: which is one of the reasons we still have the monthly releases
22:16 chromatic We just discourage people from using them, because they're not stable.
22:16 allison pmichaud: so developers can track them if they want to
22:16 allison chromatic: is it only the name that bothers you?
22:16 pmichaud so a language developer still needs to target the monthly releases.  and maintain two release targets -- one for the monthlies, and one for the stables.
22:17 allison pmichaud: they can choose
22:17 chromatic And the most recent version in Ubuntu.
22:17 allison they don't have to track anything except the most recent packaged version (on whatever OS)
22:18 pmichaud oh, language implementations don't have to issues bugfix backports?
22:18 pmichaud *issue
22:18 allison each language decides on its own support policy
22:18 allison but, the idea of bug/security fix releases is that they don't change the interface at all
22:19 chromatic Except insofar as our support policy forces their hand.
22:19 NotFound Or the packagers, that may not be the same people as the developers.
22:19 allison so, parrot making a bug/security release shouldn't affect languages targeting that release
22:20 allison (I won't go so far as to say "absolutely must not" because I can't predict the future, but that's the idea)
22:20 chromatic See also "The myth of bugfixes and stable APIs"
22:20 Tene_ Okay, for a relatively more realistic example, it looks like I've made one bugfix related to Parrot deprecations in about the past six months.
22:20 Tene_ removing the n_* opcodes
22:21 pmichaud no, but languages having bug/security fixes will have to target both whatever release they're tracking and whatever the current "stable" version of Parrot is out there.
22:21 pmichaud Tene_: I've made quite a few.
22:21 allison Tene: is that a bugfix?
22:21 allison Tene: sounds like a deprecation
22:21 Tene_ pmichaud: you'v ebeen committing to cardinal?
22:21 Tene_ allison: that's right.
22:22 pmichaud Tene_: oh, sorry, I didn't realize you were limiting to cardinal.
22:22 allison Tene: okay, a *language* failure fix, makes sense
22:22 pmichaud I was referring to pct/rakudo/...
22:22 Tene_ ah
22:22 Tene_ pmichaud: You're right.  I thought that I mentioned cardinal, but my writing is bad today.
22:23 allison pmichaud: yes, a language will have to make the choice of what to track
22:23 pmichaud and some changes to Parrot we still haven't recovered from, such as the mmd changes.
22:24 chromatic There's only one kind of change we can accurately predict anyway.
22:24 allison pmichaud: some lessons learned with mmd, io went smoother because of it
22:24 chromatic We *can't* predict how much work it is to upgrade to a monthly release.
22:24 allison yes
22:24 allison and, we can't dictate the upgrade policy of various language
22:24 chromatic We *can't* predict how much work it is to upgrade to a biannual release (except that it's several times the amount of work to upgrade to a monthly release, minus any resolved churn).
22:25 allison yes
22:25 chromatic We can only predict *deprecations*, because we explicitly *plan* deprecations.
22:25 pmichaud allison: I'm glad io went smoother -- I'm not arguing against mmd here, I'm simply noting that some things we could do with Parrot before we still cannot do today.
22:25 NotFound And languages cannot dictate policy of his packagers, also.
22:25 chromatic Yeah, but packagers can't dictate policy of the project.  Get on the trolley.  It's the 21st century.  Please work with upstream.  etc
22:26 allison pmichaud: I wan't aware of that. after 1.0 could use to sit down and work through those, and make sure you get back up to the same level
22:26 allison chromatic: yes, we can plan deprecations
22:26 allison all we're doing here is giving people more options
22:26 allison they have the option of continuing to upgrade monthly
22:27 chromatic But our language *discourages* that.
22:27 chromatic I mean our jargon.
22:27 allison they will also have the option of upgrading once or twice a year, and we'll give them good points to do it
22:28 Tene_ but if we're telling distros to only ship our biannual releases...
22:28 chromatic Exactly.
22:28 allison the current choice of jargon discourages it, because the default case for a green new user or production user is the once or twice a year option
22:28 NotFound There is no magic in numbers and there is also no magic in the word 'stable'. If we don't like the connotations of such word, we can just pick another word.
22:29 allison more experienced Parrot developers understand what the monthly releases are, and understand the plusses and minuses of tracking them
22:29 chromatic There is a lot of magic in the word "stable".  Out of twelve releases in a year, only two of them are "stable".  What does that imply about the other ten?
22:29 Infinoid allison: I still don't get that.  If I am a new user who wanted to try out parrot, and see that there's a 1.0 and a 1.1, I'm gonna choose 1.1.
22:29 allison that they're intended for developers
22:29 chromatic Really.
22:29 davidfetter yeah
22:29 chromatic The opposite of "stable" is "intended for developers"?
22:29 allison stable and development
22:30 chromatic okay then.
22:30 chromatic We're back to my question.  What practical attributes of the "stable" releases can we measure precisely?
22:30 allison we're not going the debian route of having an "unstable" release which is what most people are expected to use if they want to get any work done
22:30 chromatic That's because Debian doesn't have regular releases.
22:30 NotFound I think the meaning has been said a lot of time. In the 'magic' releases we'll do some worg on fixing critical things.
22:31 szbalint let's call it sid :)
22:31 chromatic We won't fix critical things in the "development" releases?  We won't run our tests?  We won't add tests?
22:31 Tene_ If the big point of the magic releases is ubuntu, has anyone talked to ubuntu to find out what they will actually ship?
22:31 allison chromatic: and, to repeat myself: a stable release is about deprecation points and bug/security fixes
22:31 chromatic We can predict what gets fixed and when?
22:31 chromatic What kind of bugs get fixed in "stable" releases?
22:31 allison Tene: they won't ship monthlies
22:32 chromatic Why won't Ubuntu ship monthlies?
22:32 Infinoid They will, if an HLL they want to ship depends on some feature we've added since the last stable
22:32 Tene_ allison: because they happen every month?  Do they just refuse to ship software released that frequently?
22:32 allison chromatic: because we turn around new packages faster than they can sponsor and include them, so we end up stuck at 0.4
22:33 Tene_ Can weuWould it be possible to get someone involved in the ubuntu process to facilitate that?
22:33 chromatic I'm not sure it's good policy to let poor engineering dictate our support policy.
22:33 allison chromatic: we're not, Ubuntu is a rabbit trail we got off on
22:33 chromatic You brought it up.
22:34 allison chromatic: as an example of packaging, yes
22:34 chromatic I believe you said something like "Users will get stuck with 1.0 in Ubuntu and we have to support them."
22:34 chromatic I believe I responded with something like "Ubuntu will have to support them, yes."
22:34 allison chromatic: do you mean our in-person conversation last week?
22:34 chromatic Yes.
22:34 allison it was a rabbit trail there too
22:34 Tene_ Presumably ubuntu won't ship any new versions of languages either
22:35 nopaste "rurban" at 93.210.224.72 pasted "support_policy #3" (27 lines) at http://nopaste.snit.ch/15766
22:35 allison Tene: yes, they only do package updates twice a year
22:35 ron joined #parrot
22:35 chromatic Back to my question again.  What practical attributes of the "stable" releases can we measure precisely?
22:35 rg so you presume that the people who want to use parrot now won't be able to install it from a tar file but have to rely on a package in their os?
22:36 Tene_ chromatic: isn't it mainly about deprecation schedule?
22:36 allison to clarify/resolve: chromatic, can we pin down exactly what you're debating?
22:36 chromatic Tene_, I think so too.
22:36 Infinoid rg: most of the people who don't have a clue or care what parrot is will likely be installing it as a package dependency, yes
22:36 NotFound rg: not at alll
22:36 allison chromatic: you're not debating the 1.0, 1.1, 1.2, 1.3... release numbering?
22:37 NotFound rg: If they want, they can do it. But a lot of people just don't want.
22:37 chromatic No.  I'm debating the magic "stable" level and the notion of backporting bugfixes.
22:37 allison chromatic: you're not debating changing our deprecation cycle to twice per year?
22:37 rurban I think we agreed to remove the word stable from the pod
22:37 chromatic I think a six month deprecation cycle is fine.
22:38 allison chromatic: you're not debating that we can't afford to make bug/security fixes to every monthly release, so we're only doing them on the same cycle as the deprecation cycle?
22:38 chromatic I want to know precisely you mean by a "bug fix" to a "stable" release?
22:38 allison skip the term "stable", I haven't gotten there yet
22:38 chromatic Except I want to write that in an English sentence.
22:38 allison chromatic: critical bug and security fixes made to January/July releases
22:39 chromatic What makes a bug fix "critical"?
22:39 Tene_ allison: "critical bug"?
22:39 allison chromatic: there's no way to define that in advance, but it generally means "if it doesn't cause a segfault or allow a server to be hacked, it's not backported"
22:40 allison feature flaws, or unimplemented specs never get backported
22:40 NotFound The common mean may be: a lot of people want it to be fixed, and we agree and work on it.
22:40 chromatic Anything other than a segfault or an exploitable flaw, you either backport the patch yourself or upgrade to a monthly release?
22:41 chromatic (or wait for the next biannual release)
22:41 allison yes
22:41 allison (with the option to evaluate each case as it comes)
22:41 Infinoid that leaves a big range of bugs that HLLs have to deal with, with no help from us
22:41 allison that is, we're not establishing a law never to be broken, we're establishing a set of guidelines
22:42 chromatic Presumably we can fix that big range of bugs in monthly releases.
22:42 Tene_ Are we going to make a guarantee and policy of doing that for all segfaults and security issues, or is that just the release that we agree to standardize on backporting to if someone decides to volunteer?
22:42 allison Infinoid: yes, what chromatic says, and also 6 months isn't really a terribly long time to wait for a new feature
22:42 Infinoid I hope so.  I just don't like the idea of explicitly treating those releases as abandonware.
22:42 NotFound I hope that most HLL will not always be walking on thin ice.
22:42 Infinoid It's more a matter of perception than anything else
22:43 allison Tene: I would steer clear of offering "guarantees" for anything
22:43 allison Tene: that's what a support contract is for
22:43 chromatic I'm comfortable with the perception that the best way to work with Parrot is to target the monthlies.
22:43 allison chromatic: we didn't get there yet
22:43 Tene_ if ubuntu isn't going to be releasing updates of languages, no language will want to track biannuals either
22:43 Tene_ right?
22:43 purl i heard right was aways right?
22:44 chromatic Let's assume Ubuntu chooses some broken upgrade policy and leave that their problem for now.
22:44 allison Tene: hum? the idea is that the biannuals will be packaged
22:44 allison so, languages will track biannuals
22:44 allison and language packages will also track biannuals
22:45 NotFound Tene_: we can't predict what people will do, we can clearly explains our plans to let them make informed choices.
22:45 NotFound That includes explain that our plans are not set in stone.
22:45 allison chromatic: so, wrapping up one point, we agree on bug/security fixes for the January/July releases?
22:45 chromatic Only if you call them "super critical bug/security fixes".
22:46 chromatic I am not kidding about that.
22:46 allison super happy dev farm chocolate fun-fun
22:46 chromatic That's going to be easy to localize for Japan, but I really want to avoid the impression that we'll fix anything but serious crasher bugs there.
22:47 chromatic I think we agree on that policy.  I want us to be specific about what "bug fix" means there.
22:47 allison As and editor, I'll remove redundant adjectives. And, we have no other kind of bug/security fixes, so no extra adjectives.
22:47 NotFound "Godzilla fixes"
22:47 allison chromatic: you want law, we're not making law, we're making guidlines for future desisions
22:47 cotto mothra-sized or bigger
22:47 chromatic I don't want law.
22:47 chromatic I don't want ambiguity.
22:48 allison life is ambiguity
22:48 chromatic "We'll fix bugs for this release" could mean many, many things.
22:48 particle1 and i have the tee-shirt.
22:48 allison chromatic: yes, and it doesn't matter what we call it, we'll still have to explain it
22:49 chromatic Then why not explain it in the support policy document with an adjective?
22:49 rg can you call it "security bug fixes"?
22:49 chromatic I'll donate another nickel to the Parrot Foundation to pay for the increased storage and bandwidth costs for the extra couple of words.
22:49 allison chromatic: it just begs more questions
22:49 NotFound And even if we are cristal clean in the explanation, someone misinterpret it, on purpose or not.
22:49 chromatic Right.
22:50 chromatic Because "serious crasher bug fix" is exactly as ambiguous as "bug fix".
22:50 * davidfetter knows he's late to the party, but how about 1.0, 1.5RC1, 1.5RC2, 1.5RC3, 1.5RC4, 1.5RC5, 1.5, .... ?
22:50 chromatic English has noun phrases for a reason.  Anyone care to speculate why?
22:50 allison okay, let the record show that we disagree on whether we should call them "bug/security fixes" or "super critical bug/security fixes"
22:50 allison moving on
22:50 chromatic davidfetter, because we're adults, and adults don't need release candidates if they know what they're doing.
22:50 NotFound "We'll fix it if you send us enough cookies"
22:50 particle1 chromatic: your nickels are no good here.
22:51 particle1 donate time.
22:51 davidfetter adults are not as common as i'd wish. not in software, not anywhere else :P
22:51 allison I agree with chromatic on avoiding "release candidates", though I wouldn't state it quite like that
22:51 chromatic It doesn't have to be "super critical", but some explanation that we are not fixing "This doesn't work the way I expect!" and "Can you move this widget one pixel to the right?" bug fixes would be nice.
22:51 chromatic davidfetter, that's why there are so many release candidates.
22:52 chromatic It's a great way to say "I feel guilty for not releasing software, and please test it, but I'm not sure it works."
22:52 Infinoid davidfetter: I suggested "monthly snapshot" earlier, but apparently even though these releases are throwaway, we don't want them to look throwaway.  Except that we do.  So I'm confused.
22:52 allison chromatic: agreed on including some language that explains what we mean by bug/security fixes (even though people won't read it and will be confused anyway)
22:52 allison Infinoid: we're not there yet
22:52 chromatic I don't care about people who don't read the documentation.  Darwin will claim them soon enough.
22:53 allison so next piece
22:53 davidfetter there's a difference between "rtfm" and "major POLA violation"
22:53 davidfetter and tbh, "releases" that aren't actually, are the latter
22:53 allison chromatic: you do debate which releases should be the "default" for people to use, yes?
22:53 allison chromatic: I say biannuals, you say monthlies
22:53 chromatic Yes.
22:54 allison I believe we're talking about different audiences.
22:54 davidfetter the developer audience doesn't need a release number
22:54 chromatic Perhaps.
22:54 NotFound People will always ask for fix to anything they don't like. But as my mom says, against the vice of demanding there is the virtue of denying.
22:55 allison or, are you suggesting that production users, say, a development house running mod_pipp for their website, should upgrade to monthly releases?
22:55 chromatic I think end-users, users of HLLs targeting Parrot, will use whatever version their HLL recommends.
22:55 NotFound (Not sure about my translation to english)
22:55 chromatic I do think production users should upgrade to monthlies.
22:55 chromatic They have the option not to.
22:55 allison chromatic: okay, that's where we disagree
22:55 chromatic but if I were running a development house, they would.
22:55 allison I would say they shouldn't upgrade to monthlies, but have the option of doing it if they want to
22:56 allison it's a fine semantic distinction
22:56 chromatic I can't force them to upgrade.  I can recommend that they do.
22:56 Tene_ why should they avoid monthlies?
22:56 chromatic We *can* encourage them to do so with our bug fixing policies.
22:56 Infinoid If monthlies will contain fixes that the stable point releases won't, just because the bug caused an exception instead of a segfault (or some similar policy detail), I'd definitely use the monthlies.
22:57 chromatic Me too.
22:57 allison Tene: because I've worked in production dev shops, and selling a manager on the idea that they need to spend a week of their team's time each month upgrading all their software isn't going to fly
22:57 chromatic I thought we had agreed to avoid strawmen.
22:57 allison chromatic: I don't see how that's a strawman
22:58 chromatic I've worked in production dev shops, and selling a manager on the idea that they have to strip naked, do rain dances, and make their own salt water taffy from their tears each time they want to upgrade all of their software isn't going to fly anywhere but on Wall Street.
22:58 allison chromatic: that's a strawman :)
22:58 NotFound I think avoiding a segfault is not just a policy detail.
22:58 chromatic So is "OMG!  IT TAKEZ A WEEK TO UPGRADESZ! NOOOOES!"
22:59 allison chromatic: actually, I think that's a non-sequitur
22:59 chromatic Okay, well I thought we agreed to avoid those too.
22:59 Infinoid NotFound: the line needs to be drawn somewhere for whether it qualifies as making a "bugfix release" to a supported version, and fixes for lesser bugs are still useful.
22:59 NotFound The virtual machine must not  segfault. If it does, is a serious bug.
22:59 allison hey, I'm not the one who brought up naked taffy rain dances :)
22:59 chromatic You brought up the FUD that it takes a week per month to upgrade to a monthly.
23:00 Infinoid If it takes a week per month, we've seriously failed our deprecation policy
23:00 chromatic Or their shop sucks, in which case we can't help them.
23:00 allison for an expert, no, it won't take that long
23:00 chromatic Did you *measure* it?
23:00 allison it's an estimate
23:00 chromatic Based on?
23:01 Infinoid I thought the idea of having a deprecation policy was to ensure newer versions are a drop-in replacement
23:01 allison let's remove time form it entirely
23:01 pmichaud I would think that a shop running mod_pipp would upgrade based on the mod_pipp upgrade cycle, not the Parrot one.
23:01 allison pmichaud: yup
23:01 chromatic Yeah, they count as HLL users in my mind.
23:02 NotFound You're again forgetting that we talk about language interoprability as one of our goals.
23:02 allison but, we're giving the language developers sane points to synchronize to
23:02 pmichaud I'm not forgetting that at all.
23:02 chromatic Not until 2.0.
23:02 allison as opposed to a free for all where every language synchronizes to a different random monthly release
23:02 pmichaud I'm saying that that decision to upgrade is going to be based on the tools I'm using, not based on Parrot's release cycle.
23:03 allison pmichaud: yes
23:03 NotFound pmichaud: but having each tool based on a different point will not help.
23:03 chromatic If only we had some way of encouraging each language to target a specific point...
23:03 allison where chromatic and I disagree (as I understand it), is what we suggest the tools synchronize to
23:03 pmichaud NotFound: I agree, if each tool takes a different point, that won't help.
23:03 pmichaud (more)
23:03 pmichaud However, I don't think we're going to have to deal with synchronization points until after 2.0, at the earliest.
23:04 NotFound pmichaud: I agree on that
23:04 allison pmichaud: I agree
23:04 allison 1.0 and 1.4 are more practice runs
23:04 allison that is, we won't know where the pain points of synchronizing are until we actually try it a few times
23:04 pmichaud I don't even know who is going to try before 2.0, to be honest.
23:05 allison pmichaud: I'm going to try to get 1.0 into Ubuntu 9.10.
23:05 allison pmichaud: and 'parrot-python' and 'parrot-php'
23:05 pmichaud Unless Parrot gets a lot better about hitting its non-critical milestone targets, it's unlikely that rakudo will be targeting any stable release prior to 2.0, or even attempting to do so.
23:05 NotFound And pirric? ;)
23:05 allison pmichaud: and maybe 'parrot-perl6'
23:06 pmichaud allison: we can certainly package up a parrot-perl6 that represents the state of Rakudo as of Parrot 1.0.  But very few people will want to use it.
23:06 allison pmichaud: how do the milestone targets come into play?
23:06 pmichaud allison: will calling conventions be fixed anytime soon?
23:06 chromatic Or MMD?
23:06 purl i heard MMD was multi-method dispatch
23:06 allison pmichaud: non-critical is supposed to mean... not critical for the release
23:07 chromatic Sure, but some of these features are critical for Rakudo.
23:07 pmichaud I understand that non-critical means non-critical for the release.  That doesn't mean it's not critical for Rakudo.
23:07 allison okay, I don't know what's critical for Rakudo
23:07 allison we don't have a Rakudo milestones list
23:07 pmichaud we have bug reports and feature requests, though.
23:07 pmichaud Those weren't "wishful thinking" -- they're things that we need in order to implement Perl 6.
23:07 allison I don't know what parts of Rakudo are blocking on what parts of Parrot
23:08 chromatic I think what pmichaud means is that "The day after Parrot gets a bugfix or a new feature from this list, Rakudo will start using it."
23:08 pmichaud Rakudo is blocking on calling conventions, such as :lookahead.
23:08 chromatic Waiting six months for that revision to land in a new stable release is not an option.
23:08 pmichaud Rakudo is blocking on pipe I/O, to be able to do qx{}
23:08 allison this sounds like a place we need to synchronize better, any suggestions on how?
23:09 pmichaud Rakudo is blocking on MMD, to be able to subclass the Complex PMC and use it sanely
23:09 allison I have a sense that Rakudo needs things, but when I sit down to work for a day, I don't have any way of prioritizing based on what various languages need
23:09 pmichaud I've asked for these things in the past, and the response has been "oh, we'll do that as part of the {mmd|calling_conventions|io} branch"
23:09 allison since the dev summit, I've been prioritizing based on the milestones
23:09 pmichaud but when the branch finally lands, they aren't there.
23:10 allison but Rakudo needs aren't Parrot milestones
23:10 NotFound I think MMD and subclassing working fine is good for all languages, even pir.
23:10 allison can we make a wiki page?
23:10 pmichaud more to the point, Rakudo needs haven't been *critical* Parrot milestones.
23:10 pmichaud which means they're not likely to make it into the 1.0 release.
23:10 allison "top feature/fix requests from languages"
23:11 pmichaud which means that the 1.0 release isn't likely to be a long-lived target for us.
23:11 pmichaud even the 0.9.1 release wasn't a valid target for us within 24 hours after its release.
23:11 allison pmichaud: yes, for 1.0 it was more important to stabilize the core subsystems
23:11 pmichaud I'm not arguing with the plan, I'm simply saying what the impact is of that plan for Rakudo, and why I don't think the stable releases make much difference yet.
23:12 Infinoid does this prevent Rakudo from making distro packages until we hit 1.4?
23:12 pmichaud Infinoid: Rakudo is already making distro packages.
23:12 allison what I'm taking away from this is that another addition to the January/July releases will be extensive language testing
23:12 pmichaud allison: I did make that point on the mailing list this past week.
23:12 chromatic It's not about language testing.
23:13 Infinoid (test coverage)++
23:13 pmichaud Infinoid: Rakudo is making monthly releases.  It will continue to make monthly releases.  It's very likely that those monthly releases will _not_ be based on Parrot stable releases.
23:13 allison that is, explicitly synchronizing between the various independent language projects
23:13 pmichaud (where "stable release" here means "deprecation point releases")
23:13 pmichaud allison: did you see my message on parrot-dev about needing to add "language build" as a critical task for parrot stable releases?
23:13 allison no
23:14 pmichaud you need to read it and comment.
23:14 allison okay, will do
23:14 allison to summarize here and move on:
23:14 pmichaud this last week we had a situation occur where it would've been possible to have a 1.0 Parrot released that could not be used to build Rakudo.
23:14 allison pmichaud: okay, that would be problematic
23:15 NotFound pmichaud: I think this was a serious parrot problem, not just a rakudo blocker.
23:15 pmichaud I will have to read scrollback -- I'm being summoned loudly to dinner :-|
23:15 allison there is a disagreement on whether monthlies or biannuals should be the "default"
23:15 pmichaud NotFound: My point is that it was possible for us to have not caught this "serious parrot problem"
23:15 pmichaud NotFound: I agree it's a serious parrot problem.  But Parrot's tests didn't catch it.
23:15 NotFound pmichaud: yes, we can always make big mistakes.
23:16 allison the answer is "it depends", on a lot of factors, whether the user should be using one or the other
23:16 pmichaud afk # dinner
23:16 allison so, the documents need to be clear about the risks and advantages of each
23:17 chromatic I'm not sure it's practical to build a stable, modern, full-featured HLL on Parrot 1.0.
23:18 allison chromatic: full-featured is not what we promised for 1.0
23:18 allison (in the sense of "we will add no further features")
23:18 chromatic Sure, and people starting from nothing probably won't run into every possible wall by 1.4... but in terms of a realistic situation.
23:19 GeJ Good morning everyone
23:20 allison summary: I'm still not convinced it's wise to encourage people to upgrade every month.
23:20 allison summary: Does anyone have a compromise solution?
23:20 NotFound The problem in t/pmc/packfileconstanttable.t, TT #385, is not the same that caused the rakudo building segfault?
23:20 allison it may be simply "we don't encourage them to do anything"
23:21 NotFound I think we must just explains our plans, no encourage nor discourage anything.
23:21 chromatic That's fine with me, provided we use language as clear as possible.
23:22 allison NotFound: yes, if we're clear enough on what the monthly and biannual releases mean, they can make the choice for themselves
23:22 chromatic If a reasonable person unfamiliar with the project can read that and understand what we mean, fine.
23:22 allison chromatic: yes, that's the key point
23:22 bacek_ joined #parrot
23:22 allison chromatic: and, we may have to revise as we start getting responses from users
23:23 klapperl joined #parrot
23:23 chromatic If we can describe a biannual release as "Here's a spot to rest for six months if you don't care about new features and can live with only critical fixes," fine.
23:23 allison chromatic: that's already a bias
23:23 chromatic Okay, remove the clause about new features then.
23:24 allison chromatic: if we're going to not encourage any particular practice, we have to be completely non-biased in the descriptions
23:24 allison biannuals are X, monthlies are Y
23:24 NotFound allison: reasonably, completely may be impossible.
23:24 chromatic "We will provide critical bugfixes for the January and July releases as we deem necessary."
23:24 allison clear, measurable distinctions
23:25 NotFound If we disagree on each word, surely will be impossible.
23:25 allison chromatic: true in substance, edit for tone
23:25 allison (sound less like Linux Kernel hackers)
23:25 chromatic "You suck, you suck, you suck, you're cool, and you suck."
23:25 allison yes :)
23:26 allison okay, so we have a task of editing the support policy. I'll do that.
23:26 chromatic "We will do our best to provide critical bugfixes for the January and July releases."
23:26 allison chromatic: something like that
23:26 chromatic We can't promise to address or backport everything, but we can promise to try.
23:27 NotFound We'll try not to kill you, but...
23:27 chromatic Me, I'll assign them all to NotFound or Whiteknight, because I'm just that kind of cool.
23:27 allison I'll call that piece wrapped up.
23:28 chromatic I can live with that kind of description.
23:28 NotFound You must translate the assignation to spanish, to be sure I don't misunderstand ;)
23:28 allison final point of contention: what do we call the ftp directories? That is, what do we call the releases?
23:28 allison and, before we get into it, is it the final point?
23:29 chromatic Yo estoy el tiburon grande.
23:29 chromatic grande y guapo
23:29 NotFound chromatic: Yo seré espalda.
23:29 allison something about big sharks
23:29 allison or donkeys
23:29 chromatic Hasta la manana de manana.
23:30 NotFound (Impossible to translate spanish joke on translations)
23:30 chromatic It's difficult with an Austrian accent, certainly.
23:30 chromatic How about "monthly" and "biannual"?
23:31 allison monthly is out, because all releases are monthly
23:31 chromatic symlink to latest_monthly and latest_biannual
23:31 allison (both the January/July ones and the other ones
23:31 chromatic Or just the symlinks.
23:31 chromatic Stuff everything in a big bucket of releases.
23:31 chromatic symlink the latest biannual and the latest
23:32 NotFound chromatic: you need a keyboard with a dead ~
23:32 rurban only the latest symlink?
23:32 allison chromatic: could you outline your objections to "stable"/"development"?
23:32 rurban ln -s 1.0 latest
23:32 chromatic Sure.  The opposite of "stable" is "unstable" and "development" doesn't mean anything.
23:32 NotFound We can call them magic/maggot
23:33 chromatic We could count back from 100 to 0 in our release numbers and call them Maginot.
23:33 allison chromatic: I don't see the problem.
23:33 chromatic I'm not in the business of putting out unstable releases.
23:33 allison any name will have the meaning we attach to it
23:33 allison we don't call them unstable
23:34 rurban didn't we agreed to remove stable? so make everything on big list of releases and the user puts the meaning into it.
23:34 chromatic We don't call them stable.  We call other releases stable.  We explicitly don't call them stable.
23:34 allison I'm open to being convinced, I just don't see it.
23:34 allison rurban: the decision is still stable/development, untile we come up with something better
23:35 chromatic These releases are stable.  We call them stable.  These other releases, we don't call them stable.
23:35 allison (and yes, this is the key point of disagreement)
23:35 allison (that's why I wanted to save it until we had cleared up that it was the *only* remaining point of disagreement)
23:35 allison chromatic: what does that mean?
23:35 purl That boy needs therapy.
23:36 chromatic What makes the stable releases "stable"?  Do they work?  Do they pass their tests?  Do they not try to make time with your cat?  Do they not eat your data?  Has the API changed?  Are there bugfixes only?  Do we support it for a long time?
23:36 allison chromatic: we define it
23:36 chromatic That's not really good enough.  The word is too overloaded.
23:36 NotFound chromatic: we must answer such questions in a directory name?
23:37 allison chromatic: but we're using the overloading to our advantage
23:37 chromatic When you pick a term like "stable" with so many connotations, you invite those questions.
23:37 chromatic Do they work?  Yes.  Do the development releases work? Yes.
23:37 chromatic Do they pass their tests?  Yes.  Do the development releases pass their tests?  Yes.
23:37 allison Larry always says it's better to take an existing word that's 90% of the way to the meaning you want than to take a completely different word.
23:37 allison "stable" is 90% of the way there, and we define the remaining 10%
23:37 chromatic Has the API changed?  From 1.0 to 1.4, yes.  In the development releases?  Yes.
23:38 chromatic Are there bugfixes only?  No.  In the development releases?  No.
23:38 chromatic Do we support it for a long time?  Only in the sense of critical bug fixes.  For the development releases?  Only until the next monthly.
23:38 chromatic Am I missing any other connotations of "stable"?
23:38 allison development means a monthly release, where no bug/security fixes will be backported, and your option for fixes is to upgrade to the next monthly
23:39 allison a stable release is one where we'll make clear exactly what API changes you can expect, and where we will make bug/security fixes
23:39 chromatic stable means a monthly release, where critical bug/security fixes will be backported, and your option for fixes is to upgrade to a subsequent release.
23:39 chromatic NO
23:39 allison chromatic: what?
23:39 chromatic CRITICAL bug/security fixes
23:40 allison chromatic: we tabled the adjectives discussion
23:40 chromatic I'm untabling it.
23:40 NotFound I don't see the problem with the names monthly/biannual
23:40 chromatic CRITICAL bug/security fixes
23:41 allison NotFound: monthly we can't use
23:41 chromatic Why can't we use "monthly"?
23:41 allison (they're all monthly)
23:41 allison biannual doesn't say anything about what the difference between the two is
23:41 chromatic There are two of them a year.
23:41 chromatic There are twelve monthlies a year.
23:41 NotFound allison: the biannual is also a monthly? No problem about that for me.
23:41 purl okay, NotFound.
23:41 allison yeah, what does that mean?
23:42 chromatic We have a time-based release schedule is what that means.
23:42 allison chromatic: no, there are 10 non-biannual releases
23:42 chromatic Yes, because they're monthly.
23:42 allison so are the biannuals
23:42 allison they're all monthly releases
23:42 chromatic Yes, they are.
23:43 allison "Parrot follows a monthly release cycle..." that much is clear
23:43 NotFound allison: yes, and two of them are the biannuals, no problem.
23:43 chromatic The January and July releases are also biannual releases.
23:43 chromatic They receive critical bug and security fixes until the next biannual release.
23:43 allison biannual is completely meaningless to anyone outside the project
23:44 chromatic And yet it describes precisely what we're doing.
23:44 * rg thinks that's a good thing. it encourages them to read the documentation.
23:44 NotFound Well, if we want to avoid any connotation the name must be meaningless
23:44 allison rg: confusing your users before they ever get started is never a good thing
23:44 chromatic We don't want to avoid every connotation, just the ones that are misleading.
23:45 NotFound chromatic: someone will mislead any
23:45 allison we definitely don't want to start with no connotations
23:45 chromatic Yes, but I'm using the reasonable and literate person policy.
23:45 NotFound Sometimes I doubt reasonable people does exist %-)
23:45 allison if we were going for that we'd have "foo" releases and "bar" releases
23:46 NotFound The rest of the time, I'm sure they don't
23:47 allison I accept that we're going to have to do some explaining of our policy, but "stable" and "devel" get them 90% of the way to our meaning
23:47 chromatic I thought you had agreed to let people make their own decisions about upgrading.
23:48 rg so would you like to call the directories "valid_for_6_months" and "valid_for_1_month"?
23:48 allison chromatic: yes, how does that take away their decision?
23:49 chromatic It's like me going in #parrotsketch and saying "chromatic, Coke, fp, jonathan, kjs, NotFound, particle, pmichaud, and Whiteknight are good coders."
23:49 allison chromatic: I don't follow
23:49 chromatic "Other members of #ps include allison, cotto, Infinoid, japhb, and Tene."
23:49 allison okay, and?
23:50 chromatic I didn't say that you're not a good coder.
23:50 Tene_ ;_;
23:50 chromatic I merely implied it.
23:50 chromatic (Please note that I am NOT saying anyone isn't a good coder; it's just an example)
23:50 allison this really sounds like a strawman to me
23:51 Tene_ (Please note that I'm not actually offended, just harassing c)
23:51 Infinoid Given how little coding I've done for parrot recently, it's probably deserved.
23:51 chromatic What makes our "development" releases *not* stable?
23:51 chromatic Please answer that question.
23:51 allison until now, we've been calling all of our releases "development" releases
23:52 Infinoid Along the same lines, if users should expect breakage upgrading from one monthly to the next, I don't see the point of having a 6-monthly deprecation policy at all.
23:52 NotFound To make more Ubuntu analogies, we can call it STS, Short Time Support
23:52 chromatic I don't mind short_support and long_support.
23:53 chromatic Or monthly_support and biannual_support.
23:53 Whiteknight yay! somebody thinks I'm a good coder
23:53 allison NotFound: none of our releases are long term support
23:53 allison LTS is 3 years
23:53 Infinoid Whiteknight: I never had a question about that :)
23:53 NotFound allison: that's the point. The other hasn't even that.
23:53 chromatic No, but that does seem to be the biggest distinction between the monthly and biannual releases.
23:54 allison chromatic: it's support, deprecation cycle, and synchronization points for various related projects
23:54 allison what part of that isn't stable?
23:54 chromatic Let's throw out "synchronization points" for now, because I don't believe it and I'm not even sure I know what it means.
23:55 chromatic I know what "critical bug and security fixes" means.
23:55 allison okay, packaging points
23:55 cas left #parrot
23:55 NotFound Target points, maybe.
23:55 chromatic I'm not sure the packaging question is relevant now.
23:55 allison NotFound: leaves the question "target for what"
23:56 chromatic Does the fact that we don't backport critical bugfixes to a February release make that February release "unstable"?
23:56 allison chromatic: okay, I'll agree to disagree on the packaging question
23:56 NotFound allison: then we only have the foo/bar way.
23:56 chromatic I'm not even sure we disagree.  I just don't care about the packaging question.
23:56 japhb [Bikeshed] chromatic, would you mind 'semiannual' rather than 'biannual'?  The latter is easily confused with 'biennial'.  ( http://en.wiktionary.org/wiki/biannually )
23:56 chromatic semiannual would be fine too.  I have no particular care about that bikeshed color.
23:56 Tene_ chromatic: "no modifications ever after the next release" certainly implies that it's *more* stable than biannual
23:56 allison chromatic: it makes it a development release
23:57 chromatic How does that make it a development release?
23:57 allison because we aren't offering to give it the same level of production support as the stable releases
23:58 chromatic How does that make it "unstable"?
23:58 allison it doesn't
23:58 allison it makes it development
23:58 Infinoid This goes back to the suggestion in #ps of calling them "supported" rather than "stable"
23:58 chromatic Supported is fine.
23:58 chromatic Provided we're very clear that that's critical bug and security fixes only.
23:59 allison supported isn't bad
23:59 NotFound I think we already agreed that no matter what the name is, we must explain.
23:59 chromatic Now for a better term than "development".
23:59 allison you jump too fast
23:59 chromatic Sure, we have to explain, but that explanation can be *three* sentences.  I typed them earlier.
23:59 allison grasshopper
23:59 purl Grasshopper, it is important that you develop the ability to learn from the available documentation.  With this skill you become as a peer to those who discuss the mysteries of Perl.  Without it, you become but a beggar searching for scraps, dependent on the whims of those with more wisdom and knowledge.
23:59 Infinoid NotFound: Sure, it should be documented either way.  I just think "supported" matches reality better than "stable"

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced