Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2009-03-03

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

All times shown according to UTC.

Time Nick Message
01:58 Tene_ joined #parrotsketch
03:55 japhb joined #parrotsketch
04:59 Tene joined #parrotsketch
14:04 Tene joined #parrotsketch
16:10 davidfetter joined #parrotsketch
17:35 masak joined #parrotsketch
17:40 pmichaud joined #parrotsketch
17:44 PacoLinux joined #parrotsketch
17:49 Util joined #parrotsketch
18:07 barney joined #parrotsketch
18:09 Infinoid joined #parrotsketch
18:27 allison joined #parrotsketch
18:32 rurban joined #parrotsketch
18:32 allison Hi all, who's here?
18:33 rurban rurban
18:33 cotto cotto
18:33 * Infinoid
18:34 * Util
18:34 allison let's get started in alphabetical order. cotto?
18:34 * masak
18:35 cotto * finished a couple more PMC ATTR conversions (Key, Sub)
18:35 cotto eor
18:35 allison Infinoid?
18:36 Infinoid I haven't had much time for parrot.  Some minor website and ticket tweaks, not much else.
18:36 Infinoid 1;
18:36 allison masak?
18:36 masak * got some good proto development done
18:36 masak * was granted, along with ihrd and Tene, a grant for the Perl 6 web thingy
18:36 masak * slowly coming back to November development
18:36 masak * some bug reports
18:36 masak .eof
18:36 allison rurban?
18:37 rurban - got single float working, sanitized converters (post 1.0)
18:37 rurban - sanitized native_pbc tests
18:37 rurban - looked into jit for long double and amd64,
18:37 rurban but got no 64bit system for 2 weeks to test
18:37 rurban - all tickets on track
18:37 rurban EOR
18:37 allison Util?
18:37 Util Just now applied r37099 to fix TT#397. I mentioned it pending at the last #ps meeting.
18:38 Util While watching for conflicts last week, saw code problems in src/sub.c, that I am writing a ticket for right now.
18:38 Util I will need other eyes to resolve the issue.
18:38 Util EOR
18:38 * barney came in late
18:38 allison go ahead barney
18:38 barney Pipp:
18:38 barney Added Pipp::Test, without dependency on Parrot::Test
18:38 barney Try to support building with installed Parrot.
18:38 barney Support for 'perl Configure.pl --gen-parrot'
18:38 barney Add src/pmc/Makefile
18:39 barney Build in HEAD might be broken
18:39 barney .eor
18:39 allison anyone else come in?
18:39 allison ok, allison?
18:39 allison - Worked on Debian/Ubuntu packaging, prepping for 1.0.
18:39 allison - Disabled the "EmailVerificationModule" in Trac, so registered users won't be bitten by the bug in TracAccountManager where it displays odd error messages until they verify their email address
18:39 allison - Set up a 'languages' repository and Trac instance.
18:40 allison - A large part of the week was absorbed by OSCON planning, but that's pretty much wrapped up now.
18:40 allison - The primary focus of this week will be ticket resolving.
18:40 allison EOR
18:40 allison Questions?
18:40 Infinoid When parrotcode.org gets aliased to parrot.org, what will happen to planet.parrotcode.org?
18:41 Infinoid (and are there other subdomains I need to worry about?)
18:41 * pmichaud arrives late.
18:42 allison planet.parrotcode.org can stay, though we should make sure it works as both planet.parrotcode.org and planet.parrot.org
18:42 Infinoid Ok, thanks.
18:42 allison Infinoid: I can't think of any other subdomains, but we could ask Robert/Ask for a list of what's currently hosted on their DNS
18:43 allison pmichaud: go ahead and report?
18:44 pmichaud I primarily worked on getting "is export" to work in Rakudo's settings file, added some more metaoperators, answered questions on the mailing list
18:44 pmichaud Currently we're trying to figure out an optimal 'git' workflow
18:44 pmichaud Rakudo.org has now migrated away from being a blog to a more traditional site
18:45 pmichaud Oh, and we issued our first release of Rakudo independent from Parrot (#14, "Vienna")
18:45 pmichaud eor
18:45 Util q1q
18:46 allison returning to questions, Util?
18:46 Util Do Infinoid and I have access to fix dead links in http://www.pugscode.org/ ? If so, where is the entry point?
18:46 pmichaud Util:  I'm pretty sure it's in the svn repo.
18:46 pmichaud if not, it's somewhere on feather -- we can fix it from there.  I'll look around.
18:46 pmichaud might be good to ask on #perl6
18:47 allison yes, good suggestions
18:47 Util Thanks, I should have thought of that. I will look around myself, and query #perl6 if needed.
18:47 rurban 1q me
18:48 allison go ahead rurban
18:48 pmichaud Util:  I'm guessing /data/var/www/pugscode.org
18:48 pmichaud (on feather)
18:48 rurban pbc with --ops and --pmc. we will deprecate the cmdline options I guess. But cannot we do better?
18:49 allison rurban: more detail on the question?
18:49 rurban e.g store the names and not the index in the freeze
18:49 kj joined #parrotsketch
18:49 rurban or store some md5 of all used pmcs and ops and check that
18:49 * kj comes in late.
18:49 rurban just some ideas for 2.6
18:50 particle1 joined #parrotsketch
18:50 rurban this will need a parrot-dev discussion I guess
18:50 allison rurban: okay, write the ideas up into a proposal later in the year
18:51 allison kj: anything to report?
18:51 kj no report, except that I have now access to both windows and MacOS. No activities due to $work :-(
18:51 kj eor
18:52 allison kj: access is good, much testing potential
18:52 kj allison: yes, not too mention that it's **FAST**
18:52 allison particle: anything to report?
18:52 allison kj: fast is also good
18:53 allison or, any more questions?
18:53 allison I have one
18:53 Tene_ joined #parrotsketch
18:54 allison rurban: are you able to compile trunk on cygwin? I can't. It dies in the dynpmc stage.
18:54 rurban I'll try.
18:54 rurban I just fixed the dynpmc trouble two days ago
18:54 allison ok, I didn't try today, so I'll try again
18:54 rurban makefile missed the libs
18:54 allison (after parrotsketch)
18:55 allison okay, good (to get that fixed)
18:56 allison if there are no more questions or reports, will go on to roadmap review
18:56 allison - implement pdd14-numbers
18:57 allison AFAIK, no progress
18:57 allison - pdd26-ast, user docs
18:57 kj for anybody who wants to follow: Roadmap is at: https://trac.parrot.org/parrot/wiki/ParrotRoadmap
18:57 allison pmichaud, tene?
18:57 pmichaud still working on that.  I somewhat expect "user docs" to be part of pct more than the ast itself.
18:57 pmichaud (part of pct docs)
18:58 pmichaud I reviewed WhiteKnight++'s documents and have some patches to make there, will do that today.
18:58 NotFound joined #parrotsketch
18:58 allison pmichaud: aye, so if adequately covered within the pct docs can be considered good
18:58 allison - todo/skip test review
18:58 allison chromatic not here for update
18:58 allison - bug/issue tracking, triage, guidelines
18:59 allison same
18:59 allison - move languages out of repo (or tarball)
18:59 pmichaud on that point, how likely is it that we'll have email-to-trac working before release?
18:59 allison we now have a languages repository to host any remaining languages
18:59 pmichaud (for bug/issue tracking item)
19:00 allison pmichaud: coke's been following up on email-to-trac so I don't know the status
19:00 pmichaud it would be good for us to have a definitive "this is how to submit bug reports" before the release.
19:00 rurban the parrotbug email is also putting tickets into rt
19:01 rurban and not trac
19:01 allison pmichaud: for now that's "submit a ticket through the web interface"
19:01 pmichaud rurban: that's why I brought up this point.  I added a trac ticket about parrotbug.
19:01 allison and really, even when email-to-trac is working, the web interface is the preferred method, because it captures more information from the submitter
19:02 pmichaud (waiting for trac to respond...)
19:02 pmichaud allison: might be worth a note or comment on TT #27, then.
19:03 allison pmichaud: okay, will do
19:03 Tene_ allison: Seems like I have tuits available again.  I was looking to write pdd23 user docs the other day, but didn't know where I should be adding them.
19:04 Tene_ allison: is anything more-specific than "some kind of user docs somewhere" desired?
19:04 allison Tene: great, we're moving that kind of documentation to docs/user
19:05 Tene_ so docs/user/pir/pp00X-exceptions.pod ?
19:05 pmichaud "pp001-intro.pod" ... what does "pp" stand for here?
19:05 pmichaud Tene:  I would think docs/user/exceptions
19:05 pmichaud c.f.   docs/users/pct  (for pct documentation)
19:05 allison Tene: that was a left over from an old naming scheme, you can skip the pp<whatever>
19:05 allison Tene: (and remove it from the old docs too, if you get a tuit)
19:06 Tene_ pmichaud: just docs/user/exceptions.pod ?
19:06 allison I like it
19:06 pmichaud Tene_: docs/user/exceptions/*.pod, I would think.
19:06 pmichaud Tene_: unless it'll be one file, then exceptions.pod would be okay.
19:07 allison start with one file, and split it to a directory if it grows
19:07 Tene_ pmichaud: are you thinking that it should cover more than using exceptions from pir?
19:07 Tene_ from PCT, maybe?  I'm trying to figure out why this is separate from pir/
19:08 pmichaud I'm thinking pir/ is "how to write PIR programs", not "how to solve <subsystem> from PIR"
19:08 pmichaud maybe I'm wrong -- haven't looked at docs/user/ until just now.
19:08 Coke joined #parrotsketch
19:08 allison Tene: there is no docs/pir
19:08 pmichaud allison: there's docs/user/pir
19:08 Tene_ allison: docs/user/pir/
19:09 Tene_ pmichaud: but you're not making recommendations on content with that name.  Okay.
19:09 Tene_ I'll try to start on it tonight.
19:09 * Coke came in late
19:09 pmichaud Tene_: it's more important to write something -- we can (likely will) reorganize it all later anyway :-)
19:09 allison ah, didn't know about the subdirectory, okay, put it in docs/user/pir
19:09 * NotFound also
19:09 * Tene_ also
19:10 kj I wonder, if it's about throwing exceptions in PIR, shouldn't it be part of PIR docs...?
19:10 pmichaud so, in this model, where would pct docs go?
19:10 allison Tene: and definitely only one file then: docs/user/pir/exceptions.pod
19:10 kj pmichaud: i think there's docs/user/pct..
19:10 Tene_ pmichaud: presumably docs/user/pct
19:10 pmichaud kj:  not yet there isn't.
19:10 kj pmichaud: right. thre's docs/pct
19:10 kj so perhaps should move that
19:10 kj into docs/user/pct
19:11 allison kj: is that developer documentation or user documentation?
19:11 kj allison: is there a difference in case of pct?
19:11 kj the users /are/ developers if they use pct
19:11 pmichaud it's for users of pct.
19:11 pmichaud (as opposed to pct developers)
19:11 kj yes, I know. ambiguity
19:11 allison kj: in theory, developer documentation would be for people "developing" pct, while user documentation would be people using it
19:11 kj pmichaud: yes, exactly
19:11 kj allison: what pmichaud says :-)
19:12 allison aye
19:12 allison sounds like this is user documentation
19:12 kj it's written for helping people out to use pct
19:12 kj (i wrote it ;-)
19:12 allison so, move it into user
19:12 pmichaud I'll update it as well.
19:13 allison any objections to moving most of the top level docs into docs/developer?
19:13 allison so we'd have docs/user, docs/book, and docs/developer, and not much else
19:13 kj +1
19:13 pmichaud I wonder if we should reverse that
19:13 pmichaud I wonder if we should have  docs/pct/user  docs/pct/developer
19:14 pmichaud if I'm searching for information, I'm more likely to ask "where can I find information about PCT" than "I'm wanting to be a user of PCT"
19:14 allison pmichaud: for that, I'd say it should be compilers/pct/docs/user
19:14 allison which we then install into the main docs
19:14 pmichaud same for pir, though... I'm thinking docs/pir   instead of docs/user/pir
19:15 Coke "where to find docs" is amelerated by a good index.
19:15 allison the reason for the user/ directory is so new users can go to one place to find what they need
19:15 pmichaud to be honest, I didn't even realize docs/user/ existed until today.
19:15 Coke bah. ameleorated
19:16 Coke allison: new users should go to docs.parrot.org
19:16 allison pmichaud: it was only added a month or two ago, and doesn't actually hold much
19:16 pmichaud to be honest, I would never think to go to docs/user  for whatever I was looking for.  It's just not a common pattern.
19:17 allison the directory structure is the last of our worries at the moment, a bigger concern is that our documentation is.... um... not great
19:17 kj I like pmichaud's idea of switching it around, but not sure whether it's worth the trouble. As long as there's a good TOC, it should be ok.
19:19 Whiteknight joined #parrotsketch
19:19 allison Coke: are you working on docs.parrot.org?
19:19 Coke nothing really to work on. It's just a snapshot of "make html".
19:19 Coke and I'm not working on that atm.
19:20 Infinoid Last I heard, we were having trouble figuring out what the directory structure of that site should look like
19:20 allison Coke: the domain is up, do we have one snapshot on it?
19:20 Coke allison: ask for my report. =-)
19:20 allison right, Coke, anything to report? :)
19:20 Coke * Continuing TWIP.
19:20 Coke * I am not doing anything with email2trac. I'm just pointing out the lack
19:20 Coke of progress; I think it was infinoid that was working with one of the OSU
19:20 Coke folks.
19:20 Coke * ripped out -j and friends.
19:20 Coke * going through tickets (esp. deprecation tickets). There are many deprecation tickets with "before 1.0" on them. Many of these are waiting for feedback by someone who knows what they are doing. In most of the remaining cases, this isn't me.
19:20 Coke * languages hosted on parrot.org? Feel free to take over this 1.0 task from
19:21 Coke me since I'm out of the loop here.
19:21 Coke * as mentioned in twip and the ticket; docs.parrot.org has a copy of the 0.9.1 release docs.
19:21 Coke I have a question. EOR.
19:22 kj http://docs.parrot.org/ doesn't work..
19:22 Whiteknight (sorry I'm so late, network at work is garbage)
19:22 allison http://docs.parrot.org/ gives me 403 Forbidden
19:22 Coke The url from twip is:
19:22 allison probably just a permissions problem, can get that fixed quickly
19:23 Coke http://docs.parrot.org/par​rot/0.9.1/html/index.html
19:23 Coke no. there is no top level html file atm.
19:23 Coke we could easily have it redirect to the latest release of the docs.
19:23 Infinoid I was begging for a static symlink or somesuch that I can permanently link to, at one point.  Dunno if that ever got done
19:23 kj basically no TOC then?
19:23 allison okay, then we need one. And that is easily fixed
19:23 Infinoid (without the version number)
19:23 Coke I can add the redirect to the 0.9.1 docs.
19:23 allison kj: that index.html is the TOC, but it needs work
19:24 Coke Infinoid: that was stopped because of my queued question.
19:24 allison kj: feel free to work on it
19:24 allison Coke: thanks for TWIP, it's great to get the regular news reports
19:24 kj would that be static html writing?
19:24 Coke (any improvements to "make html" will be noted in the next release, and in teh snapshot.
19:24 kj Coke++ #TWIP
19:24 Coke kj: no. just make "make html" nicer.
19:24 allison kj: it's the 'make html' target
19:25 allison kj: a bunch of perl modules
19:25 allison subclasses of Pod::Simple
19:25 kj mmm. not sure if have time to figure that out this week.. kinda up the walls here.
19:25 allison Coke: you had a question?
19:26 allison kj: no worries, I can keep working on it
19:26 Coke Yes. There is apparently a discussion that needs to happen about our releases / support policy. You and chromatic seem to have very different ideas of what, say, the 1.1 release indicates.
19:27 pmichaud (I also have a comment that I think we should not use the term "milestone release")
19:27 pmichaud (at least, not to indicate the six monthish releases)
19:27 Coke I know we had the email regarding the numbers, but I don't think we addressed what kind of release 1.1 is going to be.
19:27 allison Coke: yes, we talked about it last wednesday, and it turns out we did have a different idea of what was going on
19:27 Coke development? stable?
19:27 allison Coke: seems to be resolved now
19:28 Coke ORLY? because I haven't seen any clarification anywhere.
19:28 allison 1.1 is development
19:28 Infinoid I tend to agree with chromatic's view that every release should be considered "stable"
19:28 Coke that is not the impression i had from chromatic the last time I talked to him on IRC.
19:28 Infinoid but less-loaded terminology like "latest" works equally well for me
19:28 allison Coke: as far as I can tell, our public docs are consistent
19:29 Coke allison: really? did you update your vision document?
19:29 allison Coke: so it was more a matter of synchronizing the understanding behind the docs
19:29 Coke allison: right now, you seem to understand one thing, and chromatic seems to understand something else.
19:29 pmichaud docs/project/support_policy.pod  still says 1.0, 1.5, 2.0, 2.5,
19:29 allison Coke: nothing's changed there, except the version numbers
19:29 Coke then there's a problem.
19:29 allison okay, chromatic may still be confused, but that doesn't mean everyone needs to be confused
19:29 Coke ... I am confused.
19:30 pmichaud I am also confused.
19:30 allison ok, then let's get you unconfused, and not worry about chromatic
19:30 Coke or rather, I think I know what you mean, but there's a lot of disagreement.
19:30 allison so, what are you confused about?
19:30 Coke what does 'development release' mean?
19:30 Coke since that doesn't appear anywhere but your vision doc, I have no clue.
19:30 allison a development release means we won't support it with bug/security fixes later
19:31 allison it's just a monthly release, and if you need fixes you upgrade to the next monthly
19:31 Infinoid does that mean "don't bother reporting bugs"?  or just "there won't be a $VERSION.1 point release for any issues we find"?
19:31 allison Infinoid: the latter
19:31 Coke I don't think we ever want to not have people report bugs.
19:32 Infinoid Yeah, that's the answer I was hoping for.
19:32 allison Infinoid: do report bugs, but we won't release 1.1.1 with bug fixes, we'll just release 1.2
19:32 Infinoid whereas we will get stuck maintaining 1.2 and 1.0.1 branches
19:32 allison and, if you're still using 1.1 a year later, and report a problem we've already fixed in 1.4 or 2.0, we'll tell you to upgrade
19:32 NotFound I'd like to have tons of people trying to report bugs but being unable to find one ;)
19:32 pmichaud I don't like the negative definition there, though (more)
19:33 pmichaud instead of saying "a developer release is one where we won't support it with bugfixes", I'd prefer us to say "a <something> release is one that receives support and bugfixes"
19:33 Infinoid specifically meaning, backported fixes
19:33 allison yes, we usually define it by "what's special about a stable release"
19:34 Coke allison: you and chromatic use the word stable differently.
19:34 allison rather than "what's different about a develoment release"
19:34 allison Coke: yes
19:34 Coke so, whose names are we using?
19:34 allison Coke: but stable is an industry-wide standard
19:34 pmichaud Based on the definitions we have at the moment, I'd prefer "supported release" to "stable release"
19:34 NotFound We can call it 'target' release, because will be the target for language and module creators and distro packagers, if we don't like the connotations of 'stable'
19:35 Infinoid pmichaud: Me too.
19:35 allison pmichaud: that's just going to confuse people
19:35 Coke I don't care, really. I just want /our/ docs to be self consistent.
19:35 pmichaud "stable" in the industry doesn't mean what "stable" is being used for here.
19:35 pmichaud at least, not in the way I've been seeing it.
19:35 Infinoid "supported" is definitely more accurate than "stable" for this usage
19:36 allison all it really boils down to is "what do we call the FTP directories. They're currently "devel" and "stable", the same as Perl, debian, etc
19:36 Coke perl's devel means something else, though, doesn't it?
19:36 allison Coke: it means the same thing as our monthly releases, just on a much slower timescale
19:36 Coke really? because I would never install 5.9.x in production.
19:37 allison that is, "you can use this, but it's not recommended for production, and we won't support it after the next stable release"
19:37 Coke and I would expect to be able to install parrot 1.3
19:37 allison 1.3 should not be used in production
19:37 allison 1.0 should, 1.4 should
19:37 Infinoid ... ouch.
19:37 Coke that is not my expectation. (nor was it chromatics)
19:37 Coke (when last I spoke to him.)
19:37 pmichaud (nor is it what is commonly used in the industry)
19:38 allison we're moving away from monthly releases because that's far too rapid a timescale for the average user
19:38 allison so, we define 2 points a year January and July where they really should upgrade
19:38 Coke why then are we even numbering the monthlies?
19:38 allison Coke: because we always have
19:38 pmichaud then we should stop.
19:39 Coke if we're changing what they /mean/, then we should make them look different. IMO.
19:39 pmichaud the monthly numbers are what are confusing.
19:39 pmichaud or at least part of the confusion.  I mean, I can keep it straight, but I can't explain it to others.
19:39 Infinoid I would always consider 1.1 to be better than 1.0
19:39 allison in terms of changes that are going to go over well with the team, I'd say eliminating version numbers on the monthlies just isn't going to fly
19:39 pmichaud really?  I don't know that it's been seriously proposed or discussed.
19:39 Coke allison: people complained about the version numbers because of a deeper confusion as to what the hell the plan was.
19:40 allison okay, let me take a step back and explain the fundamental tension here
19:40 allison chromatic wants to continue on a monthly schedule as we have always done, and doesn't want to add any special value to any releases (at least, that's what I understand)
19:40 allison (he's not here to clarify)
19:41 pmichaud I don't understand "don't add any special value to any releases"
19:41 Infinoid I would prefer that we try really hard to make sure *all* of our releases are production-worthy
19:41 allison but, for interacting with outside users, which we really have to do now, we cannot expect users to upgrade every month
19:41 pmichaud ("value" is ambiguous for me here)
19:41 allison we cannot expect distributions to upgrade to each monthly parrot release
19:42 Infinoid Right.  But a user who is following the "industry standard" concepts of release numbering will always grab 1.3 preferentially to 1.0
19:42 allison so, we have to pick certain releases as standard, and decide to put in extra effort on bug-fixing and packaging on those releases
19:43 allison Infinoid: what I expect to happen, is that people will catch on to the X.0 series, and ignore the others
19:43 NotFound Adn recommend such release as target for language and module releases.
19:43 allison NotFound: exactly
19:43 allison it really doesn't matter how we number those "stable" releases
19:43 allison we just have to pick something and stick with it
19:43 Coke allison: as an example: with your scheme, 1.4 is a big release. 1.5 is really "release candidate for 2.0"
19:44 Coke yes?
19:44 pmichaud except that there's an industry perception about numbering that we have to consider.
19:44 pmichaud (thus it does matter how we number the "stable" releases)
19:44 allison basically, except "release candidate" is a dirty word (I do agree with chromatic on that)
19:44 Coke (since we may put in/rip out a ton of stuff immediately after the 1.4 release is cut.)
19:44 allison Coke: yes
19:44 NotFound I don't see any industrial negative effect with Ubuntu atypical version numbering, for example.
19:45 pmichaud NotFound: because ubuntu's numbers are strictly date based.
19:45 NotFound pmichaud: because they clearly explains what it means, IMO
19:45 Coke ok. I'm willing to defer on that argument until we resolve whether or not we're going to have devel releases or not.
19:45 pmichaud NotFound: and because ubuntu does expect users to use every release.
19:45 allison pmichaud: yes, and that's why I was leaning toward X.0 and X.5, so we'd have some consistent face to present, but the half-year releases are not that important
19:45 pmichaud NotFound: i.e., there's no notion of "we're releasing this for our developers, but not for the average user"
19:45 pmichaud (in the Ubuntu case)
19:45 allison Coke: that much is decided, we're not changing the monthly cycle
19:46 allison Coke: it's valuable for training up new release managers
19:46 Coke allison: that's not what I mean.
19:46 pmichaud allison: I don't think anyone is proposing that we eliminate the monthly cycle.
19:46 allison Coke: and for a regular cycle of bugfixes
19:46 allison Coke: okay
19:46 Infinoid allison: For upgrades, its true that they're more likely to go to X.0.  I'm thinking about new installations though
19:46 Coke I mean whether or not 5/6 of our releases are going to be "throwaway".
19:47 allison Infinoid: new installations should also go for 1.0 and 1.4, not 1.3
19:47 Coke or "devel", or "not stable".
19:47 pmichaud where "throwaway" means "not recommended for production"
19:47 allison doesn't matter what you call them, but yes, 5/6 will be not recommended for production
19:47 NotFound New installations in most cases will be done with: "aptitude install parrot" and equivalents.
19:47 Infinoid Assuming 1.4 is there.  And 1.4 has been released.  And the user has some way of knowing that he/she should avoid the latest (non-supported) release
19:47 pmichaud *that's* what's odd -- the release numbers don't give any indication of "production" versus "non-production" unless you bother to read our support documents.
19:47 Coke ok. I think that point is still being discussed, but it sounds like you have decided that this is how it is.
19:48 allison or, more to the point, they'll be available for people who want to fly a little closer to the edge
19:48 Infinoid "release candidate" is ugly, but we could just call the rest of them "monthly snapshots"
19:48 allison Infinoid: snapshots makes them sound too throwaway
19:48 Infinoid That's exactly what we're doing, though.  So it seems to match reality
19:48 Coke allison: but it sounds like they /are/ throwaway.
19:48 Coke (from your standpoint.)
19:49 allison Coke: it's the only thing that meets the requirements of providing a sane, stable interface for users
19:49 Coke allison: which is the only thing?
19:49 allison Coke: defining some releases as recommended for production
19:49 NotFound I think that instead of worrying too much about names and numbers connotations we must put care in having a good document that clearly explains what is the version intended to production installations and packagers.
19:50 allison and, more importantly, we don't have the developer resources to provide production support for every monthly release
19:50 allison we'd be killing ourselves
19:50 pmichaud NotFound: if our numbering system is too strange, no amount of documentation will help.
19:50 Coke NotFound: at this point, I'm still trying to resolve what is intended by the release, not what it's called.
19:50 allison 2 releases a year, we can manage
19:50 Coke once we know what it /means/, we can come up with names that reflect that.
19:50 Coke that was part of the confusion.
19:50 allison 1 release a year we can certainly manage
19:50 Infinoid The thing is, the end users don't really care about parrot at all.  If the HLL maintainers get this right (and clearly mention the right version in their docs or install one automatically), I think that should work fine.
19:51 allison I think they're a psychology barrier here
19:51 Coke Infinoid: I'd agree with that if we knew what HLL interaction was going to look like.
19:51 Infinoid Coke: Hi, Mr. HLL maintainer!  What do you think it should look like?  :)
19:51 allison we're not saying that the monthly releases become somehow less than the releases we've been making the past 3 years
19:51 Coke Infinoid: I think it should work. I'm not competant to design it, or I'd have done it already.
19:52 allison they are exactly as important and as stable as our previous monthly releases
19:52 pmichaud allison: this is part of the issue with calling the 6-month releases "stable releases"
19:52 NotFound Coke: I added today a pir example of HLL interaction at work
19:52 pmichaud it somehow implies that the monthlies are less than they were before.
19:52 allison but the January and July releases are something more than any of the releases we've done before
19:52 NotFound examples/pir/interlangs.pir
19:52 allison pmichaud: technically, we've only had development releases until this month
19:53 pmichaud allison: I have no argument with that.
19:53 allison Coke: HLL interaction is 1.4, we will get there :)
19:54 Coke allison: assigning particular features to particular releases is another concern of mine. I'm sure we'll get there eventually (it's the main reason I'm here.)
19:54 rurban I have a packager problem with the languages. Easiest now is make -C languages co-all; make -C languages all. But I need consistent and reproducible language releases, not a random checkout state.
19:55 allison Coke: it was the best way to plan out progress
19:55 cotto So if we're recommending the 1.0, 1.4, 2.0, etc releases for general use, are we providing bugfix releases for the most recent of those (and for which kinds of bugs)?
19:55 allison Coke: it doesn't mean we're fixed in concrete
19:55 Coke rurban: language packaging should be driven by the languages, not by parrot.
19:55 rurban So I need a makefile with the language version numbers. And where to get them.
19:55 PerlJam speaking from the peanut gallery, I think users only really care what releases they can get support for.   If you're consistent about saying that the .0 and .5 releases have support and the others do not have support (but are still "stable"), then that sounds fine to me.
19:55 NotFound Coke: I said last week: It's like TAP, we have a plan, but we can skip ;)
19:56 allison cotto: critical bugs and security fixes will be backported to the stable releases
19:56 allison NotFound: yes :)
19:57 Coke Ok. /if/ we go with 2 a year being 'special', and the others just being 'monthlies' (insert your favorite words here) ...>
19:57 allison rurban: the languages are all moving out of the repository, so you have a different packaging problem
19:57 pmichaud rurban: I don't think we expect Parrot's Makefiles to build the languages.
19:57 Coke Then if we have two different kinds of releases, I would recommend calling them two different things.
19:57 allison Coke: yes
19:58 allison Coke: and agreed on calling them two different things
19:58 rurban I only have the co-all problem, which needs to be replaced with tar ball urls. Hmm
19:58 Coke because the scheme we ended up with was kind of predicated on part of chromatic's argument about how releases were going to work.
19:58 allison rurban: each language should be a separate package
19:58 rurban yes, as with fedora
19:58 Coke rurban: I don't think it's reasonable for parrot to keep track of the language's releases and repositories and recommend versions.
19:58 allison Coke: you mean 1.0, 1.1, 1.2, 1,3...?
19:59 pmichaud I think it's always been understood (at least by me) that we would have two different kinds of releases.
19:59 pmichaud I think even chromatic recognizes that.
19:59 Coke allison: I think with our current scheme, calling the first 'special' release 1.0 and the first 'monthly' 1.1 will only confuse.
19:59 Coke pmichaud: part of the issue is how those releases would differ.
19:59 pmichaud Coke: the special releases have extra care put into them, and receive backports
19:59 pmichaud Coke:  the other releases don't
19:59 allison Coke: I don't hold that particularly strongly, but I also don't have any other suggestions that would be clearer
19:59 rurban cannot we say x.0 is stable, x.4/6 is a deprecation point and the rest are unstable, devel releases?
20:00 allison we could do 1.0 and 1.4.0, 1.4.1, 1.4.2, 1.5
20:00 allison rurban: yes
20:00 Coke perl's odd numbering scheme doesn't look so crazy now, does it? =-)
20:01 allison rurban: I expect that's how most external users will handle it, no matter what we call the releases internally
20:01 pmichaud Coke: this is exactly what chromatic has been saying, except that chromatic called the 'special' releases "milestone releases" and the other releases "stable releases"
20:01 Coke pmichaud: I did not get the impression that his only difference was naming.
20:01 allison pmichaud: yep, like I said, our external documents are consistent aside from naming
20:01 Coke I got the impression that he saw no reason to discourage, say, 1.1 from going into prod.
20:01 pmichaud Coke:  "Parrot currently follows a monthly cycle; we produce a new stable release of
20:01 pmichaud Parrot on the third Tuesday of each month.  This will continue into the
20:01 pmichaud forseeable future.
20:01 pmichaud (from suppor_policy.pod)
20:02 pmichaud However, we will concentrate our efforts to produce two milestone releases each
20:02 NotFound Coke: that was before we mentioned the problem with language developers and packegers
20:02 pmichaud year, one in January and one on July."
20:02 allison Coke: btw, chromatic did entirely agree with me on not porting bug/security fixes back to the monthly releases
20:03 allison so, we all agree there are fundamental differences between the regular monthly releases and the January/July releases
20:03 Coke *sigh* work beckons.
20:03 Coke left #parrotsketch
20:03 allison we have been running too long on this
20:04 rurban s/we produce a new stable release (of.*each month)/we produce a new release \1/g
20:04 NotFound We can take a cuantum physics approach and call such releases 'charm' or such
20:04 allison at the end of the day, it really doesn't matter
20:04 allison I'm happy with the compromise we worked out
20:04 NotFound Words free of connotations
20:04 Infinoid Hmm.  I still think that provided we get the dependency information right between parrot and the HLLs, the user won't have to care which version gets installed because the right thing will happen automatically
20:05 Infinoid The only reason why I originally brought this up is because I want a docs.parrot.org/parrot/latest/ or docs.parrot.org/parrot/stable/ or *anything* I can link to without having to change it every time we release
20:05 allison Infinoid: that's unlikely to happen before 3.0,
20:05 allison it would limit the options for further development of Parrot
20:06 pmichaud allison:  with the compromise that's been worked out, what are the canonical terms for the 'special' and 'monthly' releases?
20:06 NotFound Infinoid: Ideally each language and module must have an x.y or later, but I don't expect such and ideal world.
20:07 allison pmichaud: the compromise was mainly about version numbers, I suspect the special/monthly terms are what's still not at consensus
20:07 pmichaud allison: agreed; I was kind of asking for a decision as opposed to a report :-)
20:08 pmichaud or at least something we can use in the interim to update the existing support_policy.pod to try to reduce some of the confusion.
20:08 allison the decision is still stable/development, because I haven't heard anything clearer
20:08 pmichaud okay, so Jan+Jul releases are "stable release", other releases are "development releases"
20:08 pmichaud I can live with that.
20:08 allison pmichaud: aye
20:08 Infinoid Should the website docs always link to the most recent stable, or the most recent (whatever) release?
20:09 pmichaud I agree that people will get confused by   1.3 not stable, 1.4 stable, 1.5 not stable, 1.6 not stable, etc.... but it's not really that big an issue.
20:09 allison Infinoid: it should have two links, one to stable one to devel
20:09 allison (similar to the Perl download page)
20:09 particle1 i'd really to see 1.6 as stable, if 2.6 and 3.6 are also stable
20:09 allison pmichaud: I think so too, but I also think they'll just end up following 1.0, 2.0, etc
20:09 Infinoid allison: Ok.  But where should users go by default?  I need something to bounce the old pod2html pages from parrotcode.org to
20:09 rurban I've tried a diff at http://nopaste.snit.ch/15762
20:09 Infinoid And to link from www.parrot.org/dev, etc.
20:10 allison Infinoid: those pages are going away
20:10 particle1 as far as naming is concerned, consistency is more important than logic.
20:10 allison Infinoid: change the text and link them to www.parrot.org/downloads
20:10 * pmichaud barrages particle with an infinite number of water balloons.
20:11 Infinoid Should I not add bounces for them, then?  This is a good portion of my list of parrotcode.org links to make parrot.org handle
20:11 allison sorry, download, not downloads
20:11 pmichaud it would not bother me to go     1.0, 1.1, 1.2, 1.3, 1.6, 1.7, 1.8, ...
20:11 pmichaud i.e., to skip from .3 to .6
20:11 allison Infinoid: ah, you're talking about aliases on the new site, yes, those are good
20:12 allison Infinoid: was /dev a direct link to the tarball?
20:12 Infinoid allison: I don't mind getting rid of those old links... they're all pretty disorganized.  but now I'm wondering exactly what my task should be :)
20:12 particle1 or 1.0, 1.3, 1.4...
20:12 rurban or better skip 1.1 and 1.2 and go directly to 1.4 for april
20:12 pmichaud somehow the jump from 1.3 to 1.6 bothers me less than a skip from 1.0 to 1.4
20:12 particle1 april is 1.3
20:12 rurban oops 1.3
20:12 pmichaud or 1.3
20:12 allison Infinoid: yes, making redirects for the old pages is good, we have a lot of Google traffic for them and it would be a shame to lose that traffic
20:12 pmichaud if we go 1.0 to 1.3, then people will ask "what happened to 1.1 and 1.2?" (more)
20:12 Infinoid allison: Sorry, I was just talking about www.parrotcode.org/cage-cleaners/guide.html, www.parrotcode.org/faq/, www.parrotcode.org/glossary.html, www.parrotcode.org/docs/, not the tarball.
20:12 pmichaud if we go 1.3 to 1.6, then we can say "it's a stable release, so it gets the .6"
20:13 pmichaud (I think this came up on the mailing list already also :-)
20:13 rurban agreed
20:13 particle1 pmichaud: 1.0 is a stable release, that's two months late :)
20:13 pmichaud particle1: not at all, it's exactly when we said it would be :-)
20:14 allison Infinoid: let's carry the website questions to #parrot
20:14 allison on version numbers, there is no perfect answer
20:14 pmichaud it simplifies things slightly if we can refer to .0 and .6 releases as always being stable releases.
20:14 allison whatever we pick, we'll have to explain
20:15 allison another factor is that the half-yearly stable releases won't continue after 4.0
20:15 pmichaud I think it's easier to explain the jump from .3 to .6 than it is to explain that 1.4 is a stable release.
20:15 allison so, we're really only talking about 3 special half-yearly releases
20:15 pmichaud allison: I can conceive that we might stick with half-yearly stable releases after 4.0.
20:15 allison it doesn't matter so much if they're consistent, because it's not a long-term pattern
20:16 allison pmichaud: maybe, but then we might not even have 3.6
20:16 pmichaud I wouldn't want to speculate too much about that far in the future, or let it be too much of a driver for our present decisions
20:16 pmichaud so if it's easier to say "always .0 and .6 for now", we should do that.
20:16 NotFound Someone said: "In the long term, all dead"
20:16 pmichaud NotFound: Keynes
20:16 allison it's easiest to say "January and July"
20:17 pmichaud well, that's what I've been generally doing, yes.
20:17 particle1 enero x julio
20:17 pmichaud maybe I can do that with the docs.
20:17 allison and "whatever version number happens to fall in January or July
20:17 particle1 er, y
20:17 particle1 numbers are already localized.
20:17 allison (with a special exception for 1.0, which isn't January)
20:17 pmichaud surely it's January somewhere in the world, like timezones?  ;-P
20:17 allison but on going into the future it's Jan/Jul
20:17 allison pmichaud: :)
20:18 pmichaud I'll see if I can update support_policy.pod with the new information.
20:19 allison pmichaud: okay, thanks!
20:20 allison any other questions before we wrap up for the week?
20:20 pmichaud I'm wrapped.
20:20 Util Earlier, I asked for extra eyes on a not-yet-ticketed problem.
20:20 Util The ticket is TT#398, and the relevant eyes are most probably pmichaud and/or cotto's.
20:20 NotFound Who pays the beers?
20:21 allison that's a wrap everybody, thanks!
20:21 rurban yes, I want to rename sun4 to sparc
20:21 rurban But we can do this in 1.6 also
20:22 * Util moves to #parrot
20:22 allison left #parrotsketch
20:22 Util left #parrotsketch
20:22 rurban left #parrotsketch
20:22 Infinoid left #parrotsketch
20:22 NotFound left #parrotsketch
20:25 particle1 left #parrotsketch
20:25 pmichaud left #parrotsketch
20:30 masak left #parrotsketch
20:32 PacoLinux left #parrotsketch
21:25 rdice joined #parrotsketch
22:03 Whiteknight joined #parrotsketch

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