Parrotsketch Every Tuesday @ 18:30 UTC | IRC Log at irclog.perlgeek.de/parrotsketch/today
Set by moderator on 18 February 2009.
01:58 Tene_ joined 03:55 japhb joined 04:59 Tene joined 14:04 Tene joined 16:10 davidfetter joined 17:35 masak joined 17:40 pmichaud joined 17:44 PacoLinux joined 17:49 Util joined 18:07 barney joined 18:09 Infinoid joined 18:27 allison joined 18:32 rurban joined
allison Hi all, who's here? 18:32
rurban rurban 18:33
cotto cotto
Infinoid
Util 18:34
allison let's get started in alphabetical order. cotto?
masak
cotto * finished a couple more PMC ATTR conversions (Key, Sub) 18:35
eor
allison Infinoid?
Infinoid I haven't had much time for parrot. Some minor website and ticket tweaks, not much else. 18:36
1;
allison masak?
masak * got some good proto development done
* was granted, along with ihrd and Tene, a grant for the Perl 6 web thingy
* slowly coming back to November development
* some bug reports
.eof
allison rurban?
rurban - got single float working, sanitized converters (post 1.0) 18:37
- sanitized native_pbc tests
- looked into jit for long double and amd64,
but got no 64bit system for 2 weeks to test
- all tickets on track
EOR
allison Util?
Util Just now applied r37099 to fix TT#397. I mentioned it pending at the last #ps meeting.
While watching for conflicts last week, saw code problems in src/sub.c, that I am writing a ticket for right now. 18:38
I will need other eyes to resolve the issue.
EOR
barney came in late
allison go ahead barney
barney Pipp:
Added Pipp::Test, without dependency on Parrot::Test
Try to support building with installed Parrot.
Support for 'perl Configure.pl --gen-parrot'
Add src/pmc/Makefile
Build in HEAD might be broken 18:39
.eor
allison anyone else come in?
ok, allison?
- Worked on Debian/Ubuntu packaging, prepping for 1.0.
- 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
- Set up a 'languages' repository and Trac instance.
- A large part of the week was absorbed by OSCON planning, but that's pretty much wrapped up now. 18:40
- The primary focus of this week will be ticket resolving.
EOR
Questions?
Infinoid When parrotcode.org gets aliased to parrot.org, what will happen to planet.parrotcode.org?
(and are there other subdomains I need to worry about?) 18:41
pmichaud arrives late.
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.
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
pmichaud: go ahead and report? 18:43
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
Currently we're trying to figure out an optimal 'git' workflow
Rakudo.org has now migrated away from being a blog to a more traditional site
Oh, and we issued our first release of Rakudo independent from Parrot (#14, "Vienna") 18:45
eor
Util q1q
allison returning to questions, Util? 18:46
Util Do Infinoid and I have access to fix dead links in www.pugscode.org/ ? If so, where is the entry point?
pmichaud Util: I'm pretty sure it's in the svn repo.
if not, it's somewhere on feather -- we can fix it from there. I'll look around.
might be good to ask on #perl6
allison yes, good suggestions 18:47
Util Thanks, I should have thought of that. I will look around myself, and query #perl6 if needed.
rurban 1q me
allison go ahead rurban 18:48
pmichaud Util: I'm guessing /data/var/www/pugscode.org
(on feather)
rurban pbc with --ops and --pmc. we will deprecate the cmdline options I guess. But cannot we do better?
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
rurban or store some md5 of all used pmcs and ops and check that 18:49
kj comes in late.
rurban just some ideas for 2.6
18:50 particle1 joined
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
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 :-(
eor
allison kj: access is good, much testing potential 18:52
kj allison: yes, not too mention that it's **FAST**
allison particle: anything to report?
kj: fast is also good
or, any more questions? 18:53
I have one
18:53 Tene_ joined
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.
I just fixed the dynpmc trouble two days ago
allison ok, I didn't try today, so I'll try again
rurban makefile missed the libs
allison (after parrotsketch)
okay, good (to get that fixed) 18:55
if there are no more questions or reports, will go on to roadmap review 18:56
- implement pdd14-numbers
AFAIK, no progress 18:57
- pdd26-ast, user docs
kj for anybody who wants to follow: Roadmap is at: trac.parrot.org/parrot/wiki/ParrotRoadmap
allison pmichaud, tene?
pmichaud still working on that. I somewhat expect "user docs" to be part of pct more than the ast itself.
(part of pct docs)
I reviewed WhiteKnight++'s documents and have some patches to make there, will do that today. 18:58
18:58 NotFound joined
allison pmichaud: aye, so if adequately covered within the pct docs can be considered good 18:58
- todo/skip test review
chromatic not here for update
- bug/issue tracking, triage, guidelines
same 18:59
- move languages out of repo (or tarball)
pmichaud on that point, how likely is it that we'll have email-to-trac working before release?
allison we now have a languages repository to host any remaining languages
pmichaud (for bug/issue tracking item)
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.
rurban the parrotbug email is also putting tickets into rt
and not trac 19:01
allison pmichaud: for now that's "submit a ticket through the web interface"
pmichaud rurban: that's why I brought up this point. I added a trac ticket about parrotbug.
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
pmichaud (waiting for trac to respond...) 19:02
allison: might be worth a note or comment on TT #27, then.
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.
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
Tene_ so docs/user/pir/pp00X-exceptions.pod ? 19:05
pmichaud "pp001-intro.pod" ... what does "pp" stand for here?
Tene: I would think docs/user/exceptions
c.f. docs/users/pct (for pct documentation)
allison Tene: that was a left over from an old naming scheme, you can skip the pp<whatever>
Tene: (and remove it from the old docs too, if you get a tuit)
Tene_ pmichaud: just docs/user/exceptions.pod ? 19:06
allison I like it
pmichaud Tene_: docs/user/exceptions/*.pod, I would think.
Tene_: unless it'll be one file, then exceptions.pod would be okay.
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?
from PCT, maybe? I'm trying to figure out why this is separate from pir/
pmichaud I'm thinking pir/ is "how to write PIR programs", not "how to solve <subsystem> from PIR" 19:08
maybe I'm wrong -- haven't looked at docs/user/ until just now.
19:08 Coke joined
allison Tene: there is no docs/pir 19:08
pmichaud allison: there's docs/user/pir
Tene_ allison: docs/user/pir/
pmichaud: but you're not making recommendations on content with that name. Okay. 19:09
I'll try to start on it tonight.
Coke came in late
pmichaud Tene_: it's more important to write something -- we can (likely will) reorganize it all later anyway :-)
allison ah, didn't know about the subdirectory, okay, put it in docs/user/pir
NotFound also
Tene_ also
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?
allison Tene: and definitely only one file then: docs/user/pir/exceptions.pod
kj pmichaud: i think there's docs/user/pct..
Tene_ pmichaud: presumably docs/user/pct
pmichaud kj: not yet there isn't.
kj pmichaud: right. thre's docs/pct
so perhaps should move that
into docs/user/pct
allison kj: is that developer documentation or user documentation? 19:11
kj allison: is there a difference in case of pct?
the users /are/ developers if they use pct
pmichaud it's for users of pct.
(as opposed to pct developers)
kj yes, I know. ambiguity
allison kj: in theory, developer documentation would be for people "developing" pct, while user documentation would be people using it
kj pmichaud: yes, exactly
allison: what pmichaud says :-)
allison aye 19:12
sounds like this is user documentation
kj it's written for helping people out to use pct
(i wrote it ;-)
allison so, move it into user
pmichaud I'll update it as well.
allison any objections to moving most of the top level docs into docs/developer? 19:13
so we'd have docs/user, docs/book, and docs/developer, and not much else
kj +1
pmichaud I wonder if we should reverse that
I wonder if we should have docs/pct/user docs/pct/developer
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
which we then install into the main docs
pmichaud same for pir, though... I'm thinking docs/pir instead of docs/user/pir
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
pmichaud to be honest, I didn't even realize docs/user/ existed until today.
Coke bah. ameleorated
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
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.
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
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".
and I'm not working on that atm.
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?
Coke allison: ask for my report. =-)
allison right, Coke, anything to report? :)
Coke * Continuing TWIP.
* I am not doing anything with email2trac. I'm just pointing out the lack
of progress; I think it was infinoid that was working with one of the OSU
folks.
* ripped out -j and friends.
* 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.
* languages hosted on parrot.org? Feel free to take over this 1.0 task from
me since I'm out of the loop here. 19:21
* as mentioned in twip and the ticket; docs.parrot.org has a copy of the 0.9.1 release docs.
I have a question. EOR.
kj docs.parrot.org/ doesn't work.. 19:22
Whiteknight (sorry I'm so late, network at work is garbage)
allison docs.parrot.org/ gives me 403 Forbidden
Coke The url from twip is:
allison probably just a permissions problem, can get that fixed quickly
Coke docs.parrot.org/parrot/0.9.1/html/index.html 19:23
no. there is no top level html file atm.
we could easily have it redirect to the latest release of the docs.
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
kj basically no TOC then?
allison okay, then we need one. And that is easily fixed
Infinoid (without the version number)
Coke I can add the redirect to the 0.9.1 docs.
allison kj: that index.html is the TOC, but it needs work
Coke Infinoid: that was stopped because of my queued question. 19:24
allison kj: feel free to work on it
Coke: thanks for TWIP, it's great to get the regular news reports
kj would that be static html writing?
Coke (any improvements to "make html" will be noted in the next release, and in teh snapshot.
kj Coke++ #TWIP
Coke kj: no. just make "make html" nicer.
allison kj: it's the 'make html' target
kj: a bunch of perl modules 19:25
subclasses of Pod::Simple
kj mmm. not sure if have time to figure that out this week.. kinda up the walls here.
allison Coke: you had a question?
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.
pmichaud (I also have a comment that I think we should not use the term "milestone release") 19:27
(at least, not to indicate the six monthish releases)
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.
allison Coke: yes, we talked about it last wednesday, and it turns out we did have a different idea of what was going on
Coke development? stable?
allison Coke: seems to be resolved now
Coke ORLY? because I haven't seen any clarification anywhere. 19:28
allison 1.1 is development
Infinoid I tend to agree with chromatic's view that every release should be considered "stable"
Coke that is not the impression i had from chromatic the last time I talked to him on IRC.
Infinoid but less-loaded terminology like "latest" works equally well for me
allison Coke: as far as I can tell, our public docs are consistent
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
Coke allison: right now, you seem to understand one thing, and chromatic seems to understand something else.
pmichaud docs/project/support_policy.pod still says 1.0, 1.5, 2.0, 2.5,
allison Coke: nothing's changed there, except the version numbers
Coke then there's a problem.
allison okay, chromatic may still be confused, but that doesn't mean everyone needs to be confused
Coke ... I am confused.
pmichaud I am also confused. 19:30
allison ok, then let's get you unconfused, and not worry about chromatic
Coke or rather, I think I know what you mean, but there's a lot of disagreement.
allison so, what are you confused about?
Coke what does 'development release' mean?
since that doesn't appear anywhere but your vision doc, I have no clue.
allison a development release means we won't support it with bug/security fixes later
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"?
allison Infinoid: the latter
Coke I don't think we ever want to not have people report bugs.
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
Infinoid whereas we will get stuck maintaining 1.2 and 1.0.1 branches
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
NotFound I'd like to have tons of people trying to report bugs but being unable to find one ;)
pmichaud I don't like the negative definition there, though (more)
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
allison yes, we usually define it by "what's special about a stable release"
Coke allison: you and chromatic use the word stable differently. 19:34
allison rather than "what's different about a develoment release"
Coke: yes
Coke so, whose names are we using?
allison Coke: but stable is an industry-wide standard
pmichaud Based on the definitions we have at the moment, I'd prefer "supported release" to "stable release"
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'
Infinoid pmichaud: Me too. 19:35
allison pmichaud: that's just going to confuse people
Coke I don't care, really. I just want /our/ docs to be self consistent.
pmichaud "stable" in the industry doesn't mean what "stable" is being used for here.
at least, not in the way I've been seeing it.
Infinoid "supported" is definitely more accurate than "stable" for this usage
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?
allison Coke: it means the same thing as our monthly releases, just on a much slower timescale
Coke really? because I would never install 5.9.x in production.
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
allison 1.3 should not be used in production
1.0 should, 1.4 should
Infinoid ... ouch.
Coke that is not my expectation. (nor was it chromatics)
(when last I spoke to him.)
pmichaud (nor is it what is commonly used in the industry)
allison we're moving away from monthly releases because that's far too rapid a timescale for the average user 19:38
so, we define 2 points a year January and July where they really should upgrade
Coke why then are we even numbering the monthlies?
allison Coke: because we always have
pmichaud then we should stop.
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.
or at least part of the confusion. I mean, I can keep it straight, but I can't explain it to others.
Infinoid I would always consider 1.1 to be better than 1.0
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
pmichaud really? I don't know that it's been seriously proposed or discussed.
Coke allison: people complained about the version numbers because of a deeper confusion as to what the hell the plan was.
allison okay, let me take a step back and explain the fundamental tension here 19:40
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)
(he's not here to clarify)
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
allison but, for interacting with outside users, which we really have to do now, we cannot expect users to upgrade every month
pmichaud ("value" is ambiguous for me here)
allison we cannot expect distributions to upgrade to each monthly parrot release
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
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.
allison NotFound: exactly
it really doesn't matter how we number those "stable" releases
we just have to pick something and stick with it
Coke allison: as an example: with your scheme, 1.4 is a big release. 1.5 is really "release candidate for 2.0"
yes? 19:44
pmichaud except that there's an industry perception about numbering that we have to consider.
(thus it does matter how we number the "stable" releases)
allison basically, except "release candidate" is a dirty word (I do agree with chromatic on that)
Coke (since we may put in/rip out a ton of stuff immediately after the 1.4 release is cut.)
allison Coke: yes
NotFound I don't see any industrial negative effect with Ubuntu atypical version numbering, for example.
pmichaud NotFound: because ubuntu's numbers are strictly date based. 19:45
NotFound pmichaud: because they clearly explains what it means, IMO
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.
pmichaud NotFound: and because ubuntu does expect users to use every release.
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
pmichaud NotFound: i.e., there's no notion of "we're releasing this for our developers, but not for the average user"
(in the Ubuntu case)
allison Coke: that much is decided, we're not changing the monthly cycle
Coke: it's valuable for training up new release managers 19:46
Coke allison: that's not what I mean.
pmichaud allison: I don't think anyone is proposing that we eliminate the monthly cycle.
allison Coke: and for a regular cycle of bugfixes
Coke: okay
Infinoid allison: For upgrades, its true that they're more likely to go to X.0. I'm thinking about new installations though
Coke I mean whether or not 5/6 of our releases are going to be "throwaway".
allison Infinoid: new installations should also go for 1.0 and 1.4, not 1.3 19:47
Coke or "devel", or "not stable".
pmichaud where "throwaway" means "not recommended for production"
allison doesn't matter what you call them, but yes, 5/6 will be not recommended for production
NotFound New installations in most cases will be done with: "aptitude install parrot" and equivalents.
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
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.
Coke ok. I think that point is still being discussed, but it sounds like you have decided that this is how it is.
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"
allison Infinoid: snapshots makes them sound too throwaway
Infinoid That's exactly what we're doing, though. So it seems to match reality
Coke allison: but it sounds like they /are/ throwaway.
(from your standpoint.)
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?
allison Coke: defining some releases as recommended for production
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.
allison and, more importantly, we don't have the developer resources to provide production support for every monthly release 19:50
we'd be killing ourselves
pmichaud NotFound: if our numbering system is too strange, no amount of documentation will help.
Coke NotFound: at this point, I'm still trying to resolve what is intended by the release, not what it's called.
allison 2 releases a year, we can manage
Coke once we know what it /means/, we can come up with names that reflect that.
that was part of the confusion.
allison 1 release a year we can certainly manage
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.
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.
Infinoid Coke: Hi, Mr. HLL maintainer! What do you think it should look like? :)
allison we're not saying that the monthly releases become somehow less than the releases we've been making the past 3 years
Coke Infinoid: I think it should work. I'm not competant to design it, or I'd have done it already.
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"
NotFound Coke: I added today a pir example of HLL interaction at work
pmichaud it somehow implies that the monthlies are less than they were before.
allison but the January and July releases are something more than any of the releases we've done before
NotFound examples/pir/interlangs.pir
allison pmichaud: technically, we've only had development releases until this month
pmichaud allison: I have no argument with that. 19:53
allison Coke: HLL interaction is 1.4, we will get there :)
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.
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)?
allison Coke: it doesn't mean we're fixed in concrete
Coke rurban: language packaging should be driven by the languages, not by parrot.
rurban So I need a makefile with the language version numbers. And where to get them.
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.
NotFound Coke: I said last week: It's like TAP, we have a plan, but we can skip ;)
allison cotto: critical bugs and security fixes will be backported to the stable releases 19:56
NotFound: yes :)
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
pmichaud rurban: I don't think we expect Parrot's Makefiles to build the languages.
Coke Then if we have two different kinds of releases, I would recommend calling them two different things.
allison Coke: yes
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
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.
allison rurban: each language should be a separate package
rurban yes, as with fedora
Coke rurban: I don't think it's reasonable for parrot to keep track of the language's releases and repositories and recommend versions.
allison Coke: you mean 1.0, 1.1, 1.2, 1,3...?
pmichaud I think it's always been understood (at least by me) that we would have two different kinds of releases. 19:59
I think even chromatic recognizes that.
Coke allison: I think with our current scheme, calling the first 'special' release 1.0 and the first 'monthly' 1.1 will only confuse.
pmichaud: part of the issue is how those releases would differ.
pmichaud Coke: the special releases have extra care put into them, and receive backports
Coke: the other releases don't
allison Coke: I don't hold that particularly strongly, but I also don't have any other suggestions that would be clearer
rurban cannot we say x.0 is stable, x.4/6 is a deprecation point and the rest are unstable, devel releases?
allison we could do 1.0 and 1.4.0, 1.4.1, 1.4.2, 1.5 20:00
rurban: yes
Coke perl's odd numbering scheme doesn't look so crazy now, does it? =-)
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"
Coke pmichaud: I did not get the impression that his only difference was naming.
allison pmichaud: yep, like I said, our external documents are consistent aside from naming
Coke I got the impression that he saw no reason to discourage, say, 1.1 from going into prod.
pmichaud Coke: "Parrot currently follows a monthly cycle; we produce a new stable release of
Parrot on the third Tuesday of each month. This will continue into the
forseeable future.
(from suppor_policy.pod)
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
pmichaud year, one in January and one on July."
allison Coke: btw, chromatic did entirely agree with me on not porting bug/security fixes back to the monthly releases
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
allison we have been running too long on this 20:03
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
allison at the end of the day, it really doesn't matter
I'm happy with the compromise we worked out
NotFound Words free of connotations
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
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,
it would limit the options for further development of Parrot
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.
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 :-)
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
pmichaud okay, so Jan+Jul releases are "stable release", other releases are "development releases"
I can live with that.
allison pmichaud: aye
Infinoid Should the website docs always link to the most recent stable, or the most recent (whatever) release?
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
(similar to the Perl download page)
particle1 i'd really to see 1.6 as stable, if 2.6 and 3.6 are also stable
allison pmichaud: I think so too, but I also think they'll just end up following 1.0, 2.0, etc
Infinoid allison: Ok. But where should users go by default? I need something to bounce the old pod2html pages from parrotcode.org to
rurban I've tried a diff at nopaste.snit.ch/15762
Infinoid And to link from www.parrot.org/dev, etc.
allison Infinoid: those pages are going away 20:10
particle1 as far as naming is concerned, consistency is more important than logic.
allison Infinoid: change the text and link them to www.parrot.org/downloads
pmichaud barrages particle with an infinite number of water balloons.
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
pmichaud it would not bother me to go 1.0, 1.1, 1.2, 1.3, 1.6, 1.7, 1.8, ...
i.e., to skip from .3 to .6
allison Infinoid: ah, you're talking about aliases on the new site, yes, those are good
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 :)
particle1 or 1.0, 1.3, 1.4...
rurban or better skip 1.1 and 1.2 and go directly to 1.4 for april
pmichaud somehow the jump from 1.3 to 1.6 bothers me less than a skip from 1.0 to 1.4
particle1 april is 1.3
rurban oops 1.3
pmichaud or 1.3
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
pmichaud if we go 1.0 to 1.3, then people will ask "what happened to 1.1 and 1.2?" (more)
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.
pmichaud if we go 1.3 to 1.6, then we can say "it's a stable release, so it gets the .6"
(I think this came up on the mailing list already also :-) 20:13
rurban agreed
particle1 pmichaud: 1.0 is a stable release, that's two months late :)
pmichaud particle1: not at all, it's exactly when we said it would be :-)
allison Infinoid: let's carry the website questions to #parrot 20:14
on version numbers, there is no perfect answer
pmichaud it simplifies things slightly if we can refer to .0 and .6 releases as always being stable releases.
allison whatever we pick, we'll have to explain
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.
allison so, we're really only talking about 3 special half-yearly releases
pmichaud allison: I can conceive that we might stick with half-yearly stable releases after 4.0.
allison it doesn't matter so much if they're consistent, because it's not a long-term pattern
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
so if it's easier to say "always .0 and .6 for now", we should do that.
NotFound Someone said: "In the long term, all dead"
pmichaud NotFound: Keynes
allison it's easiest to say "January and July"
pmichaud well, that's what I've been generally doing, yes. 20:17
particle1 enero x julio
pmichaud maybe I can do that with the docs.
allison and "whatever version number happens to fall in January or July
particle1 er, y
numbers are already localized.
allison (with a special exception for 1.0, which isn't January)
pmichaud surely it's January somewhere in the world, like timezones? ;-P
allison but on going into the future it's Jan/Jul
pmichaud: :)
pmichaud I'll see if I can update support_policy.pod with the new information. 20:18
allison pmichaud: okay, thanks! 20:19
any other questions before we wrap up for the week? 20:20
pmichaud I'm wrapped.
Util Earlier, I asked for extra eyes on a not-yet-ticketed problem.
The ticket is TT#398, and the relevant eyes are most probably pmichaud and/or cotto's.
NotFound Who pays the beers?
allison that's a wrap everybody, thanks! 20:21
rurban yes, I want to rename sun4 to sparc
But we can do this in 1.6 also
Util moves to #parrot 20:22
20:22 allison left, Util left, rurban left, Infinoid left, NotFound left 20:25 particle1 left, pmichaud left 20:30 masak left 20:32 PacoLinux left 21:25 rdice joined 22:03 Whiteknight joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!