Changes between Version 1 and Version 2 of WeeklyMinutes20100204

Feb 5, 2010, 12:28:52 PM (9 years ago)



  • WeeklyMinutes20100204

    v1 v2  
    9494Michael: done, and the review is done, need to merge into trunk
     96= Release countdown: 6 weeks! =
     98Shane: That's it. 6 weeks to go!!!
     100= Release plan =
     102Jeremy: 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.
     104Jeremy: Going to be over 70 steps. Probably over 100 things to do, so we need a checklist.
     106= Pre-IETF gathering? =
     108Shane: Was idea to maybe get together a few days before the IETF at 950 to do the final work for the first release.
     112Shane: 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.
     114= Status Check =
     116In future, these will be done via an e-mail before the call. This week send ASAP (not ideal, since after the call, but...)
     118Likun: AXFR-in requirements now on wiki. Try to write message API in Boost Python.
     120Jinmei: What is current status? Already working?
     122Feng: Will start from simple class like Name, and should commit code maybe next week.
     124Jinmei: That's great!
     128Jeremy: 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.
     130Michael: My only concern is calling it "alpha". "Alpha" implies that this is no the path to something that can be run in production.
     132Jeremy: We'll call it a "snapshot".
     134Michael: Snapshot is off of which branch?
     136Jeremy: Parking lot. We will have a trunk, but nothing is there really.
     138Michael: Need to start merging stuff off of trunk, or decide we have to release from parking lot.
     140Shane: we need to move stuff onto trunk anyway.
     142Michael: 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.
     144Shane: Don't see much advantage.
     146Jinmei: Not sure I understand this suggestion. Is this who finally commits it to the trunk?
     148Michael: Or to the release branch.
     150Jinmei: Don't see much advantage either.
     152Larissa: Making sure everything there is possibly a release engineering function?
     154Michael: The advantage of the NetBSD way is that a release engineer can say "this is de-stabilizing".
     156Jelte: we are backwards - normally trunk is backwards
     158Jinmei: might make sense to move current set of DNS message API and review that to move to trunk as soon as possible
     160Shane: don't want unreviewed code, but we can have separate tickets
     162Jeremy: Someone mentioned sweng discussion, and other people were not there. So we're missing a lot of context.
     164Michael: This was just a status sent to the sweng list, what we will be doing to the BIND 10 list.
     166Shane: Goal of killing parking lot as soon as possible?
     168[ Agreed ]
     170Jeremy: 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.
     172Michael: 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.
     174Jinmei: 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.
     176Jeremy: Seems like we need to make a branch and call it "reviewed".
     178Shane: As long as this is systematic, so we can be safe? Jeremy will be owner.
     180Jeremy: What about existing code in trunk?
     182Jinmei: Forget it, I'll deal with it later. It's almost unchanged in parking lot.
     186Jeremy: 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.
     188Jinmei: I thought we had an idea of a checklist?
     190Jelte: 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.
     192Michael: As long as we don't have to go through old reviews...
     194Michael: Can we have this added as a template in the ticket?
     196Jeremy: Maybe... I don't know, but maybe...
     198'''AP''' Jeremy to update review process to say to cut & paste checklist into review
     202Jeremy: all code developed is owned by ISC, so everyone needs to know that
     204Jeremy: we need to include copyright in code
     206Michael: can we steal the code which looks for copyright in files?
     208Jeremy: for now just do the warnings
     210'''AP''' Jeremy to make sure files are automatically checked for copyright
     212= AOB =
     214Michael: Would like to see a message from Shane every week (starting Monday) with what our goals for that week are.
     216Jeremy: I will help with that too.