Open Source Meeting/2007-07-12

From Second Life Wiki
Jump to navigation Jump to search

< Open Source Meeting

Open source meeting - Thursday, 2pm PT

Transcript (raw)

Rob Linden: Actually, would like to switch the order, since Liana has to go
Rob Linden: so, moving the new Award program to the top of the list
Liana Linden: Thanks, Rob.
Very Susanti: well there are other things you can get from the viewer like the avatars that own objects on the parcel and how many each
Liana Linden: Any questions from the group?
Rob Linden: https://wiki.secondlife.com/wiki/Linden_Lab_Innovation_Awards
Liana Linden: There have already been some nominations posted.
Very Susanti: yes I know what the word means Dale
Dzonatas Sol: Would it be best to put all the sub-tasks on the wiki page
Soft Linden: Sure, would make sense
Soft Linden: First of all, has everyone seen the developer awards announcement?
Rob Linden: the idea behind using subtasks was to let people vote if they were so inclined
Rob Linden: nothing binding, but a nice way to say "me too"
Alissa Sabre: who's *all*?
Liana Linden: Dzonatas: the main categories are linked from the wiki. I don't see what value there would be keeping an additional list on the wiki.
Very Susanti: no this is all new to me, I am looking at the links now
Dzonatas Sol: Liana, it seemed like an easier visual step
Dzonatas Sol: no worries
Rob Linden: I'd like to make sure people look back to early this year for contributors there, too
Rob Linden: I think the nomination process is going to be unfortunately biased toward people who contributed most recently
Dzonatas Sol nods
Boroondas Gupte: that how human memory works
Boroondas Gupte: *that's
Soft Linden: Should dump a list of contributions.txt from the end of the eligible period to the wiki. Can linkify the JIRAs after each person.
Liana Linden: Good idea, Soft.
Soft Linden: Are contributions straight through the 22nd eligible?
Rob Linden: another thing is to look at people who contributed bugs, organization, etc as well
Dzonatas Sol: contributions.txt doesn't seem like the best place to look when you consider other efforts to render bug definition
Liana Linden: Yes, through the 22nd.
Rob Linden: yup
Rob Linden looks if there's a good public stat page
Soft Linden: No, it's definitely not all-inclusive. But for a couple of the categories, it'd be the right list.
Liana Linden: yep
Very Susanti: watch out if you crash there is a new mandatory first look client
Rob Linden: I think I found a good report, but it may tax JIRA pretty hard
Rob Linden: at the risk of bringing jira completely to its knees:
Rob Linden: https://jira.secondlife.com/secure/ConfigureReport.jspa?filterid=10040&mapper=reporter&selectedProjectId=10003&reportKey=com.atlassian.jira.plugin.system.reports%3Asinglelevelgroupby&Next=Next
Liana Linden: Don't everyone click on that at once. ;-)
Dale Glass: oops
Lolo007 Fargis: Hi
Soft Linden: By next Thursday, everyone's query should finish!
Dale Glass: yep, that's taking some time
Very Susanti: is it really quiet here? or am I in trouble? for some reason it is showing a 0 msec ping time to the User servers
Rob Linden: Very....it's not really quiet
Boroondas Gupte: there was a but about the ping, IRC
Dzonatas Sol: kewl report
Rob Linden: lolo007, we're discussing https://wiki.secondlife.com/wiki/Linden_Lab_Innovation_Awards
Dale Glass: yay, it loaded
Rob Linden: looking forward to seeing who everyone nominates. a lot of great work has been done here, and we're only really just getting started
Soft Linden: Rob - that's a great tool - but I think we want to cache it statically XD
Very Susanti: lol at for entertainment purposes only
Very Susanti: ohh nice report
Liana Linden: Yeah, Very. We couldn't completely duck the lawyer lingo.
Liana Linden: Rob, we can move on to the next topic.
Rob Linden: okee dokee
Liana Linden: If anyone has any further questions or suggestions, please IM or email me.
Soft Linden: I could cover patches a moment here...
Liana Linden: Thanks, all. Ciao.
Soft Linden: Good travels!
Very Susanti: thank you Liana
Dzonatas Sol: take care Liana
Rob Linden: patches!
Rob Linden: (and testing, thereof)
Very Susanti: many safe TP's for you, and may your attachment stay where they are meant to be
Soft Linden: So one of the problems we've got is that we get quite a few good patches in, but we also run across quite a few that are pretty fundamentally broken... they introduce new bugs, or even don't even quite do what the patch description stated.
Soft Linden: In the end, this means that we have to spend an awful lot of developer time just validating these, and debugging them when they're mostly right, but still need cleanup.
Boroondas Gupte: would be grate if there was a standardazed way to indicate what source version a patch was made against.
Soft Linden: I'm wondering what we can do to encourage a bit of peer testing. If we committed to getting patches in within a week of a peer review from another successful commiter, would that encourage more testing?
Very Susanti: that is a common issue with patches, especially as they may have been uploaded on a particular development snapshot, and may not be update that frequently
Very Susanti: and a easier way of creating a patch which may include changes to multiple files
Dzonatas Sol: Soft good ideas. I tried to encourage such before in different ways. It appeared that there was more desire to import the patches as they were. Are we now agreeing to slow down that process?
Soft Linden: Dzonatas, we're already slowed down by having to comb through broken patches. I want to avoid that... I don't understand your question.
Boroondas Gupte: Very, use diff -ur for multiple files
Rob Linden: so (setting expectations here as best I can), sometime in the mysterious and uncertain future, we'd /like/ to get to the point where there's a public maintenance branch, from whence we actually publish nightly builds
Able Whitman: I think it also would be helpful to have some kind of a code review process that patches go through as well, to get feedback from other folks on the patch before it's imported.
Dzonatas Sol: Rob, excellent idea
Able Whitman: Yes, Rob, I love that idea :)
Rob Linden: once we get to that point, then anyone with commit access (which could be non-Lindens) could test builds
Very Susanti: I guess it might also be usefull to publish a "build day" to test new patches, so people know they have to update them by a certain day time
Dale Glass: how about switching to some sort of distributed source control system?
Rob Linden: however, that's ni the misty, mysterious future, toward which we don't yet have anything mroe than an idea
Dzonatas Sol: Soft, the resources available internally and externally are very different, obviously. Even pinging people to do peer-review on the outside won't happen as easily.
Alissa Sabre: Do we have a handy way to, ah, list all recently submitted patches?
Dale Glass: LL publishes original source, everybody has their own branch from that, and LL merges back whatever's useful
Soft Linden: For the current, would it be useful to have a "patch tested" status for JIRAs with patches attached, and import those preferentially?
Dale Glass: I'm sort of doing that atm
Very Susanti: I like that idea Dale, but that is available to abuses too, and it will require limitting the access to people who prove they can be trusted
Dzonatas Sol: like... a way to sign off on them as reviewed
Soft Linden nods to Dzonatas - "Ya"
Squirrel Wood: patch tested would certainly help
Dzonatas Sol: sub-task QA in PJIRA?
Able Whitman: Soft, I think that would be great. And maybe a "code reviewed" flag as well?
Dale Glass: what abuses?
Dale Glass: here's what I do
Dale Glass: I mirror the SL SVN repository
Dale Glass: and publish my own
Dale Glass: with changes from that
Very Susanti: well people can add nonsense just for fun
Dale Glass: nono, I can't write to the LL one
Very Susanti: or they could just not do a regression to make sure they don't break stuff
Soft Linden: Rob - are we able to easily add searchable flags to JIRA?
Dale Glass: nobody can add anybody for fun because everybody runs their own tree
Dale Glass: *anything
Rob Linden: yes, the flags can be added, but I'd want to be thoughtful about what to add. people have a tough time with what's already there
Boroondas Gupte: so, more something like git than svn?
Dale Glass: yep
Dale Glass: I use svk
Boroondas Gupte: :-D
Very Susanti: not familiar with those tools, anyone have links?
Dzonatas Sol: Soft, I like to see a sub-task for such QA, like it is internally
Rob Linden: well, there is a movement afoot to start using Mercurial at Linden Lab, but nothing official yet
Dale Glass: http://svk.bestpractical.com/
Dale Glass: SVK is a bit lacking in documentation, though
Very Susanti: I am admittidly new to open source, most of my experience is coding in closed controlled corp enviroment
Boroondas Gupte: http://git.or.cz/
Boroondas Gupte: (used by the linux kernel folks)
Very Susanti: haha we should use git just for the name
Dale Glass: this is a good SVK intro: http://pickscrape.woobling.org/svk-visual-guide.pdf
Rob Linden: Bryan O'Sullivan (Sardonyx Linden) is very closely associated with Mercurial, so if we went with a distributed system, it'd almost certainly be that
Dzonatas Sol: are we suggesting public builds being placed on external jira to test a bulk of patches... like release-candidate?
Dale Glass: Rob, I use SVK because it was what worked best with the current SVN, but if LL uses something else of course I'll adopt it (so long it works ;-)
Very Susanti: and so long as it is free too
Soft Linden: Dzonatas - possibly. At the very least, out there for people to test for brokenness. Could be that OSS-only stuff is hashed out on the mailing list, instead of PJIRA. At people's preference.
Dale Glass: but, IMO, LL will have to eventually switch to something distributed, as the current system is limiting and inconvenient
Rob Linden: sure, it just could take us a little while
Rob Linden: getting back to the original point that Soft was making...
Alissa Sabre: Soft, what was your problem?
Dzonatas Sol: it seems appropriate for the het-grid
Rob Linden: ...right now, patch integration involves a lot of dev work on our end, due to the reasons Soft cited above
Soft Linden: Alissa - many of the patches we get are fairly broken, adding new bugs, or not doing quite what they claimed. I'm after a way to get some peer validation of patches.
Alissa Sabre: Do you want to identify a broken patch in good patches?
Very Susanti: well then the burden of merging branches to you guys though
Dale Glass: well, precisely the benefit of a distributed system is that it makes easy for people to import changes from other's trees
Boroondas Gupte: it would be great to get the non-techy folks into testing patches as well (for example if the patch implements a feature they were waiting for). If there was a way to machine-readably include the source version a patch was made against, a mechanism could be imagined where you can select some patches from jira, click a button and download you coustom patched ready compiled bineries some later.
Rob Linden: distributed system is just mechanism
Rob Linden: the point is "not all patches are created equal"
Dale Glass: of course
Very Susanti: well that is a long time issue with patches
Dzonatas Sol: I believe we understand how a patch can go from a complete simple implementation to a nightmare in the end.
Alissa Sabre: Ok. (1) Make clear which version a patch is against, (2) THe problem the patch tries to solve, (3) How can a tester know the patch is working.
Dale Glass: but mechanism IMO is important too. For example with patches it's hard to keep up with active development. I release a patch, somebody tests it, then I release an updated version and it'll take them some effort to merge that
Very Susanti: and I suppose the point is most of us do not develop against a fixed build but instead a code branch
Alissa Sabre: Dale, what do you mean by "updated version"?
Very Susanti: exactly Dale, the older a patch is the less likely it will be current
Soft Linden: Yeah. That's where I'd commit to fastlining patches that were validated against current code, and validated by someone with a good track record.
Alissa Sabre: If a patch is to fix a bug, and your first patch surely fixed the bug, why you need another version?
Squirrel Wood: because that first patch might have some undesired side effects?
Very Susanti: and if you are getting ready for testing a patch you could alert the contributer so they have a chance to update it
Alissa Sabre: Ah, ok. That's understandable.
Very Susanti: that way they won't be penalized if the patch has been simply made out of date due to another change
Dzonatas Sol: Sounds like it would be good two have two release-candidates. One internally, and one externally.
Dale Glass: What I mean is:
Alissa Sabre: Or, to modify the patch for a newer release of the viewer code base
Dale Glass: I have my tree. Suppose I merge your patch for testing
Soft Linden: Right. And part of the problem there is patches that were allowed to get stale. We *need* to not let that happen with usable patches.
Dale Glass: your patch will be against a clean tree
Rob Linden: it'd be nice to implement code reviews somehow
Squirrel Wood: Invalidate patches that were developed on old code versions?
Dale Glass: now, you update and resubmit your patch. So I don't get a diff between old patch and new patch
Rob Linden: not just "look at my patch" but a Q&A style
Dale Glass: that means I need to do management on my side to integrate things every time you re-release it
Dzonatas Sol: Patches applied through Bug Triage can be immediately applied to the external RC
Dzonatas Sol: or likewise
Very Susanti: yes but then you are forcing people to nurse patches which may never be accepted
Able Whitman: I agree,Rob. While I might not be able to download and test every patch, I would make an effort to help code review every patch that is scheduled for triage.
Dzonatas Sol: If it helps us stay on the same branch... it is good
Dale Glass: now, my SVN server is set up in such a way that somebody can keep up with my code. They can merge my original change, then keep merging small improvements I make
Soft Linden: I do like the idea of externalizing our process somewhat. When we check something in, we encourage people to say (a) what the patch does, (b) the reasoning behind it, (c) how to test it, (d) what compnents were affected. Not everyone follows that to the letter, but even just having to make those comments can help you catch things yourself.
Very Susanti: have you made a wiki page on how you would like patch report to look like with one or two examples, Torley did that recently with Jira bugs
Dzonatas Sol: Rob, yes, the Q&A style is right on the money =)
Soft Linden: I don't know of one, Very, but that's a good idea.
Alissa Sabre: I personally prefer something like a fill-in form to submit a patch.
Boroondas Gupte: there's a page on how to create patches, but none on what comments to include in jira when submitting
Able Whitman: Having patch submitters also include at least some basic test cases would be very good.
Rob Linden: yeah, there's a wiki page out there. new jira fields are also possible, but my concern about complexity remains
Soft Linden: /softask Patch JIRA description in patching guide
/softask: Task from Soft Linden accepted by server.
Very Susanti: I just wish I knew a good way of keeping a viable patch current, in a way that is not a terrible burden to the developer
Soft Linden: Very, if we could spot the viable patches, we'd be able to selectively get those in faster.
Soft Linden: Shouldn't be a need to go to extra work to keep them current, then.
Very Susanti: well it would be easier if developer knew the was a "code freeze" for a build on Tues
Very Susanti: and possibly they could test their patches then and mark them as viable or not
Very Susanti: and maybe have a time period to fix them
Soft Linden: That's a thought. We already tend to know what patches we'll be discussing/importing during triage... maybe advance notice on those?
Very Susanti: but working against a continuously changing codebase is always going to present problems
Very Susanti: and the code freezes could be numbered too
Very Susanti: should
Rob Linden: since we're coming up on 5 min to end of scheduled time, is there anything in the agenda that people were counting on talking about?
Very Susanti: even if they are not the same numbers as the main code release numbers
Rob Linden: (I don't want to cut this conversation off if not)
Rob Linden: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda
Very Susanti: just owner permission in the object updates
Able Whitman: I came mostly to talk about patch testing, code reviews, and test cases :)
Dzonatas Sol: I think of a simle way we can do Soft's desire with a sub-task during Bug Triages... and follow-up on sldev
Dzonatas Sol: I'll*
Dzonatas Sol: any objections?
Soft Linden: I'm not quite clear on what that would be, Dzonatas.
Soft Linden: A sub task during the triage... like asking if anyone there had tested it?
Dzonatas Sol: a sub-task to start a QA of items to import... (the loose idea of it)
Dzonatas Sol: ya
Soft Linden: Okie, so in advance ya mean.
Dzonatas Sol: hopefully in advance, yes
Dzonatas Sol: =)
Soft Linden: Or I guess it wouldn't need to be. Just picking what gets imported during triage, then people agreeing to test it. But just some way of selecting things that get imported conditioned on their being tested would be great!
Soft Linden: Very, you said object -permissions- during update? Or did you mean owners?
Very Susanti: yes ooops
Very Susanti: I am in sllloooowwww motion here
Soft Linden: All good. Making sure I didn't miss something!
Very Susanti: well actually this is a wider topic, and not just an open source issue anyway.
Rob Linden: k, gotta run myself
Dzonatas Sol: Thank you ROb
Soft Linden: Thanks, Rob :)
Rob Linden: (I dunno about Soft or others)
Dzonatas Sol: for your time
Soft Linden: I can be around for another few minutes - not *too* long though...
Rob Linden: thanks all for coming!
Retrieved from "https://wiki.secondlife.com/w/index.php?title=Open_Source_Meeting/2007-07-12&oldid=25787"