Date: Mon, 06 Jan 2003 11:14:42 -0500 (EST) From: John Baldwin To: Niklas Johannes Saers Cc: re@freebsd.org Subject: RE: releng process On 05-Jan-2003 Niklas Johannes Saers wrote: > Dear Sirs, > My name is Niklas Saers (call me Nik) and I'm writing a masters thesis on > the processes in the FreeBSD project. > > I was wondering how much http://people.freebsd.org/~jhb/docs/releng.txt > applies to the release engineering process. Should I totally disregard it > and trust only > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/article.html ? > What I find of particular interest in jhb's document is differences in > timelines for X.0 releases as opposed to X.Y releases. My document was more just putting ideas on paper. The second document was written later and is a much more accurate model of how release engineering currently works in FreeBSD. It's also based on the actual processes used in the past few releases. > Also, I would like to ask how much these two documents are stuck to during > the release engineering processes? Do the timelines stick? Are the > responsabilities as clearly defined as the documents give impression of? > How much have these process descriptions been followed during the release > engineering process of 5.0? I think the timelines have almost always slid. For a typical example, you can see the schedule for 4.7 release at http://www.freebsd.org/releases/4.7R/schedule.html which includes scheduled and actual dates for several of the steps in that release. Similar schedules are available for 4.5, 4.6, and 5.0. Looking back we seem to be developing a trend of getting worse in terms of slippage. :-/ One thing that these schedules do not reflect, however, are when we make a decision to delay a release and then change the estimated dates on the schedule to reflect that delay. 5.0 is a rather exceptional case of this as it was originally scheduled to be released on November 15. However, 5.0-DP2 ended up being released nearly 5 months late on November 18 which is when the actual code freeze for 5.0 began. We do seem to be mostly on track to release 5.0 on it's currently scheduled date of January 17. -- Date: Wed, 8 Jan 2003 11:57:30 +0100 (MET) From: Niklas Johannes Saers To: John Baldwin Cc: re@freebsd.org Subject: RE: releng process Hi John, thanks for anwering so quickly. > My document was more just putting ideas on paper. The second document was > written later and is a much more accurate model of how release engineering > currently works in FreeBSD. It's also based on the actual processes used > in the past few releases. Then I will disregard those notes. But the second document doesn't seem to contain much about the timeline. Are those ideas from the first paper the main ideas used when planning and making the release schedule? Since you say that the timelines have almost always slid, how do the past experiences get used when making the schedule for an upcoming release? Thanks for the schedule pointers. > One thing that these schedules do not reflect, > however, are when we make a decision to delay a release and then change > the estimated dates on the schedule to reflect that delay. Since the documents themselves do not reflect this, is this reflected somewhere? If not, would you mind telling me more about this? > However, 5.0-DP2 ended up being released > nearly 5 months late on November 18 which is when the actual code > freeze for 5.0 began. Reading the CVS notes for www/en/releases/5.0R/schedule.sgml I don't get the impression that a specific date was planned for DP2 (rev 1.10). What would affect the planning process at this time, and what measures did/does the re team have for pushing for a stable DP2 release? > We do seem to be mostly on track to release 5.0 on it's currently > scheduled date of January 17. I would like to wish you the best of luck for this release. I've been using 5.0 for quite some time on my desktop and know the FreeBSD team has been doing a really good job. Sincerely yours Niklas Saers -- Date: Wed, 8 Jan 2003 12:04:48 +0100 (MET) From: Niklas Johannes Saers To: John Baldwin Subject: RE: releng process PS, one thing I forgot to ask about http://people.freebsd.org/~jhb/docs/releng.txt vs http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/article.html is if the roles from the first document still stick? Are the roles stable, official FreeBSD roles, or do they and their responsability change much depending on who is in the re team? Sincerely yours Niklas Saers -- Date: Wed, 08 Jan 2003 10:44:30 -0500 (EST) From: John Baldwin To: Niklas Johannes Saers Cc: re@freebsd.org Subject: RE: releng process On 08-Jan-2003 Niklas Johannes Saers wrote: > Hi John, thanks for anwering so quickly. > >> My document was more just putting ideas on paper. The second document was >> written later and is a much more accurate model of how release engineering >> currently works in FreeBSD. It's also based on the actual processes used >> in the past few releases. > > Then I will disregard those notes. But the second document doesn't seem to > contain much about the timeline. Are those ideas from the first paper the > main ideas used when planning and making the release schedule? Since you > say that the timelines have almost always slid, how do the past > experiences get used when making the schedule for an upcoming release? Well, I think the timelines from that first paper might have been used some. However, that first paper was properly based on the informal guidelines that Jordan used when planning releases prior to 4.4. Murry and I both worked with Jordan (Murray longer than I did) to help get releases done so to speak and thus I guess we both have assumptions based on that that aren't written down anywhere. :-/ (I've been helping with releases since 4.1.) I think we've basically have a schedule for -stable releases of having about a month code freeze prior to release along with cutting a release every 4 months or so. Some of the more recent changes have been to try and release Release Candidates more often and on a more fixed schedule (about once a week or so). For releases from -current, there aren't any really good guidelines as it is really a fairly rare occurrence as far as releases of FreeBSD go (just contrast the 3.[12345] and 4.[1234567] releases with 3.0 and 4.0 to see the difference in frequency). Thus, I think -current releases are something we don't understand as well and they are much more of an art than a science at this point. At least, they are not as well organized as -stable releases. > Thanks for the schedule pointers. > >> One thing that these schedules do not reflect, >> however, are when we make a decision to delay a release and then change >> the estimated dates on the schedule to reflect that delay. > > Since the documents themselves do not reflect this, is this reflected > somewhere? If not, would you mind telling me more about this? Well, in theory releases on a given branch (such as 4.x releases) are supposed to happen every 4 months, so if you compare the actual release dates of 4.x releases, you can see how well or poorly we met that schedule. >> However, 5.0-DP2 ended up being released >> nearly 5 months late on November 18 which is when the actual code >> freeze for 5.0 began. > > Reading the CVS notes for www/en/releases/5.0R/schedule.sgml I don't get > the impression that a specific date was planned for DP2 (rev 1.10). What > would affect the planning process at this time, and what measures did/does > the re team have for pushing for a stable DP2 release? I think we had a date, but it wasn't put in the 5.0 schedule. We've only recently started using schedules such as this and we originally planned when to do DP1 and DP2 back in February of 2002 at BSDCon. I don't think we had a schedule page at that time but that it was added later. Had we used one from the beginning it might have helped us get things done sooner. Another problem we had was that when we tried to release DP2 earlier, people kept committing things that broke large pieces of the kernel, so we would wait until things settled down, and then someone would go and break something else. One of the features that did cause a lot of breakage (KSE-III commit) was something we wanted to be in DP2, so we really didn't want to release DP2 with stuff that was before all the breakage began. re@ really didn't assert itself to try and keep people from breaking things until we got towards the end of the DP2 cycle (probably around September or so). We weren't perfect but I think we learned a lot. :) One thing to keep in mind is that this is the first release off of -current that this re@ team has done. All the prior -current releases were done by Jordan for the most part. >> We do seem to be mostly on track to release 5.0 on it's currently >> scheduled date of January 17. > > I would like to wish you the best of luck for this release. I've been > using 5.0 for quite some time on my desktop and know the FreeBSD team has > been doing a really good job. Thanks. -- Date: Wed, 08 Jan 2003 10:57:22 -0500 (EST) From: John Baldwin To: Niklas Johannes Saers Subject: RE: releng process On 08-Jan-2003 Niklas Johannes Saers wrote: > PS, one thing I forgot to ask about > http://people.freebsd.org/~jhb/docs/releng.txt vs > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/article.html > is if the roles from the first document still stick? Are the roles stable, > official FreeBSD roles, or do they and their responsability change much > depending on who is in the re team? The roles were largley my thinking about how to do things. When I wrote releng.txt all we had was for the most part one release engineer and a guy who worked on the ports releases. We have adopted some parts of releng.txt now. We have a group of release engineers with a head RE (though I think we are moving to a model where each release (or possibly each branch) has its own head RE rather than there being just one head RE for all releases.. this is a very recent change), we have a mailing list and small group for each architecture that is responsible for handling the builds, etc. of that architecture. We don't really have a re-ports right now, we just talk to the portmgr@ people and they handle it, but there isn't really a specific release engineer-ports liason. Well, there isn't a formal one, but one member of portmgr@ (kris@) has become the defacto liason. :) We don't really have a re-docs right now either. The doceng@ group manages doc/ and lays down the tags at the appropriate time though, and docs are built as part of the release build process that the re- people do, so re-docs isn't all that pressing and docs/ are handled ok. We don't have a re-qa@ at all. The qa@ list itself is rather quiet as well though, and in general there is a need for more QA work in FreeBSD. -- Date: Wed, 08 Jan 2003 22:05:03 -0800 From: Bruce A. Mah To: John Baldwin Cc: Niklas Johannes Saers , re@FreeBSD.org Subject: Re: releng process Parts/Attachments: 1 Shown 66 lines Text 2 231 bytes Application ---------------------------------------- If memory serves me right, John Baldwin wrote: > > Thanks for the schedule pointers. > > > >> One thing that these schedules do not reflect, > >> however, are when we make a decision to delay a release and then change > >> the estimated dates on the schedule to reflect that delay. > > > > Since the documents themselves do not reflect this, is this reflected > > somewhere? If not, would you mind telling me more about this? > > Well, in theory releases on a given branch (such as 4.x releases) are > supposed to happen every 4 months, so if you compare the actual release > dates of 4.x releases, you can see how well or poorly we met that schedule. At one point I did some checking, and it seems that for the past several 4.X releases we were fairly consistent about having ten days of schedule slippage by time the release finally got out the door. To find that, one would need to compare the first checked-in revision of the release schedule with the last one, to account for schedule changes made during code-freeze. About the "release every 4 months" part...I have some reservations as to whether or not we'll be able to do that when we're simultaneously releasing from the 5.X and 4.X branches. It basically would mean doing twice the work with the same number of people. We haven't discussed this very much, however. > >> However, 5.0-DP2 ended up being released > >> nearly 5 months late on November 18 which is when the actual code > >> freeze for 5.0 began. > > > > Reading the CVS notes for www/en/releases/5.0R/schedule.sgml I don't get > > the impression that a specific date was planned for DP2 (rev 1.10). What > > would affect the planning process at this time, and what measures did/does > > the re team have for pushing for a stable DP2 release? > > I think we had a date, but it wasn't put in the 5.0 schedule. We've only > recently started using schedules such as this and we originally planned > when to do DP1 and DP2 back in February of 2002 at BSDCon. I don't think > we had a schedule page at that time but that it was added later. Had we > used one from the beginning it might have helped us get things done sooner. Maybe. I think the point you made below illustrates that it's basically hard trying to predict when things will be stable enough to release (even for a developer preview). Certainly nobody expected that DP2 would be five months late. > Another problem we had was that when we tried to release DP2 earlier, people > kept committing things that broke large pieces of the kernel, so we would > wait until things settled down, and then someone would go and break something > else. One of the features that did cause a lot of breakage (KSE-III commit) > was something we wanted to be in DP2, so we really didn't want to release DP2 > with stuff that was before all the breakage began. re@ really didn't assert > itself to try and keep people from breaking things until we got towards the > end of the DP2 cycle (probably around September or so). We weren't perfect > but I think we learned a lot. :) One thing to keep in mind is that this is > the first release off of -current that this re@ team has done. All the prior > -current releases were done by Jordan for the most part. I thought it noteworthy that when we finally did get more assertive, we seemed to get approval from most of the other developers pretty quickly. Bruce. -- Date: Mon, 13 Jan 2003 08:45:32 -0800 From: Bruce A. Mah To: Niklas Johannes Saers Cc: re@FreeBSD.ORG, John Baldwin , Bruce A. Mah Subject: Re: releng process Parts/Attachments: 1 Shown 83 lines Text 2 231 bytes Application ---------------------------------------- If memory serves me right, Niklas Johannes Saers wrote: > Hi, and thank you (John and Bruce) for your answers. I've included both > the answers in this mail. > > First of all, I'd like to ask how you handle the feature freeze. It's not > mentioned in articles/releng/article.html, yet it's something that I've > seen both on your schedule and in mailinglists. Hmmm. Well, very roughly, feature freeze means that anything that adds new functionality needs to be approved by re@ first. Bug fixes, documentation updates, etc. can usually continue without re@ approval. I guess we don't define this very well. :-p > Another thing I wondered about, I understand you use Perforce for the > release engineering. Why do you use this, and does the synchronization > between CVS and Perforce give you much extra work? We've used Perforce (which most of us abbreviate as P4) to help us do the 5.0-DP1 and 5.0-DP2 snapshots. But we do all the rest of the release engineering work using CVS (including the in-progress 5.0-RELEASE). CVS is, and remains, the "official" source code repository until explicitly changed (I think core@ would be responsible for this, but they would be relying on input from a lot of the teams, including re@). P4 is used by a number of developers as an source code control system for side projects before they get committed to the main CVS repository. Automated imports take care of importing the current CVS state into P4 and making P4 views available. [I'll let John answer John's questions!] > Bruce: > > About the "release every 4 months" part...I have some reservations as to > > whether or not we'll be able to do that when we're simultaneously > > releasing from the 5.X and 4.X branches. It basically would mean doing > > twice the work with the same number of people. We haven't discussed > > this very much, however. > > If I understand correct, last time two branches were being released > simultanious, Jordan was doing most of the work, with help from Murray? This was before I joined the RE team (actually before I got my commit bit), but I think that's the case, yes. > I > understand you haven't discussed this much, but do you have any thoughts > on the subject? Such as, how long do you plan to continue 4.X? When 5.1 is > out the door, what would be the advantages of keeping the 4.X thread alive > rather than turning it into a security branch? Not everybody wants to (or *should*) jump on the 5.0 bandwagon immediately, and we basically don't want to abruptly end the 4.X line for the more conservative users. As I wrote in the Early Adopter's Guide (have you had a chance to read this?), the number of remaining 4.X releases depends on a number of things: Perceived stability of the 5.X line (and creation of the RELENG_5 branch). RE resources (I see manpower becoming a major issue here). User demand. Some of the changes that jhb mentioned in his answers (one head RE per branch) might help us out in terms of not getting a single head RE burned out. But I still suspect we're going to have a manpower shortage on the RE team for 2003. > > I thought it noteworthy that when we finally did get more assertive, we > > seemed to get approval from most of the other developers pretty quickly. > > Is this an incentive to be more assertive about sticking to schedule? (ref > the question above to John regarding advantages of sticking to schedules) I'd say so, to a certain extent. We do need to remember that FreeBSD is largely a volunteer project, so we can't push people *too* hard. (This reminds me of Keith Bostic's keynote talk at BSDCon 2000 on managing open source software projects.) Hope this helps! Bruce. -- Date: Mon, 13 Jan 2003 12:00:55 -0500 (EST) From: John Baldwin To: Niklas Johannes Saers Cc: Bruce A. Mah , re@freebsd.org Subject: Re: releng process On 13-Jan-2003 Niklas Johannes Saers wrote: > First of all, I'd like to ask how you handle the feature freeze. It's not > mentioned in articles/releng/article.html, yet it's something that I've > seen both on your schedule and in mailinglists. Basically, in a feature freeze, committers can commit small bugfixes without any re@ approval. New features and major changes have to be approved by re@ however. In a code freeze, all changes must be approved by re@. > Another thing I wondered about, I understand you use Perforce for the > release engineering. Why do you use this, and does the synchronization > between CVS and Perforce give you much extra work? We have only used Perforce for the 5.0 developer preview releases. All offical releases and release candidates are done in CVS. Perforce was used for the DP's because several folks on re@ find p4 more adept at manging branches than CVS and because we wanted to avoid putting extra branches into the CVS repo since CVS does not handle branches efficiently. > John: >> I think we've basically have a schedule for -stable releases of having >> about a month code freeze prior to release along with cutting a release >> every 4 months or so. > > When do you set the date for a new release? Who does this? Is this done > after every new release, or would for instance a release schedule for 5.x > be set up when 5.1 goes out the door? I think the schedule is set such that release X.Y + 1 is scheduled for 4 months after X.Y. That is, we schedule one at a time I think rather than scheduling them all relative to X.0. Also, when releasing on two different branches we sometimes change the schedule. For example, 4.8 was supposed to be released in February, but we are not going to start working on 4.8 until 5.0 is finished. > Also, regarding schedules (such as www/releases/5.0R/schedule.html), when > are these made and who decides the dates? Is this different for .0 > releases, STABLE-releases and security branch releases? Usually the date is decided because someone on re@ sends out a mail like "gee, we released 4.X about 2.5 months ago, shouldn't we be getting ready for a freeze and release cycle right about now?" Not very formal I guess. For X.0 releases the scheduling is more of a consensus among several FreeBSD developers who are not on re@ along with the members of re@. > Why was it decided to make more release candidates? I can understand it > for .0 releases, but isn't STABLE considered an ongoing release candidate? > Or is there more into being a release candidate than what is in a STABLE > snapshot? -STABLE really is not an ongoing RC. Between release cycles, committers are allowed to merge things into stable using their own judgement without explicit re@ approval. During the cycle changes going into -stable require explicit re@ approval. The first RC in a cycle is usually cut so developers and testers can get a feel for what condition -stable is in and what bugs there are that need to be fixed for the release. Further RCs provide a means of checking for regressions and verifying fixes for problems found in earlier RCs. >> Thus, I think -current releases are something we don't understand as >> well and they are much more of an art than a science at this point. At >> least, they are not as well organized as -stable releases. > > What do you mean by them being much more of an art than science? Well, if it were a science, we would have a set of rules and a set process to follow. We don't really have those set rules for X.0 releases, we are still figuring out what those rules might be. Hence it is more of an art at this stage. > Do different people go into making .0 releases than .X releases? Well, the same people are on re@, but different changes go into different types of releases. X.Y releases do not generally contain large architectural changes or experimental changes. X.0 releases do usually contain those types of changes however, so different levels of testing and amounts of bugfixing, etc. are required for X.0 releases. >> Well, in theory releases on a given branch (such as 4.x releases) are >> supposed to happen every 4 months, so if you compare the actual release >> dates of 4.x releases, you can see how well or poorly we met that >> schedule. > > For this theory, could you point me to where this is written or tell me > where this theory comes from? (I don't mean to be picky, it's just that it > would be a good reference :) ) Not sure if it is written anywhere. I think Jordan (previous re@) might have stated it in some e-mails, and I believe I have heard him state it in person. The current re@ team has just continued with that practice. I think that the original reason for every 4 months was so that Walnut Creek CD-ROM could plan for when to sell new CD's of FreeBSD as far as scheduling when to send master CD's off to the duplicators, schedule time at the duplicators, and when to hire temps to help mail out all the CD's, etc. > Has it been your experience that having a schedule has made it easier to > get things done? Well, I think it helps us (me at least) remember to get things done better. Personally, I work better when I have a todo list when I am completeing a complex task and am less likely to omit certain steps. > You say that people would break the code when including some features you > really wanted in DP2. Does re@ decide what features go into a particular > release? Yes, re@ makes the call on when to release the DPs and what changes we want to be in each DP. >> We have a group of release engineers with a head RE (though I think we >> are moving to a model where each release (or possibly each branch) has >> its own head RE rather than there being just one head RE for all >> releases. > > How are you changing these structures? By discussion on the mailinglists > only? Do you need approval from the committer community or core, or are > you largely a self-organized group when it comes to such issues? We are self-organized. We discuss such changes either in e-mail or on weekly teleconferences. (We have held teleconferences weekly during the 5.0 release cycle, for "normal" X.Y releases we have not used teleconferences in the past.) >> We don't have a re-qa@ at all. The qa@ list itself is rather quiet as >> well though, and in general there is a need for more QA work in FreeBSD. > > I would imagine that your group is particularly affected by the lack of QA > work. Is this something you are trying to push, or are there other groups > that push more for this? (I read the qa list and as you say, it's very > quiet) Well, most of the people on re@ are already very busy and don't have time to push for better QA. :-/ Personally, I try to spend some time before major releases fixing bugs in the installation utlity and trying to improve the "user experience" during the installation process, but that is most of the extent of how much I push QA. Other folks on re@ contribute similarly. I hope all this is helping you with your paper. :) -- Date: Wed, 15 Jan 2003 06:31:57 -0800 From: Bruce A. Mah To: Niklas Johannes Saers Cc: Bruce A. Mah , re@FreeBSD.org, John Baldwin Subject: Re: releng process Parts/Attachments: 1 Shown 65 lines Text 2 231 bytes Application ---------------------------------------- If memory serves me right, Niklas Johannes Saers wrote: > Hi Bruce, and thanks for your helpfull answers :) You're welcome. :-) > > > First of all, I'd like to ask how you handle the feature freeze. > > Hmmm. Well, very roughly, feature freeze means that anything that adds > > new functionality needs to be approved by re@ first. Bug fixes, > > documentation updates, etc. can usually continue without re@ approval. > > Ah, sorry, I phrased my question badly. When does feature freeze happen in > the process? It's set in the schedule, but articles/releng does not > mention it. Is this 15 days before the code freeze, extending the period > from 45 to 60 days? OK. For the 4.X releases, there really isn't much of a feature freeze (right, guys?), just the code freeze. Remember there is a much smaller set of features that can be added to 4.X than to CURRENT (because everything in 4.X had to live in CURRENT first). The releng article doesn't really cover 5.0 (which did have a well-defined feature freeze) because as we've discussed already, the ".0" releases are very different from the ".N" releases, where N>0. > > As I wrote in the Early Adopter's Guide (have you had a chance to read > > this?) > > I'm sorry, I had not read the Early Adopter's Guide. I did now and I see > it answered the questions with regards to planned releases. No problem. We have lots of documentation and picking out which thing you should read is sometimes hard. > > Some of the changes that jhb mentioned in his answers (one head RE per > > branch) might help us out in terms of not getting a single head RE > > burned out. But I still suspect we're going to have a manpower shortage > > on the RE team for 2003. > > Is there a willingness to help with this in the community? I think there are some people who have expressed interest in helping out, yes. At the same time, we need to make sure that anyone that we bring onto the team has a set of skills that matches up with what we need. > Is the learning > curve for developers wanting to help out with RE long? Hmmm. Ask that to scottl...he only joined the team a few months ago and he's basically taken over the overall 5.0 release process. :-) It depends on what a new RE team member would be doing. For myself, I got eased in pretty well because I basically kept on doing what I was doing anyways (release documentation). After a few releases, I started helping out with some other areas like snapshot builds and fixing some small point problems. I would hazard a guess that one release cycle is enough to bring a new team member "up to speed". Cheers, Bruce. --- Date: Wed, 15 Jan 2003 16:11:53 -0700 From: Scott Long To: John Baldwin Cc: Niklas Johannes Saers , re@freebsd.org, Bruce A. Mah Subject: Re: releng process John Baldwin wrote: [...] > Not really. :) The only thing we've really talked with them about is > Java on FreeBSD but those conversations have been very brief and haven't > resulted in anything so far. > I'd like to interject that there is a lot of informal contact with Foundation members. Their scope does not intersect ours, however, so little very coordination is needed (in contrast to NetBSD where the NetBSD Foundation plays a much more active role in day-to-day things). Also note that the FreeBSD Foundation has helped fund the previously mentioed Developer Summits. -- Date: Wed, 15 Jan 2003 11:37:00 -0500 (EST) From: John Baldwin To: Niklas Johannes Saers Cc: re@freebsd.org, Bruce A. Mah Subject: Re: releng process On 15-Jan-2003 Niklas Johannes Saers wrote: > Hi John, and thanks again for taking the time to answer so extensively :) > >> For X.0 releases the scheduling is more of a consensus among several >> FreeBSD developers who are not on re@ along with the members of re@. > > So the discussions regarding the X.0 releases are more likely to be on the > developer@ list? Not really. The decision to delay 5.0 a year back in the fall of 2001 was largely the result of a private conversation on IRC between Jordan and myself for example. The planning for this release cycle was partially worked out at the developer summits (in-person meetings of developers who could make it to the recent Usenix ATC and BSDCon conferences) and partially worked out in either private e-mail, IRC conversations, private in-person conversations at conferences (I know we had a brief meeting between Murray, Robery, and myself at BSDCon prior to the developers summit to talk about dates for the developer previews and other schedule issues), etc. I would say that the number of people who aided in the decision who are not on re@ is not a large number, more like maybe 10 or so. >> We are self-organized. We discuss such changes either in e-mail or on >> weekly teleconferences. (We have held teleconferences weekly during the >> 5.0 release cycle, for "normal" X.Y releases we have not used >> teleconferences in the past.) > > This sounds like quite an expense each of you are carrying? Are you doing > this over IP, or do you get this covered by i.e. the FreeBSD Foundation? Actually, Robert's employer is currently providing the teleconferences for us and AFAIK it is not incurring an out of pocket expense for Robert. > Regarding the Foundation, does the re@ group have much contact with them > at all? If so, in what ways? Not really. :) The only thing we've really talked with them about is Java on FreeBSD but those conversations have been very brief and haven't resulted in anything so far. >> I hope all this is helping you with your paper. :) > > Thank you very much, it is. :) Regarding that, my paper is two part. The > first part is a methodology for the FreeBSD project based on what is > available of articles, mailinglists and questions like this. The second > part is my thesis which basically is background, steps towards making the > methodology, rearch results, the methodology and an analysis based on the > response from the community and seeing how fit such a methodology is. > Whereas the second part is a far way of, I'd like to send the actual > methodology to all those who have helped with information to verify the > correctness / make important changes before it's released to the community > and (hopefully) imported to the docs. I regard the document as a live > document, being up for change almost all the time as the project will > surely keep changing. Sounds good. :) -- Date: Wed, 15 Jan 2003 16:11:53 -0700 From: Scott Long To: John Baldwin Cc: Niklas Johannes Saers , re@freebsd.org, Bruce A. Mah Subject: Re: releng process John Baldwin wrote: > Not really. :) The only thing we've really talked with them about is > Java on FreeBSD but those conversations have been very brief and haven't > resulted in anything so far. > I'd like to interject that there is a lot of informal contact with Foundation members. Their scope does not intersect ours, however, so little very coordination is needed (in contrast to NetBSD where the NetBSD Foundation plays a much more active role in day-to-day things). Also note that the FreeBSD Foundation has helped fund the previously mentioed Developer Summits. Scott