wiki:WeeklyMinutes20100204

Notes from the BIND 10 call

Attendees

Jeremy
Shawn
Shane
Likun
Feng
Fujiwara-san
Jelte
Joao
Jinmei
Larissa
Michael
Kambe-san
David

Jabberizing the Call?

Shane: Some people asked if we could try the call via Jabber sometimes. Anyone done that? Opinions?

Jeremy: I do meetings that way, and they go very slow. 15 minutes can take an hour and a half.

Larissa: I am not usually in front of my computer when on this call, so not possible.

Michael: Think it is a rotten idea, since a phone call is good for rapid communication. We can use jabber any time we want.

Shane: Another possibility is to move part of it out of the jabber. For example status.

Michael & Larissa: yes!

Daily Check-ins

https://lists.isc.org/pipermail/bind10-dev/2010-February/000449.html

Michael: If working with someone, can work more real time if in nearby time-zones. So have a 5 minute call.

Jinmei: Only between people working on something?

Michael: Yes.

Jelte: Yeah, but they can just agree on that as needed.

Michael: Yeah, but maybe a daily call for those people.

Michael: Try general-purpose jabber, if we need to then we can try something else.

Jeremy: With the jabber, you don't always have the history. So I may miss discussion from a few hours earlier.

Jeremy: If there is discussion, then...?

Jelte: why not Wiki?

Michael: too many people editing at the same time doesn't work

Michael: why not Twitter?

Michael: lets try the jabber thing and see how it goes

AP from Previous Weeks

Shane to try to make a graph of timeline
Progressing but not done

Jeremy to set up automated coverage testing
Done for C++ googletest

Note about Python tests sent today, will be automated today

Shane: do we send a mail or something if it fails?

Jeremy: will try to get that done today

Jeremy: will ask the lcov list about weird examples

Jeremy will be writing a blog article about the coverage test
Jeremy: Already wrote it. Will send link later today so someone can review it.

Jelte to make proposal on how to use the exception class

Jelte: Made my exceptions a version of Jinmei's exceptions. To make this scale will propose to move Jinmei's exceptions out of isc::dns into isc or isc::common, and probably to do this for the code itself.

Michael: Maybe call this isc::exceptions?

Shane: I like that better...

Michael to update msgq ticket to indicate what exactly is to be reviewed (like which directory)
Michael: done, and the review is done, need to merge into trunk

Release countdown: 6 weeks!

Shane: That's it. 6 weeks to go!!!

Release plan

Jeremy: Started making a checklist. Wanted to talk to Shane offline, wanted to talk about overlap in this. Using previous plans, dates don't match up at all, doing alpha/beta and all that. Need to create a shorter timeline. We have around 42 days, so our release date needs to be the 19th. So I'll talk with you offline, and we can do that today or early tomorrow morning.

Jeremy: Going to be over 70 steps. Probably over 100 things to do, so we need a checklist.

Pre-IETF gathering?

Shane: Was idea to maybe get together a few days before the IETF at 950 to do the final work for the first release.

...discussion...

Shane: sounds like no support for this, but we can arrange for hours and hours of conference calls like Jelte did for the BIND 10 meeting the day before.

Status Check

In future, these will be done via an e-mail before the call. This week send ASAP (not ideal, since after the call, but...)

Likun: AXFR-in requirements now on wiki. Try to write message API in Boost Python.

Jinmei: What is current status? Already working?

Feng: Will start from simple class like Name, and should commit code maybe next week.

Jinmei: That's great!


Jeremy: for the user installation, I need to go through the steps of generating the alpha release tarball so we can go through any "gotchas" and make sure our steps are refined. I haven't even gone through all of that, but I will be. Hopefully have alpha tarball that we can provide to end users by Monday. As of yesterday I was able to run the entire BIND 10 with the authoritative daemon without source.

Michael: My only concern is calling it "alpha". "Alpha" implies that this is no the path to something that can be run in production.

Jeremy: We'll call it a "snapshot".

Michael: Snapshot is off of which branch?

Jeremy: Parking lot. We will have a trunk, but nothing is there really.

Michael: Need to start merging stuff off of trunk, or decide we have to release from parking lot.

Shane: we need to move stuff onto trunk anyway.

Michael: Other projects have insured that things get where they need to go by e-mail to groups for pull-ups into branches. In NetBSD, if you make a change, you commit it to the mainline or branch and then request a pull-up to the branch you want to.

Shane: Don't see much advantage.

Jinmei: Not sure I understand this suggestion. Is this who finally commits it to the trunk?

Michael: Or to the release branch.

Jinmei: Don't see much advantage either.

Larissa: Making sure everything there is possibly a release engineering function?

Michael: The advantage of the NetBSD way is that a release engineer can say "this is de-stabilizing".

Jelte: we are backwards - normally trunk is backwards

Jinmei: might make sense to move current set of DNS message API and review that to move to trunk as soon as possible

Shane: don't want unreviewed code, but we can have separate tickets

Jeremy: Someone mentioned sweng discussion, and other people were not there. So we're missing a lot of context.

Michael: This was just a status sent to the sweng list, what we will be doing to the BIND 10 list.

Shane: Goal of killing parking lot as soon as possible?

[ Agreed ]

Jeremy: Need review of configure scripts and Makefiles. In my case I see errors and warnings, but I haven't had a chance to follow up on this.

Michael: For one-time bootstrap. If we can do this today and tomorrow and get rid of parking lot branch in 2 days? I think we have to do this as one large merge.

Jinmei: Just move the parking lot to the trunk, even without reviewing it. Make a list of which parts should be reviewed. First-time bootstrap workaround. After that we go to the more sophisticated review possible.

Jeremy: Seems like we need to make a branch and call it "reviewed".

Shane: As long as this is systematic, so we can be safe? Jeremy will be owner.

Jeremy: What about existing code in trunk?

Jinmei: Forget it, I'll deal with it later. It's almost unchanged in parking lot.


Jeremy: Comment about review process. Should we have a checklist where the reviewer copies & pastes it into the reply? That way we can show the same checklist... maybe too simple & too redundant. I noticed there was a minor issues in one of the msgq tests, and I just noticed that today. Maybe the reviewer didn't run the tests since it was renamed... so a checklist could verify those things would have been caught.

Jinmei: I thought we had an idea of a checklist?

Jelte: We do have a checklist, but I think what Jeremy means is we go by each line and put "okay" on each line as we go through it.

Michael: As long as we don't have to go through old reviews...

Michael: Can we have this added as a template in the ticket?

Jeremy: Maybe... I don't know, but maybe...

AP Jeremy to update review process to say to cut & paste checklist into review


Jeremy: all code developed is owned by ISC, so everyone needs to know that

Jeremy: we need to include copyright in code

Michael: can we steal the code which looks for copyright in files?

Jeremy: for now just do the warnings

AP Jeremy to make sure files are automatically checked for copyright

AOB

Michael: Would like to see a message from Shane every week (starting Monday) with what our goals for that week are.

Jeremy: I will help with that too.

Last modified 8 years ago Last modified on Feb 5, 2010, 12:28:52 PM