Parrot 0.9.1 Released | parrot.org/ | 451 RTs left!
Set by moderator on 24 February 2009.
Infinoid I should rephrase that to say: parrot's string constants have always confused me. 00:00
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:01
pmichaud I'd leave it as-is, personally. 00:02
cotto I'll go with that approach, then. 00:03
00:09 AndyA joined 00:16 alvar_ joined 00:22 tetragon joined 00:29 Limbic_Region joined
dalek kudo: 4ec17da | pmichaud++ | docs/ChangeLog:
ChangeLog update.
 00:39
shorten dalek's url is at xrl.us/beh357
nopaste "kid51" at 71.247.39.200 pasted "Am I calling these tests correctly?" (10 lines) at nopaste.snit.ch/15758 00:41
00:52 Hunger joined, baest joined 00:53 rg joined 00:55 namenlos joined 00:57 baest joined
Coke kid51: no. -j is no longer a valid option 00:59
You need --runcore=jit or -R jit now.
(which 'make testj' should use)
kid51 Would it have been a valid option as of, say r37039? 01:01
01:01 omega joined 01:10 skv joined 01:55 cognominal joined 01:58 Tene_ joined
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:17
Does anyone know if, in Trac tickets, the 'Cc:' pane actually works? 02:20
rg yes, it does.
purl stays quiet
kid51 I've added myself as a Cc to certain tickets, but not gotten any mail.
rg did you add your full email address?
kid51 No, based on previous instances, I just used my login. 02:21
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."
rg in fact, i can only add or remove myself, not edit the cc 02:23
but it's showing my full email to add, not my login. 02:24
maybe the usernames part is broken?
kid51 Quite possibly.
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
kid51 You are correct. 02:27
Which means that the 'username' aspect of that is probably broken.
Which calls for a new TT! 02:28
rg :)
cotto The GSOC 2009 wiki page is very lonely. 02:31
kid51 link? 02:33
rg kid51: look, my first solaris smolder: smolder.plusthree.com/app/public_pr...ails/18495 02:34
shorten rg's url is at xrl.us/beh4n2
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!
I, too, have been using make smolder_coretest. On my iBook, which is slow.
rg Duration 48:17 ... this thing is sloooooooow
kid51 Gawd, that's even slower than my iBook! 02:37
Vastly slower, in fact. The duration on smolder.plusthree.com/app/public_pr...ails/18491 was 17:04. 02:38
shorten kid51's url is at xrl.us/beh4oe
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 ;)
i'm so happy for the am64 platform i'm usually working on. regular smolder in under 5 mins ;) 02:40
*amd64
kid51 So what you just posted is not from your regular platform?
rg no, that's a sparc so we can build big endian native_pbc files 02:41
kid51 k
rg i wonder, is sun4u known widely enough to tell it's 64bit? 02:44
but then the default build on those is still 32bit 02:45
kid51 knows little about Sun/Solaris
rg: If you're looking at a Sun box, can you add anything to trac.parrot.org/parrot/ticket/205 02:46
rg i wonder who's the poor soul who submitted smolder.plusthree.com/app/public_pr...ails/18490
shorten rg's url is at xrl.us/beh4ps
cotto kid51, trac.parrot.org/parrot/wiki/GSOC2009Tasklist 02:48
rg i think that's the atan2 problem with gcc. there's a note in the hints about that. 02:49
do you think i should copy the note to the ticket? 02:52
02:53 HG` joined
kid51 Why not? I just added some speculation thereto. 03:06
03:15 rakudohudson joined
kid51 must sleep 03:18
purl $kid51->sleep(8 * 3600);
rg must sleep, too 03:28
03:28 Khisanth joined
mikehh what happened to dalek 03:30
dalek rrot: r37085 | coke++ | failed to fetch changeset:
Update harness testing to account for mapping of harness options to
 03:32
03:33 DietCoke joined 03:42 janus joined 03:49 HG` joined
Coke doing a bisect over a range of commits that involve deleting lots of directories sucks. 03:54
03:55 japhb joined
Coke finds a good rev for bisecting #390 03:58
04:35 tetragon joined 04:59 Tene joined 05:12 masak joined
cotto trac++ 06:06
06:30 Theory joined 06:31 Ademan joined 07:05 uniejo joined 07:16 slavorgn joined 07:29 Ademan joined 07:54 riffraff joined
dalek rrot: r37086 | fperrad++ | trunk/lib/Parrot/Configure/Compiler.pm:
[makefile] use simply expanded variable ':=' only with gmake (see TT #382)
 08:26
08:40 Nom joined 08:48 rblackwe_ joined 09:20 bacek joined
dalek rrot: r37087 | fperrad++ | trunk (2 files):
[rand] apply a patch from TT #392 (fix on 64bit platform)
 09:43
rrot: r37088 | fperrad++ | trunk:
svn:ignore pirc
 10:03
kudo: e2ee4c7 | (Moritz Lenz)++ | src/ (2 files):
remove trailing spaces
 10:28
shorten dalek's url is at xrl.us/beh5j6
10:34 namenlos joined
dalek rrot: r37089 | fperrad++ | trunk/config/gen/makefiles/root.in:
[install] set *nix rights after a copy
 10:34
cotto That commit seems to make some unwarrantedly unixy assumptions. 10:51
10:59 cybertom joined 11:05 cybertom left
nopaste "bacek" at 123.243.38.218 pasted "string.pmc.vcs" (16 lines) at nopaste.snit.ch/15760 11:32
bacek This is fix for memory leak in string.pmc
11:50 kid51 joined
bacek ok. My attempt was incorrect. But why we need copy of string here? Isn't s->strstart enough here? 11:54
12:22 gryphon joined 12:33 rg1 joined 13:06 tetragon joined
Coke cotto: CHMOD is probably extutils. 13:23
which I would expect to DTRT.
bacek: I don't know the context of your question, but in general, no, strstart isn't necessarily a valid string. 13:40
valid c-string, that is.
dalek rrot: r37090 | fperrad++ | trunk (2 files):
[install] install install_config.fpmc instead of runtime/parrot/include/config.fpmc
 13:57
14:04 Tene joined 14:06 Whiteknight joined 14:20 jan joined
rg1 cotto: that commit must be only temporary anyway 14:22
dalek rrot: r37091 | fperrad++ | trunk (5 files):
[install] runtime/parrot/library/config.pir is now generated, and can work on installed tree
 14:39
rrot: r37092 | fperrad++ | trunk/config/gen/makefiles/root.in:
[install] build the correct installable_pbc_to_exe (see TT #345), and fix dependencies
 14:43
14:46 jan joined 15:12 alvar joined 15:42 khatar joined
dalek rrot: r37093 | rurban++ | trunk/MANIFEST.generated:
[install] MANIFEST fixes

  - delete old pdb, pirc		 15:45
15:47 cas joined
NotFound bacek: What memory leak? 15:49
purl i guess memory leak is blogs.sun.com/roller/page/kto?entry...of_leaking or blog.jrock.us/categories/Catalyst/2007/9/2
jrockway wow, that is a terrible link
15:50 particle1 joined
jrockway purl, memory leak? 15:50
purl i guess memory leak is blogs.sun.com/roller/page/kto?entry...of_leaking or blog.jrock.us/articles/Plugging%20a...0whale.pod
jrockway fixed ;)
jrockway un-delurks
dalek rrot: r37094 | fperrad++ | trunk/config/gen (2 files):
r37095 | NotFound++ | trunk/src/pmc/string.pmc:
 15:53
15:53 dalek joined 16:07 khatar joined 16:10 davidfetter joined 16:25 khatar joined 16:28 Whiteknight_ joined
kudo: 688f9a2 | pmichaud++ | (3 files):
Modernizing some code. Eliminated globals from Configure.pl. Error checking on file closes.
 16:47
shorten dalek's url is at xrl.us/beh6hg
dalek rrot: r37096 | NotFound++ | trunk/examples/pir/interlangs.bas:
[examples] fix interlang.bas instructions, PacoLinux++
 16:48
16:48 Patterner joined 16:53 Khisanth joined
dalek rrot: r37097 | NotFound++ | trunk/examples/pir (2 files):
[examples] fix interlang.bas and interlang.pir instructions, PacoLinux++
 17:00
kudo: 868c638 | bacek++ | build/gen_metaop_pir.pl:
Implement [Rop]
 17:14
shorten dalek's url is at xrl.us/beh6k6
pmichaud #ps in 50 17:40
17:44 particle1 joined
dalek kudo: c08b9bd | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 315 files, 7087 passing, 0 failing
 17:45
shorten dalek's url is at xrl.us/beh6qa
18:07 barney joined 18:11 Psyche^ joined
dalek rrot: r37098 | fperrad++ | trunk/config/gen/makefiles/root.in:
[build] partial revert of r37016, please don't introduce dependents in inference rule. NOT SUPPORTED by all make.

BSD make has similar issue (see TT #382). Apply patch from rg++.		 18:12
rrot: r37099 | Util++ | trunk (32 files):
[cage] (TT #397) PDD07 enforcement for Parrot_str_not_equal(foo,bar)==0
 18:25
18:27 allison joined 18:31 rurban joined
davidfetter rurban, ping 18:47
oops. nm. let's wait until after parrotsketch 18:48
18:49 kj joined 18:53 Tene_ joined
davidfetter what's the authoritative scm? i'm getting wacky troubles with building make rpm from the git repo 18:55
19:16 Theory joined 19:19 Whiteknight joined
rurban allison: cygwin trunk builds fine, esp dynpmc and dynoplibs 19:23
19:24 mikehh joined
allison rurban: okay, great 19:25
19:37 estrabd joined
dalek pp: b9baec4 | (Bernhard Schmalhofer)++ | t/php/type.t:
Pipp::Test doesn't support $TODO.
 19:54
shorten dalek's url is at xrl.us/beh7b6
Util davidfetter: the authoritative repo is git://github.com/rakudo/rakudo.git , as described in Moritz's post perlgeek.de/blog-en/perl-6/where-ra...lives.html . 19:55
As evidence, see also github.com/rakudo/rakudo/ , which shows the official "Public Clone URL".
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.
Coke (third method) - that's the recommended method. 19:56
davidfetter Util, for parrot, too?
Util Do you mean "what is the authoritative SCM for Parrot"? 19:57
If so, then `svn co svn.parrot.org/parrot/trunk/ parrot` 19:58
20:03 Coke left
dalek pp: 1ae73de | (Bernhard Schmalhofer)++ | t/php/relops.t:
Parrot::Config might not be available
 20:07
shorten dalek's url is at xrl.us/beh7ds
nopaste "rurban" at 93.210.224.72 pasted "support_policy" (41 lines) at nopaste.snit.ch/15762 20:08
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?
pmichaud rurban: no, according to #parrotsketch, it's now "stable release" 20:14
Infinoid allison: You've answered my website questions, thanks.
allison Infinoid: okay 20:18
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
nopaste "rurban" at 93.210.224.72 pasted "support_policy #2" (41 lines) at nopaste.snit.ch/15763 20:20
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:27
allison Infinoid: that sounds like an ideal list 20:43
cotto Util, I'll look at TT #398 later today. 20:44
Util Thanks, cotto 20:47
20:48 baest joined
pmichaud looking at TT #398 now. Looks like a couple of errors were introduced since the original. 21:12
Agreed that the indentation in the original was incorrect.
Util Thanks, pmichaud 21:17
21:25 rdice joined 21:26 donaldh joined 21:36 chromatic joined
chromatic Fixing bugs and releasing a new version of the January release when it's June is *stupid* and *wrong* and *expensive*. 21:37
We already have a perfectly good way to release a new version of Parrot for people to use.
We've done it for more than two years now.
rurban the term "stable release" in the support_policy? 21:38
chromatic Making any release more magical than any other release. 21:39
rurban but .0 and .6 should be makred as deprecation points somehow
chromatic The entire *point* of using time-based releases is that no release is more magical than any other release.
I can point to an entire shelf of books in my library which all say the same thing.
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.
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.
rurban so the deprecation policy needs to be changed in the text? from future 6 releases to 2 as now?
allison if we have users, then we have to release bug and security fixes for them
pmichaud thus, what allison calls "development releases" we simply identify by month.
dalek rrot: r37100 | pmichaud++ | trunk/src/sub.c:
[core]: Clean up code format issues identified in TT #398 (Util++)
chromatic We *do* release bug and security fixes.
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.
pmichaud the other "stables releases" we give numbers like 1.0, 1.5, 2.0, 2.5, etc.
allison ah, right this is back to the question of "how long to we support a release"
pmichaud That eliminates a lot of the confusion surrounding 1.1, 1.2, 1.3, etc.
allison nothing to do with what we call them
chromatic No, that's not it at all.
The real question is "Why bother releasing software we tell people not to use?" 21:42
I prefer to keep exercises in masturbation out of my software devevelopment processes.
allison my original proposal was to stop the monthly releases, but you and others convinced me otherwise
chromatic Because monthly releases *work*.
particle1 monthly user upgrades don't. 21:43
chromatic If our software gets better every month, it's worth releasing every month.
allison I do think it's valuable for training new release managers and for a bugfix cycle
chromatic: monthly releases work for *us*, for the developers, they don't work for users
chromatic Users don't *have* to upgrade monthly.
Users who *want* to upgrade monthly have that option.
allison right, so we have to tell them which versions to upgrade to
particle1 users *have* to get critical security fixes, without deprecations. 21:44
allison and which versions we'll be providing bug/security fixes for
particle1 microsoft used to bundle features with bugfixes. that sucked.
allison we can't afford to provide bug/security fixes to all monthly releases, that would kill us
chromatic Okay, so you want to predicate the whole release structure around the exceptional possibility that there will be a critical security fix.
particle1 perl 5.8 hashes.
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?
particle1 notepad.
purl notepad is the worst. or a piece of shit or to vi what garlic chicken salad is to a flamethrower.
chromatic allison, what piece of software do you know that has more critical bug/security fixes than monthly releases?
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.
I'm not fixing bugs twice, in two different releases, for free.
I'm not supporting code that I can't see and don't know even exists.
I'm *not* letting you tell volunteers that they have to do that.
allison chromatic: that's fine, but as a project, we have to support users
chromatic If you want to do it, fine.
See p5p for the inevitable results of *that* decision. 21:47
allison we never tell volunteers that they *have* to do anything
we already had this conversation
chromatic *What* makes a 1.1 release not worth releasing?
Why do we imply it's not stable?
allison we're not talking about making bug/security releases for 8 year old version of Parrot
chromatic Do we not have a test suite?
Do we not run the test suite? 21:48
Do we not fix bugs in it?
allison we're talking about 2 years, tops
chromatic Do we deliberately have regressions from 1.0?
allison in an ideal world, that's great, but real software is not like that
rurban stable is about API decisions, not about bugs
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
chromatic Frankly, "real software" doesn't fit in the "stable API" nonsense either.
allison chromatic: planning our release structure around the idea that we'll never have bugs or security problems is not reasonable
chromatic That's just another example of magical version number thinking.
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.
If you think my point is that we'll never have bugs of security problems, then we have a REAL problem communicating.
allison maybe I misunderstood you, but as far as I know I was only directly answering your statement 21:51
try explaining more?
or, perhaps I should ask, what is your point? 21:52
chromatic Maintaining a 1.0 branch is a mistake.
allison chromatic: well, hopefully we'll never have to create one
chromatic Backporting the most *critical* of fixes for crashes, data losses, and exploitable security fixes is fine.
allison hopefully we'll never have critical bug and security fixes 21:53
chromatic Anything else is madness.
allison but, when we do, we need to have a plan in place for how to handle them
oh, yes, we already agreed it's only critical bug and security fixes that get a 1.0.1 or whatever release
chromatic We continue to release monthly releases with the most boring, unimaginative, non-magical version numbering scheme imaginable.
rurban but calling every monthly release "stable" is even more weird then
chromatic What makes the monthly releases anything *but* stable? 21:54
allison the non-magical numbering has also already been decided
chromatic Do we wave magnets over our hard drives before releasing them?
rurban the need to branch it and maintain it
chromatic We don't branch for releases. No. That's nuts.
allison the monthly releases go on exactly as they have done
rurban 1.0.1, 1.1.2 ...
allison 1.1.0 is no different than 0.9.1 21:55
pmichaud I think my point is that it should be.
chromatic We *don't* suggest that there's any difference in stability between 1.0 and 1.1.
allison chromatic: that's where the difference enters
rurban so we should just explain that int the policy document
chromatic *What* difference?
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
chromatic NO.
allison 1.1 we won't do bug/security fixes on 21:57
chromatic No bug fixes.
rg1 the big difference i see are deprecations. you can't drop in a newer release and expect older pbc to work.
allison for bug/security fixes to 1.1, you upgrade to 1.2
or 1.3, or...
chromatic People are not going to understand that magical numbering system.
No magical numbers. Please.
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?
chromatic Oh look, another strawman.
Yay. It's *FUN* to be misquoted.
allison chromatic: the current numbering scheme was chosen exactly because you wanted no magical numbers
rurban sorry.
allison chromatic: is there a less magical scheme we could pick?
chromatic And yet, 1.0 and 1.6 *are* magical version numbers.
allison rurban: I mean there will be no 1.1.1, 1.2.1, etc 21:59
1.0 and 2.0 are magical
chromatic What's magical about them? 22:00
rurban so use only x.0 as magical number and set milestones to any arbitray number?
allison and pretty obvious to anyone
chromatic If there's magic, I want to be able to *measure* the magic.
I don't want it to be magic, even. I want it to be scientific.
I want it to be so utterly boring and reproducable, it's the opposite of magic.
rurban and major deprecations as now, not every 6 months?
allison it's deprecation cycles and whether they get bug/security fixes, that's the cold, hard difference
chromatic Okay. Good. We can *measure* that. 22:01
I mean, the deprecation points.
allison yes, the january/july releases
NotFound Are you debating about numbers, or about the concept of having 1 or 2 releases a year that have bug fixes?
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
(we keep running into points where we violently agree)
chromatic: production users shouldn't use the monthly releases 22:03
chromatic: developers might
22:03 Whiteknight joined
chromatic What kind of production users of a virtual machine and compiler toolkit aren't developers? 22:03
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
chromatic End-users of *Parrot* will use whichever version their *language* requires.
allison chromatic: if the only people who ever use parrot is compiler-developers, we're dead
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.
Talk about a DarkPAN.
allison chromatic: and yes, what they'll install is "parrot-php" or something like that
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
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.
allison because you need to synchronize between languages
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.
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?
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
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?
allison chromatic: that right there is the fundamental reason for adding biannual releases
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.
allison what? I don't understand taht last question?
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
chromatic NotFound, I agree, but that's not the impression allison gave me last week.
Why can't they do the same for monthly releases?
pmichaud (and hope that the biannual release hasn't broken anything)
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
chromatic: it's slowing down our language developers
chromatic As opposed to all their time updating to biannual releases.
allison yes, we had that conversation too
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?
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.
pmichaud Tene_: or package your own copy of parrot.
allison but it's horribly discouraging to have your language be broken every time to have a Saturday to work on it
chromatic Which, as it turns out, is just about the only assumption you can make for software project management.
Let's do an experiment then. 22:12
I'll pick a bug in Parrot.
allison the cost of context switching comes into play
chromatic I'll pick two ranges of commits.
One has 20,000 commits.
One has 200 commits. 22:13
We'll see who finds the bug more easily with a bisect.
Actually, let's make the numbers more realistic.
Change that to 9000 and 1300.
purl chromatic: that doesn't look right
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
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)
chromatic Do we not mark deprecations early and often?
allison chromatic: because we already are, and we're not planning to slow the pace of development
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:15
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.
allison pmichaud: so developers can track them if they want to
chromatic: is it only the name that bothers you?
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.
allison pmichaud: they can choose 22:17
chromatic And the most recent version in Ubuntu.
allison they don't have to track anything except the most recent packaged version (on whatever OS)
pmichaud oh, language implementations don't have to issues bugfix backports? 22:18
*issue
allison each language decides on its own support policy
but, the idea of bug/security fix releases is that they don't change the interface at all
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.
allison so, parrot making a bug/security release shouldn't affect languages targeting that release
(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"
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.
removing the n_* opcodes
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
Tene_: I've made quite a few.
allison Tene: is that a bugfix?
Tene: sounds like a deprecation
Tene_ pmichaud: you'v ebeen committing to cardinal?
allison: that's right.
pmichaud Tene_: oh, sorry, I didn't realize you were limiting to cardinal. 22:22
allison Tene: okay, a *language* failure fix, makes sense
pmichaud I was referring to pct/rakudo/...
Tene_ ah
pmichaud: You're right. I thought that I mentioned cardinal, but my writing is bad today.
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.
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
chromatic We *can't* predict how much work it is to upgrade to a monthly release.
allison yes
and, we can't dictate the upgrade policy of various language
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).
allison yes 22:25
chromatic We can only predict *deprecations*, because we explicitly *plan* deprecations.
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.
NotFound And languages cannot dictate policy of his packagers, also.
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
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
chromatic: yes, we can plan deprecations
all we're doing here is giving people more options
they have the option of continuing to upgrade monthly
chromatic But our language *discourages* that. 22:27
I mean our jargon.
allison they will also have the option of upgrading once or twice a year, and we'll give them good points to do it
Tene_ but if we're telling distros to only ship our biannual releases... 22:28
chromatic Exactly.
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
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.
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?
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.
allison that they're intended for developers
chromatic Really.
davidfetter yeah
chromatic The opposite of "stable" is "intended for developers"?
allison stable and development
chromatic okay then. 22:30
We're back to my question. What practical attributes of the "stable" releases can we measure precisely?
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
chromatic That's because Debian doesn't have regular releases.
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.
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?
Tene_ If the big point of the magic releases is ubuntu, has anyone talked to ubuntu to find out what they will actually ship?
allison chromatic: and, to repeat myself: a stable release is about deprecation points and bug/security fixes
chromatic We can predict what gets fixed and when?
What kind of bugs get fixed in "stable" releases?
allison Tene: they won't ship monthlies
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
Tene_ allison: because they happen every month? Do they just refuse to ship software released that frequently?
allison chromatic: because we turn around new packages faster than they can sponsor and include them, so we end up stuck at 0.4
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.
allison chromatic: we're not, Ubuntu is a rabbit trail we got off on
chromatic You brought it up.
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."
I believe I responded with something like "Ubuntu will have to support them, yes."
allison chromatic: do you mean our in-person conversation last week?
chromatic Yes.
allison it was a rabbit trail there too
Tene_ Presumably ubuntu won't ship any new versions of languages either
nopaste "rurban" at 93.210.224.72 pasted "support_policy #3" (27 lines) at nopaste.snit.ch/15766 22:35
allison Tene: yes, they only do package updates twice a year
22:35 ron joined
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?
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?
chromatic Tene_, I think so too.
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
NotFound rg: not at alll
allison chromatic: you're not debating the 1.0, 1.1, 1.2, 1.3... release numbering?
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.
allison chromatic: you're not debating changing our deprecation cycle to twice per year?
rurban I think we agreed to remove the word stable from the pod
chromatic I think a six month deprecation cycle is fine.
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?
allison skip the term "stable", I haven't gotten there yet
chromatic Except I want to write that in an English sentence.
allison chromatic: critical bug and security fixes made to January/July releases
chromatic What makes a bug fix "critical"? 22:39
Tene_ allison: "critical bug"?
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"
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.
chromatic Anything other than a segfault or an exploitable flaw, you either backport the patch yourself or upgrade to a monthly release?
(or wait for the next biannual release) 22:41
allison yes
(with the option to evaluate each case as it comes)
Infinoid that leaves a big range of bugs that HLLs have to deal with, with no help from us
allison that is, we're not establishing a law never to be broken, we're establishing a set of guidelines
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?
allison Infinoid: yes, what chromatic says, and also 6 months isn't really a terribly long time to wait for a new feature
Infinoid I hope so. I just don't like the idea of explicitly treating those releases as abandonware.
NotFound I hope that most HLL will not always be walking on thin ice.
Infinoid It's more a matter of perception than anything else
allison Tene: I would steer clear of offering "guarantees" for anything 22:43
Tene: that's what a support contract is for
chromatic I'm comfortable with the perception that the best way to work with Parrot is to target the monthlies.
allison chromatic: we didn't get there yet
Tene_ if ubuntu isn't going to be releasing updates of languages, no language will want to track biannuals either
right?
purl i heard right was aways right?
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
so, languages will track biannuals
and language packages will also track biannuals
NotFound Tene_: we can't predict what people will do, we can clearly explains our plans to let them make informed choices. 22:45
That includes explain that our plans are not set in stone.
allison chromatic: so, wrapping up one point, we agree on bug/security fixes for the January/July releases?
chromatic Only if you call them "super critical bug/security fixes".
I am not kidding about that. 22:46
allison super happy dev farm chocolate fun-fun
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.
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.
NotFound "Godzilla fixes"
allison chromatic: you want law, we're not making law, we're making guidlines for future desisions
cotto mothra-sized or bigger
chromatic I don't want law.
I don't want ambiguity.
allison life is ambiguity 22:48
chromatic "We'll fix bugs for this release" could mean many, many things.
particle1 and i have the tee-shirt.
allison chromatic: yes, and it doesn't matter what we call it, we'll still have to explain it
chromatic Then why not explain it in the support policy document with an adjective? 22:49
rg can you call it "security bug fixes"?
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.
allison chromatic: it just begs more questions
NotFound And even if we are cristal clean in the explanation, someone misinterpret it, on purpose or not.
chromatic Right.
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, .... ?
chromatic English has noun phrases for a reason. Anyone care to speculate why?
allison okay, let the record show that we disagree on whether we should call them "bug/security fixes" or "super critical bug/security fixes"
moving on
chromatic davidfetter, because we're adults, and adults don't need release candidates if they know what they're doing.
NotFound "We'll fix it if you send us enough cookies"
particle1 chromatic: your nickels are no good here.
donate time. 22:51
davidfetter adults are not as common as i'd wish. not in software, not anywhere else :P
allison I agree with chromatic on avoiding "release candidates", though I wouldn't state it quite like that
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.
davidfetter, that's why there are so many release candidates.
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.
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)
Infinoid: we're not there yet
chromatic I don't care about people who don't read the documentation. Darwin will claim them soon enough.
allison so next piece 22:53
davidfetter there's a difference between "rtfm" and "major POLA violation"
and tbh, "releases" that aren't actually, are the latter
allison chromatic: you do debate which releases should be the "default" for people to use, yes?
chromatic: I say biannuals, you say monthlies
chromatic Yes.
allison I believe we're talking about different audiences. 22:54
davidfetter the developer audience doesn't need a release number
chromatic Perhaps.
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.
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.
NotFound (Not sure about my translation to english)
chromatic I do think production users should upgrade to monthlies.
They have the option not to.
allison chromatic: okay, that's where we disagree
chromatic but if I were running a development house, they would.
allison I would say they shouldn't upgrade to monthlies, but have the option of doing it if they want to
it's a fine semantic distinction 22:56
chromatic I can't force them to upgrade. I can recommend that they do.
Tene_ why should they avoid monthlies?
chromatic We *can* encourage them to do so with our bug fixing policies.
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.
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
chromatic I thought we had agreed to avoid strawmen.
allison chromatic: I don't see how that's a strawman
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 :)
NotFound I think avoiding a segfault is not just a policy detail.
chromatic So is "OMG! IT TAKEZ A WEEK TO UPGRADESZ! NOOOOES!"
allison chromatic: actually, I think that's a non-sequitur 22:59
chromatic Okay, well I thought we agreed to avoid those too.
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.
NotFound The virtual machine must not segfault. If it does, is a serious bug.
allison hey, I'm not the one who brought up naked taffy rain dances :)
chromatic You brought up the FUD that it takes a week per month to upgrade to a monthly.
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.
allison for an expert, no, it won't take that long
chromatic Did you *measure* it?
allison it's an estimate
chromatic Based on?
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
pmichaud I would think that a shop running mod_pipp would upgrade based on the mod_pipp upgrade cycle, not the Parrot one.
allison pmichaud: yup
chromatic Yeah, they count as HLL users in my mind.
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
pmichaud I'm not forgetting that at all.
chromatic Not until 2.0.
allison as opposed to a free for all where every language synchronizes to a different random monthly release
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.
allison pmichaud: yes 23:03
NotFound pmichaud: but having each tool based on a different point will not help.
chromatic If only we had some way of encouraging each language to target a specific point...
allison where chromatic and I disagree (as I understand it), is what we suggest the tools synchronize to
pmichaud NotFound: I agree, if each tool takes a different point, that won't help.
(more)
However, I don't think we're going to have to deal with synchronization points until after 2.0, at the earliest.
NotFound pmichaud: I agree on that 23:04
allison pmichaud: I agree
1.0 and 1.4 are more practice runs
that is, we won't know where the pain points of synchronizing are until we actually try it a few times
pmichaud I don't even know who is going to try before 2.0, to be honest.
allison pmichaud: I'm going to try to get 1.0 into Ubuntu 9.10. 23:05
pmichaud: and 'parrot-python' and 'parrot-php'
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.
NotFound And pirric? ;)
allison pmichaud: and maybe 'parrot-perl6'
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?
pmichaud allison: will calling conventions be fixed anytime soon?
chromatic Or MMD?
purl i heard MMD was multi-method dispatch
allison pmichaud: non-critical is supposed to mean... not critical for the release
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.
allison okay, I don't know what's critical for Rakudo
we don't have a Rakudo milestones list
pmichaud we have bug reports and feature requests, though.
Those weren't "wishful thinking" -- they're things that we need in order to implement Perl 6.
allison I don't know what parts of Rakudo are blocking on what parts of Parrot
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.
chromatic Waiting six months for that revision to land in a new stable release is not an option.
pmichaud Rakudo is blocking on pipe I/O, to be able to do qx{}
allison this sounds like a place we need to synchronize better, any suggestions on how?
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
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"
allison since the dev summit, I've been prioritizing based on the milestones
pmichaud but when the branch finally lands, they aren't there.
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.
allison can we make a wiki page?
pmichaud more to the point, Rakudo needs haven't been *critical* Parrot milestones.
which means they're not likely to make it into the 1.0 release.
allison "top feature/fix requests from languages"
pmichaud which means that the 1.0 release isn't likely to be a long-lived target for us. 23:11
even the 0.9.1 release wasn't a valid target for us within 24 hours after its release.
allison pmichaud: yes, for 1.0 it was more important to stabilize the core subsystems
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.
Infinoid does this prevent Rakudo from making distro packages until we hit 1.4? 23:12
pmichaud Infinoid: Rakudo is already making distro packages.
allison what I'm taking away from this is that another addition to the January/July releases will be extensive language testing
pmichaud allison: I did make that point on the mailing list this past week.
chromatic It's not about language testing.
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.
allison that is, explicitly synchronizing between the various independent language projects
pmichaud (where "stable release" here means "deprecation point releases")
allison: did you see my message on parrot-dev about needing to add "language build" as a critical task for parrot stable releases?
allison no
pmichaud you need to read it and comment. 23:14
allison okay, will do
to summarize here and move on:
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.
allison pmichaud: okay, that would be problematic
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 :-|
allison there is a disagreement on whether monthlies or biannuals should be the "default"
pmichaud NotFound: My point is that it was possible for us to have not caught this "serious parrot problem"
NotFound: I agree it's a serious parrot problem. But Parrot's tests didn't catch it.
NotFound pmichaud: yes, we can always make big mistakes.
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
allison so, the documents need to be clear about the risks and advantages of each
chromatic I'm not sure it's practical to build a stable, modern, full-featured HLL on Parrot 1.0. 23:17
allison chromatic: full-featured is not what we promised for 1.0 23:18
(in the sense of "we will add no further features")
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.
GeJ Good morning everyone 23:19
allison summary: I'm still not convinced it's wise to encourage people to upgrade every month. 23:20
summary: Does anyone have a compromise solution?
NotFound The problem in t/pmc/packfileconstanttable.t, TT #385, is not the same that caused the rakudo building segfault?
allison it may be simply "we don't encourage them to do anything"
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.
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.
allison chromatic: yes, that's the key point
23:22 bacek_ joined
allison chromatic: and, we may have to revise as we start getting responses from users 23:22
23:23 klapperl joined
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
chromatic Okay, remove the clause about new features then.
allison chromatic: if we're going to not encourage any particular practice, we have to be completely non-biased in the descriptions 23:24
biannuals are X, monthlies are Y
NotFound allison: reasonably, completely may be impossible.
chromatic "We will provide critical bugfixes for the January and July releases as we deem necessary."
allison clear, measurable distinctions
NotFound If we disagree on each word, surely will be impossible. 23:25
allison chromatic: true in substance, edit for tone
(sound less like Linux Kernel hackers)
chromatic "You suck, you suck, you suck, you're cool, and you suck."
allison yes :)
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."
allison chromatic: something like that
chromatic We can't promise to address or backport everything, but we can promise to try.
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.
allison I'll call that piece wrapped up.
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 ;)
allison final point of contention: what do we call the ftp directories? That is, what do we call the releases?
and, before we get into it, is it the final point?
chromatic Yo estoy el tiburon grande. 23:29
grande y guapo
NotFound chromatic: Yo seré espalda.
allison something about big sharks
or donkeys
chromatic Hasta la manana de manana.
NotFound (Impossible to translate spanish joke on translations) 23:30
chromatic It's difficult with an Austrian accent, certainly.
How about "monthly" and "biannual"?
allison monthly is out, because all releases are monthly 23:31
chromatic symlink to latest_monthly and latest_biannual
allison (both the January/July ones and the other ones
chromatic Or just the symlinks.
Stuff everything in a big bucket of releases.
symlink the latest biannual and the latest
NotFound chromatic: you need a keyboard with a dead ~ 23:32
rurban only the latest symlink?
allison chromatic: could you outline your objections to "stable"/"development"?
rurban ln -s 1.0 latest
chromatic Sure. The opposite of "stable" is "unstable" and "development" doesn't mean anything.
NotFound We can call them magic/maggot
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.
chromatic I'm not in the business of putting out unstable releases.
allison any name will have the meaning we attach to it
we don't call them unstable
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.
allison I'm open to being convinced, I just don't see it.
rurban: the decision is still stable/development, untile we come up with something better
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)
(that's why I wanted to save it until we had cleared up that it was the *only* remaining point of disagreement)
chromatic: what does that mean?
purl That boy needs therapy.
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
chromatic That's not really good enough. The word is too overloaded.
NotFound chromatic: we must answer such questions in a directory name?
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.
Do they work? Yes. Do the development releases work? Yes.
Do they pass their tests? Yes. Do the development releases pass their tests? Yes.
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.
"stable" is 90% of the way there, and we define the remaining 10%
chromatic Has the API changed? From 1.0 to 1.4, yes. In the development releases? Yes.
Are there bugfixes only? No. In the development releases? No. 23:38
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.
Am I missing any other connotations of "stable"?
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
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.
NO
allison chromatic: what?
chromatic CRITICAL bug/security fixes
allison chromatic: we tabled the adjectives discussion 23:40
chromatic I'm untabling it.
NotFound I don't see the problem with the names monthly/biannual
chromatic CRITICAL bug/security fixes
allison NotFound: monthly we can't use 23:41
chromatic Why can't we use "monthly"?
allison (they're all monthly)
biannual doesn't say anything about what the difference between the two is
chromatic There are two of them a year.
There are twelve monthlies a year.
NotFound allison: the biannual is also a monthly? No problem about that for me.
purl okay, NotFound.
allison yeah, what does that mean?
chromatic We have a time-based release schedule is what that means. 23:42
allison chromatic: no, there are 10 non-biannual releases
chromatic Yes, because they're monthly.
allison so are the biannuals
they're all monthly releases
chromatic Yes, they are.
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.
chromatic The January and July releases are also biannual releases.
They receive critical bug and security fixes until the next biannual release.
allison biannual is completely meaningless to anyone outside the project
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.
NotFound Well, if we want to avoid any connotation the name must be meaningless
allison rg: confusing your users before they ever get started is never a good thing
chromatic We don't want to avoid every connotation, just the ones that are misleading.
NotFound chromatic: someone will mislead any 23:45
allison we definitely don't want to start with no connotations
chromatic Yes, but I'm using the reasonable and literate person policy.
NotFound Sometimes I doubt reasonable people does exist %-)
allison if we were going for that we'd have "foo" releases and "bar" releases
NotFound The rest of the time, I'm sure they don't 23:46
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.
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?
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
chromatic "Other members of #ps include allison, cotto, Infinoid, japhb, and Tene."
allison okay, and?
chromatic I didn't say that you're not a good coder. 23:50
Tene_ ;_;
chromatic I merely implied it.
(Please note that I am NOT saying anyone isn't a good coder; it's just an example)
allison this really sounds like a strawman to me
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.
chromatic What makes our "development" releases *not* stable?
Please answer that question.
allison until now, we've been calling all of our releases "development" releases
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
chromatic I don't mind short_support and long_support.
Or monthly_support and biannual_support. 23:53
Whiteknight yay! somebody thinks I'm a good coder
allison NotFound: none of our releases are long term support
LTS is 3 years
Infinoid Whiteknight: I never had a question about that :)
NotFound allison: that's the point. The other hasn't even that.
chromatic No, but that does seem to be the biggest distinction between the monthly and biannual releases.
allison chromatic: it's support, deprecation cycle, and synchronization points for various related projects 23:54
what part of that isn't stable?
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.
I know what "critical bug and security fixes" means. 23:55
allison okay, packaging points
23:55 cas left
NotFound Target points, maybe. 23:55
chromatic I'm not sure the packaging question is relevant now.
allison NotFound: leaves the question "target for what"
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
NotFound allison: then we only have the foo/bar way.
chromatic I'm not even sure we disagree. I just don't care about the packaging question.
japhb [Bikeshed] chromatic, would you mind 'semiannual' rather than 'biannual'? The latter is easily confused with 'biennial'. ( en.wiktionary.org/wiki/biannually )
chromatic semiannual would be fine too. I have no particular care about that bikeshed color.
Tene_ chromatic: "no modifications ever after the next release" certainly implies that it's *more* stable than biannual
allison chromatic: it makes it a development release
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
chromatic How does that make it "unstable"? 23:58
allison it doesn't
it makes it development
Infinoid This goes back to the suggestion in #ps of calling them "supported" rather than "stable"
chromatic Supported is fine.
Provided we're very clear that that's critical bug and security fixes only.
allison supported isn't bad 23:59
NotFound I think we already agreed that no matter what the name is, we must explain.
chromatic Now for a better term than "development".
allison you jump too fast
chromatic Sure, we have to explain, but that explanation can be *three* sentences. I typed them earlier.
allison grasshopper
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.
Infinoid NotFound: Sure, it should be documented either way. I just think "supported" matches reality better than "stable"

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!