Priorities for this week: irclog.perlgeek.de/parrotsketch/201...#i_3126985 | Post closed tickets in your report. | Note: This channel is for our Tuesday status meetings (at 20:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/parrotsketch/today
Set by moderator on 8 February 2011.
01:02 cotto joined 01:19 cotto left 01:30 cotto joined 02:05 contingencyplan joined, contingencyplan left, contingencyplan joined 02:55 whiteknight left 04:04 bacek joined 06:53 contingencyplan left 08:21 lucian joined 08:22 lucian left 11:51 bacek left 13:17 Coke left, Coke joined 14:00 lucian joined 14:37 atrodo joined 14:57 bluescreen joined 15:51 bluescreen left 15:59 contingencyplan joined 16:58 lucian left 17:05 lucian joined 17:20 lucian left 17:22 lucian joined 17:33 lucian_ joined 17:36 bacek joined 17:37 lucian left 17:53 bacek left 18:08 NotFound joined 18:13 bacek joined
NotFound What I did: 18:26
-parrot
* minor fixes and testing
-winxed
* new predefined functions typeof, getstdin, getstdout and getstderr 18:27
* minor fixes
* Created the project winxedxx, a C++ backend for winxed.
The idea is to make it capable enough to compile stage 1 and then use it
to replace the current stage 0.
What I will do:
Improve winxedxx and make winxed stage 1 more extension friendly.
EOR
19:50 kid51 joined
kid51 kid51's report 19:51
* DONE
** trac.parrot.org/parrot/ticket/2009: eliminate svn-related code
** trac.parrot.org/parrot/ticket/2004: cxx option
** trac.parrot.org/parrot/ticket/2000: MethodEmitter.pm
** trac.parrot.org/parrot/ticket/1988: PMCEmitter.pm
** cage-cleaning: trac.parrot.org/parrot/ticket/1751
** minor touch-ups and testing 19:52
** Parrot Foundation business: reviewed legal drafts
** posted re GSOC
* WILL DO
** cage-cleaning: last call for trac.parrot.org/parrot/ticket/406, trac.parrot.org/parrot/ticket/1159
** finish trac.parrot.org/parrot/ticket/1954
EOR
20:03 gerd joined
mikehh What I did since my last report: 20:17
* building and testing parrot on amd64/i386, with gcc/g++
* some fixes
* branch testing and fixes
* testing Rakudo and Winxed on latest parrot
* Released Parrot 3.1.0 "Budgerigar"
What I intend to do in the next week:
* testing and fixing
* work with kid51 to remove make docs and more html cleanup
* more testing of gen_gc2 and other branches
.eor 20:18
20:18 nwellnhof joined
nwellnhof what i did: 20:19
- not much
plans:
- merge unicode_dynpmc branch
eor
20:20 tcurtis joined
cotto_work *did: 20:20
- M0 roadmap progress
-- sent out M0 planning notes to people who expressed interest in heling design M0
-- pushed m0-spec branch with draft pdd32 (M0)
-- started putting bytes into it
- profiling runcore progress
-- none
*will do: 20:21
- M0 thinking and coordination
- profiling runcore hacking/research
*blockers:
- none
20:21 benabik joined
Util No forward progress; all tuits were eaten by server crash (now fixed). 20:26
# 7-day ticket report:
2 closed: done
8 closed: fixed
2 closed: invalid
13 new
1 reopened
.end
tcurtis Wednesday before last, my laptop's screen started working, so that was a blocker until I got a monitor this weekend. Hopefully will find tree-optimization tuits this weekend.
cotto_work *started*? 20:27
tcurtis s/started/stopped/
20:28 whiteknight joined
cotto_work Hello 20:29
whiteknight hello 20:30
kid51 Good afternoon
Util Hello 20:31
cotto_work How this week's goals go? 20:32
tt count definitely didn't drop
mikehh: Did you have any issues with the release?
whiteknight what were the goals for last week? The link in /topic is woefully out of date 20:33
cotto_work GOAL 1: close 23 tickets by next #ps (get total down to <=500)
GOAL 2: monitor progress of Rakudo's needs (speed, gc, profiling, newPOST, serialization)
GOAL 3: no merges after Saturday in preparation for 3.1
GOAL 4: test HLLs after Saturday, fix bugs as needed
whiteknight well, we certainly didn't merge anything
or, we didn't keep anything merged 20:34
cotto_work heh
20:34 dukeleto joined
dukeleto hello 20:34
cotto_work Did anyone test some HLLs over the weekend? 20:35
whiteknight I tested NQP and a few other projects. Not HLLs
mikehh I tested rakudo and winxed 20:36
cotto_work mikehh: were there any wrinkles in the release process we could smooth out?
mikehh in terms of the release, I ssh into the site but could not use scp, eventually used sftp 20:37
NotFound Hola 20:38
mikehh when I used scp it kept asking for the password
cotto_work sounds like it might be using a different key, though I don't know why it'd be doing that
mikehh so that did not work for me
dukeleto mikehh: you need to use ssh-agent
mikehh possibly 20:39
but anyway sftp worked fine
then I went back into ssh to run the script
cotto_work mikehh: if you figure out what the problem was, please add it to the release manager guide in case someone else runs into it 20:40
mikehh will do, I also want to add list addresses to the guide 20:41
cotto_work good idea
any other thoughts before we move to questions? 20:42
kid51 I have one thought on the release process.
cotto_work or any question queuing?
kid51: go ahead
mikehh btw ../parrot tools/release/crow.pir did not work - complained about non-ascii text in NEWS
cotto_work plobsing++
dukeleto we need tests for crow.pir or we should just rm it 20:43
kid51 We all (well, not me, but ...) got excited at the prospect of merging generational_gc into master before this release.
mikehh tests, and more tests
cotto_work dukeleto: I like that idea. It's not reliable as is.
kid51 And I think that excitement led us to overlook the fact that code that touches so many fundamental things can simply not be rushed
cotto_work kid51: the decision to merge was definitely premature. 20:44
kid51 I think that branches which are as profound as gen_gc really need signoff from the Architect first
cotto_work It was also made in a bit of a vacuum late at night.
kid51 Actually, if we had the role of pumpking, it would have been the pumpking's job.
mikehh kid51: yes that was my fault, did not consider all the implications, however...
dukeleto kid51: we don't have a pumpking, tho 20:45
mikehh I still think we should have included it
kid51 mikehh: Well, then I think you have a more expansive concept of the Release Manager's role than I do.
I would not have wanted to make that call one way or the other.
mikehh full speed ahead and damn the torpedoes 20:46
kid51 But then again, I have yet to serve as RM :-)
mikehh or whatever, I had been testing with bacek and rakudo and others passed, so I thought we should go ahead
dukeleto We made the right decision to hold off on gen_gc
It needs polish.
kid51 mikehh: For most branches, that would be correct.
cotto_work Yes. 20:47
kid51 But certain things we do have a much more profound effect than others.
cotto_work a major subsystem rewrite like that shouldn't go in so close to a release
mikehh yes, but I certainly don't want to wait nuntil 3.3 or 3.6
cotto_work mikehh: we won't have to, one way or another 20:48
dukeleto I don't think there is much to talk about. We realized something was merged prematurely and unmerged it.
kid51 mikehh: I think there are pitfalls in the "I don't want to wait until release x.x" approach
mikehh kid51: probably, but I think we seriously need to look at our current deprecation policy 20:49
kid51 mikehh: I'm sure we'll have a looooong discussion about deprecation policy in this and later meetings
That's not the issue here.
cotto_work mikehh: I suspect whiteknight will have some thoughts there too. Let's move on to questions since this is wandering away from release discussion.
mikehh We have one, just one, major customer and a few peripherals
'k 20:50
cotto_work I had a couple:
1) I'd like to nominate atrodo for a commit bit?
mikehh +1
NotFound +1
kid51 Yes. CLA received.
dukeleto +1 for a bit for atrodo 20:51
kid51 Is atrodo working on any particular team?
cotto_work kid51: he's helping with the m0 spec.
dukeleto kid51: he is helping with M0/Lorito stuff
kid51 Excellent! I really want to see new committers integrated into functioning teams. 20:52
cotto_work Would anyone like to volunteer to mentor him?
mikehh cotto_work: I can help, but it really should be you
dukeleto cotto_work: i nominate you :) 20:53
Util +1 for a bit for atrodo
cotto_work It's settled then. Looks like cotto will do it.
dukeleto shall I add him to the developer team on Github now?
cotto_work dukeleto: sure
q2:
As mentioned on parrot-dev, I propose the following solution to getting gen_gc merged and tested while sticking with our deprection policy:
gen_gc gets merged now and is made the default, except for in the 3.2 and 3.3 releases. There, we have a configure-time option that selects the gc and defaults to gc_ms2.
This lets us make sure that Rakudo gets a shiny fast gc but that languages that aren't ready won't have to bother until 3.6.
Thoughts?
atrodo (Hurray! Thanks)
cotto_work atrodo: welcome to commit bit having. 20:54
kid51 cotto_work: Before we discuss that ... wasn't there another commit bit to be decided
hackbinary?
cotto_work kid51: I wasn't aware.
whiteknight q1q
kid51 Sorry, he submitted a CLA to parrot foundation legal list
... which you wouldn't have seen. 20:55
cotto_work kid51: are you nominating him/
?
mikehh ok that was my question
whiteknight that's my 1q
I would like to nominate Hackbinary for a bit
he's been working on docs and things
kid51 CLA received; is he working on some team?
NotFound +1
dukeleto i am +1 for hackbinary to get a bit
mikehh I can mentor there 20:56
and +1
whiteknight kid51: no team affiliation that I am aware of
kid51 No objection here.
cotto_work wfm. let's get him a commit bit
kid51 k 20:57
whiteknight awesome
kid51 q1q
cotto_work Let's go back to my gen_gc question then.
dukeleto atrodo++ and hackbinary++ now have Github commit bits
Coke cotto_work: I disagree that we should change the default /just for the release/ (catching up) 20:58
dukeleto atrodo: welcome, use your bit for good, and don't break stuff :)
Coke then we end up with a release with untested code.
atrodo Drat, I was hoping no one would tell me that
cotto_work dukeleto: I was supposed to say that.
dukeleto Coke: explain more, please.
cotto_work ;)
dukeleto cotto_work: you can tell hackbinary ;)
cotto_work Coke: I thought about that, but gc_ms2 has been well-tested already. 20:59
Coke most of our smoke/tinder is checking defaults only. switch the default just for the release, boom, our customers get the untested version.
why not just leave it the default all the time until we're ready to ship it as the default?
er, first it = old gc, second it = new gc. 21:00
kid51 notes that there are currently *4* different branches with 'ms2' in their names
Coke rakudo is smart enough to add a flag to the config if necessary.
cotto_work because gen_gc needs as much testing as we can throw at it
Coke so make it the default always.
nwellnhof imo gen_gc needs a lot more testing than ms2
Coke or leave it as an option and improve the testing options, if you're not willing to cut a release with it that way.
nwellnhof and it's really hard to get testers for something that's not in master 21:01
Coke but switching the defaults just before the release is, IMO, not a good idea.
nwellnhof: this is going to be in master. the question is if it required passing more info to Configure.pl
nwellnhof Coke: it it's enabled in the default config that doesn't help much
s/it's/it's not/ 21:02
mikehh we have just released, we have a month of testing until the next release
Coke if the issue is we can't put it in as the default until the next core release, then oh well. it's in there now, and we have N releases to improve the testing so that we get folks testing the alternate core. 21:03
then right after the next supported release, we change the default. Everyone who cares (rakudo) will be using it all along.
and they don't have to change anything after that release, because explicitly specifying the default is fine. 21:04
kid51 also notes that there are *12* different 'gc' branches in github right now; difficult to wrap one's brain around
cotto_work I'd much rather have gen_gc be the non-release default. We don't gain anything by continuing to test and develop against gc_ms2. 21:05
mikehh never mind branches, gc itself can be difficult to wrap one's brain around
dukeleto Coke: "most of our smoke/tinder is checking defaults only" isn't a good argument. We have smokers that test many Configure.pl combinations
nwellnhof gen_gc should be the default at least for the next 2-3 weeks. then we can evaluate again.
whiteknight I like that idea
if we switch it back, we still have a week of testing with ms2 before 3.2
cotto_work That sounds acceptable, though we should make sure that the Configure.pl code for picking the default gc is in place and solid before then. 21:06
nwellnhof that shouldn't be a problem
cotto_work (I know that bacek++ added some but haven't had a chance to look at it yet.)
any objections to making gen_gc the default for the next 2-3 weeks and revisiting at that time? 21:07
mikehh I am happy with that, as long as we revisit 21:08
cotto_work ok. Does anyone want to volunteer to make sure we don't forget to revisit?
mikehh I kind of like to forget that 21:09
kid51 cotto_work: Post a deadline for that reconsideration to parrot-dev. (You'll be making all the executive decisions anyway ;-) )
mikehh I'll put it in my #ps notes file 21:10
cotto_work wfm 21:11
Coke -1 from me on the plan.
cotto_work Coke: what's your objection?
Coke I already explained it. if we not comfortable making it the default for the release, I don't think it should be the default on master. Our testing infrastructure, as dukeleto mentions, should be able to handle checking the non-default also, whatever it is. 21:12
so there's no reason to /switch/ gen_gc2 to being the default. 21:13
cotto_work Our tools are flexible but our developers are lazy.
mikehh we already have it working with rakudo, winxed and lua, any other HLL's can be looked at
cotto_work (or they should be)
Coke but, I realize I'm outvoted. back to $dayjob and trying to fix partcl from months of breakage.
mikehh Coke: if you give me some pointers, I can maybe help there 21:14
nwellnhof we don't have to decide now if we're comfortable with gen_gc for 3.2. i think in 2 weeks we have a much clearer picture.
cotto_work nwellnhof: agreed. We'll revisit it then.
kid51: what was your question? 21:15
kid51 As I pre-posted, we're at the point in the year where the GSOC-2011 process is starting.
Spoke with dukeleto, who has served as joint "organization admin" for both Perl Foundation and Parrot Foundation for > 1 year. 21:16
mikehh yeah, that depends on where dukeleto stands
kid51 He notes that serving in that role for both projects is very time consuming
So this leads me to suggest that we have a distinct org-admin this year.
mikehh perl has a much bigger community 21:17
kid51 TPF president really values dukeleto's work but acknowledges that it is a lot of work
whiteknight is it going to be less time consuming to do it for only Parrot?
I suspect much of the overhead is the same whether we're organizing a big or a small group
kid51 dukeleto: Are you there? Can you speak to that?
dukeleto is here, occasionally 21:18
the time consuming part is being the admin of two semi-related umbrella organizations 21:19
i think the question I want to put to a #ps vote is: Do we want to be our own organization in GSoC/GCI from now on?
whiteknight dukeleto: if we broke off and were our own organizations and had our own org admin, would that be better from that perspective?
dukeleto whiteknight: yes, i think it is finally time that we broke off from TPF 21:20
whiteknight: this will require you, as treasurer, to do some paperwork for Google to pay PaFo
whiteknight can we be in GSoC if we aren't 501(c)(3)?
I'm fine with paperwork
dukeleto whiteknight: TPF does not seem motivated to get money from Google. I assume we will be much more so. 21:21
whiteknight: yes, they don't have a requirement to be a non-profit
whiteknight okay
Coke are we owed $$ from TPF?
mikehh it would be nice if we can get some funding
whiteknight we aren't 501(c)(3) yet. funding is ...tricky
dukeleto Coke: yes, we have not receieved any money from Google that we should have in the last 3 years probably
Coke: because TPF either didn't submit the paperwork, or it never trickles down to us, also because PaFo is in legal limbo right now 21:22
Coke: but when PaFo is legal again, we should ask TPF for some money that Google gives organizations each year
Google gives each org $500/each per GSoC/GCI, iirc 21:23
so in theory, we should be splitting that with TPF
21:23 benabik_ joined
dukeleto for the last 3 years or so, but we never saw any 21:23
21:23 benabik left, benabik_ is now known as benabik
whiteknight I suspect the split would not be 50/50, but that's a matter that would have to be negotiated 21:23
dukeleto whiteknight: why not? Parrot had about half the slots in the last 2 years of GSoC 21:24
whiteknight we would have to talk to TPF about it 21:25
dukeleto: are you planning to be an org admin this year? if so, for which foundation?
cotto_work I'm fine with PaFo being its own org, but it also doesn't mean more (or less) work for me. It depends on who's doing the work.
whiteknight that's what I'm getting at 21:26
dukeleto I am fine with being the org admin for Parrot this year.
kid51 A lot of this discussion will be at the TPF-PaFo level, so we don't have to iron out every detail in this meeting
mikehh +1
dukeleto I haven't decided what to do about TPF, and will need to talk to them about it. 21:27
cotto_work +1 then
Coke +1 for applying separately, assuming we're sticking with PaFo and not going to eventually umbrella under another org anyway.
whiteknight we should probably get in touch with Google and assess our chances of being accepted. I think our chances are high, but I would hate to be left out on some technicality
Coke (umbrella not in a gsoc context)
dukeleto Coke: no, i plan to make PaFo it's own GSoC organization
whiteknight: there is no "getting in touch with google". Our chances are high, since we have a proven track record. 21:28
Coke dukeleto: ... I mean outside of the gsoc context.
whiteknight dukeleto: it never hurts to send out an email and get more information
Coke if there is going to be no distinct legal pafo entity in a year, we might as well not go solo for gsoc.
dukeleto Coke: that is a whole other bucket of worms
whiteknight we are a legal entity, just not a tax-exempt one
Coke Yes, I know.
dukeleto Coke: that remains to be seen, and I don't think we are leaning in that direction. 21:29
Coke there was talk amongst the last directors which extended to the current board about closing up shop on pafo entirely.
(for whiteknight)
dukeleto: ok. if that's not the current leaning, no point in worrying about it for gsoc. danke.
dukeleto whiteknight: more info about what? What would I actually ask them? You can't ask "will you accept us this year" ?
whiteknight dukeleto: it's not a big deal. I'm not trying to start a fight over it 21:30
dukeleto Coke: only one person has ever mentioned closing shop on PaFo, allison, and I don't think we are leaning in that direction
whiteknight okay, /me has to pack up and catch a train. Later
21:31 benabik_ joined, whiteknight left
dukeleto whiteknight: see you on the flip side 21:31
so we will be our own GSoC org. Next question?
cotto_work I don't think any were queued, though that's not a necessity. 21:32
dukeleto I would like to see Parrot developers talk about which conferences we would like people to give talks at, so that we get the word out about Parrot.
we have devs all around the world, we can easily get talks submitted all over the place 21:33
cotto_work Good question. I've been looking at conferences and trying to pick the best ones to attend, but I'd like to hear what other people think.
dukeleto as community manager, I don't think we are effectively telling and showing people why they should be interested in Parrot.
cotto_work I've got YAPC::NA, YAPC::EU, OSCON and LinuxConf NW (and possibly another I'm forgetting) planned so far. 21:34
OS Bridge too 21:35
21:35 benabik left, benabik_ is now known as benabik
allison dukeleto: it wasn't just me, that was the general consensus of all the previous directors except particle 21:35
dukeleto: but, we decided to give a fresh bunch a chance first
dukeleto allison: sounds good to me, thanks for the correction 21:36
dukeleto is planning on YAPC::NA, LinuxFest NW, YAPC::EU, OSBridge, OSCON, PGCON 21:37
cotto_work It'd be great to see other Parrot hackers at some of those, even if they're not speaking.
and Rakudo
dukeleto yes, i will organize some kind of hackathons to whichever confs I go to
atrodo Having a talk or two at a python or ruby specific conference would probably be a good idea 21:38
dukeleto atrodo: are you volunteering? ;)
Tene q1q
cotto_work atrodo: which would you suggest? Not being part of either community, I don't know which confs would be worthwhile.
atrodo Depends on the costs involved ;)
dukeleto PyCon is having a virtual machine workshop or something this year, and all parrot devs are invited to go. I cc'ed parrot-dev a few weeks ago
atrodo cotto_work> Me either, I'm a perl guy
cotto_work Tene: go ahead. 21:39
Coke dukeleto: allison brought it up first, but she was not the only person who was considering it as an option. 21:41
(developers @ cons) - if we had funding to send people to cons, we'd probably get more interest. 21:42
(me is catching up again)
back in realtime.
Tene sorry, work interrupted. 21:43
back now
cotto_work wb
Tene Cardinal was recently brought under the parrot organization on github.
I want to know exactly what that means for grant commit privileges to people who haven't submitted parrot CLAs. 21:44
If I want to let anyone work on Cardinal, do I have to continue to maintain a repo outside of the parrot org?
dukeleto Tene: i think we only require CLA's for parrot.git right now, but that is a good question.
Coke I would /imagine/ that anything in the parrot org on github should have to follow parrot CLA rules.
dukeleto Coke: yes, but we haven't been explicit about that. 21:45
Coke as long as we're explicit either way.
cotto_work dukeleto: +1
Tene I haven't actually explored github yet to find out how any of that works.
dukeleto Tene: currently, everyone that is a developer in the Github org has a commit bit to all parrot projects on github 21:46
Tene If we actually want to encourage offering languages to be hosted under the parrot org umbrella whatever, I would not want to require that they all fall under parrot CLA requirements.
Coke if project-in-organization means anyone with access to parrot/parrot can access the others (and vice versa) that's an issue.
dukeleto Tene: can you send a quick note about your question to parrot-dev ? I would like to get feedback from people that are not here.
Tene Yeah, that's what I was worried about.
Can we change that? I have no idea how github is organized.
dukeleto we can easily seperate out our commit bits, and have a team for parrot.git bits and then a team for HLL bits
Tene dukeleto: I can.
dukeleto each github org can have N teams 21:47
Tene I'm done with my question.
dukeleto each team can be granted pull only, push+ pull or admin rights to the repos that team contains
Tene So we can make a no-cla parrot team that can have commit privs to non-cla-required repos? 21:48
like cardinal?
or should I make a cardinal team, or...
I guess take it to the list.
dukeleto: one other question... I think it was you that wanted to import it into the parrot org? Do you remember why you wanted that? 21:49
kid51 at $job
Tene What's the purpose or benefit to Parrot to have other languages hosted under the parrot organization? Permit easy access for parrot devs to fix problems with hlls?
mikehh that would have been my thought 21:50
dukeleto Tene: yes, mostly that many people have commit bits to the parrot org, more people to fix stuff
Tene: also, easier to manage stuff like post-recieve hooks to notify us on IRC when cardinal commits happen, etc 21:51
Tene: i would say we should rename our current "Developer" team to "Core Developers" which have bits to parrot.git and then make a "HLL developers" team with bits to everything that is not in core
Tene Okay, yes, if we want that to happen, allowing non-cla committers is a requirement. 21:52
dukeleto but, for instance, tree-optimization and plumage. Do people need CLA's for those?
we can hash all this out on parrot-dev
Tene actually, I really need to get back to $job, can someone else mail about this? 21:53
21:55 kid51 left
dukeleto sure, I will send an email 21:58
cotto_work Thanks. Are there any other questions or comments before we call it a wrap? 21:59
That's wrap. 22:01
22:02 nwellnhof left
tadzik so, what are the goals for this week? 22:02
ah
cotto_work tadzik: good point. I forgot those.
tadzik just when I have a free week to do something :) 22:03
cotto_work though I only have merging gen_gc and ensuring that configure-time default gc selection works
tadzik any further plans for DaD? dukeleto?
dukeleto tadzik: we can add more DaD tools 22:05
tadzik: a web interface would be nice
cotto_work that'd be quite nice 22:06
tadzik I can do something about this
what kind of web interface do we want?
dukeleto tadzik: let's move this over to #parrot 22:09
tadzik sure thing
dukeleto did we wrap this meeting? Do we have goals?
cotto_work just merging gen_gc 22:10
dukeleto cotto_work: that is going to take 1 person about 5 seconds 22:11
cotto_work yes
dukeleto cotto_work: extensively testing it, that is another story
cotto_work that's important too
dukeleto ok, wrap it up, Danno. 22:12
dukeleto goes back to #parrot
22:12 dukeleto left 22:14 NotFound left 22:22 benabik left 22:39 lucian_ left 22:40 lucian joined 23:25 atrodo left

Powered by Cro and the Raku® Programming Language.

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

Thank you!