Open Source Meeting/2007-07-12
From Second Life Wiki
Open source meeting - Thursday, 2pm PT
- Testing patches
- Streamlining patch acceptance
- Anything unresolved from SLDev-Traffic 19?
- - Wiki slowdowns
- Linden Lab Innovation Awards
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!