I'm pleased to announce the results of the 2004 committer popularity competition. (Or is it the list of people that we're punishing?). First some stats: * 307 committers enabled in the repository. * 293 (96%) committers entitled to vote. * 235 (77%) committers logged into the election server. * 228 (74%) committers voted. Here are the results: New Core Team ============= rwatson (196) imp (181) peter (164) jhb (146) murray (137) wes (128) scottl (125) markm (109) kuriyama (100) Runners up ========== marcel (98) dfr (92) obrien (68) jmallett (47) mux (47) green (44) cperciva (42) alfred (41) gordon (38) benno (38) krion (29) josef (26) hmp (21) simon (16) This new team is almost exactly the same as the current team with the addition of Scott Long taking over from Greg Lehey. Congratulations Scott. Many thanks Greg. The election schedule has the new core team taking office on Wednesday 14th July. Many thanks to everyone for making the effort to vote. It looks like my work here is done. Regards, Joe ====================================================================== There are 23 candidates running for 9 places on the core team: Alfred Perlstein Benno Rice Colin Percival Doug Rabson Gordon Tetlow Brian Feldman Hiten Pandya Warner Losh John Baldwin Juli Mallett Josef El-Rayes Kirill Ponomarew Jun Kuriyama Marcel Moolenaar Mark Murray Murray Stokely Maxime Henrion David E. O'Brien Peter Wemm Robert Watson Scott Long Simon L. Nielsen Wes Peters ---------------------------------------------------------------------- Alfred Perlstein Last modified: Jun 7 23:07:20 2004 I offer a a unique perspective, a kernel hacker that still remembers what it feels like to be a user. I want things to be easier, more initiative, more usable. I want FreeBSD to be for the users and developers. I've worked on FreeBSD stability and performance issues for the past four years. Mostly SMP, NFS and porting various cool things from other OSes to FreeBSD. My resume is here, it lists most of the FreeBSD work I've done and some of the projects I've worked on. http://people.freebsd.org/~alfred/res.txt http://people.freebsd.org/~alfred/res.pdf http://people.freebsd.org/~alfred/res.html ---------------------------------------------------------------------- Benno Rice Last modified: Jun 3 21:26:54 2004 I've been a FreeBSD committer since November, 2000. I started out working on the PowerPC port which is now in the capable hands of Peter Grehan. Lately I've been doing some work on ATM as it relates to ADSL controllers. My reason for running for a place on core is that I feel that FreeBSD needs people who can assist in smoothing some of the issues we face regarding relationships between developers. I have witnessed a lot of disagreements and arguments on various mailing lists, and I've also seen the efforts of a few people, including those on core.3, to try and diffuse these situations and encourage communication between the people involved that is calmer and more effective. I would very much like to assist this process, as I have done in various jobs in the Real World(tm). I am not the most prolific committer, but I am subscribed to a large number of FreeBSD mailing lists and try to stay very much in touch with the goings on of the project, both at the developer level and the user level. I also think that the more active committers should be encouraged to keep committing. =) I have been using, advocating and developing FreeBSD for many years now and I have a very deep regard and respect for the project and all the people who work on it. I hope I will have the chance to further foster this work. ---------------------------------------------------------------------- Colin Percival Last modified: Jun 29 05:44:44 2004 As I write this, I see 18 statements already online, ranging from 17 lines (scottl) up to 136 lines (murray); the total number of lines of statement is over 900. In light of this, and of my good fortune to be placed close to the top of the list in alphabetical order, I'll keep my statement brief and hope that the reader will find the patience necessary to read all the statements -- not just those in the first half of the alphabet. I got my commit bit in January of this year, and thus far I have only made one major contribution to the project: FreeBSD Update, an entirely binary method of tracking security branches. There are large portions of FreeBSD which are entirely opaque to me, and -- unlike most Computer Science students -- I have never taken an operating systems course in my life. Why, then, do I think that I would make a good core team member? First, because the core team has a multiplicity of roles and needs a variety of skills. Part of the role of the upcoming core team will be to manage the transition to 6-CURRENT; part of its role will be to act as public spokesmen for the project; and part of its role will be to mediate disputes between members of the project. While I lack technical knowledge about FreeBSD, I have found -- somewhat to my astonishment -- that I seem to be a rather effective mediator and communicator; since the list of candidates (and indeed, of members of the project in general) is heavily weighted in favour of those with technical expertise, I think I could bring talents to the core team which would otherwise be insufficiently present. More importantly, however, the precise fact that I am relatively new to FreeBSD gives me a useful perspective on the project. It is all too easy for us to code inside an ivory tower and ignore the large unwashed masses who constitute most of the users of FreeBSD. The issue of binary security updates is a perfect example of this; for years, users of FreeBSD asked for these, but it took a complete newcomer (me!) to step in and produce them. Slightly over a year later, FreeBSD Update has now been used to apply security patches to over five thousand systems. I think my presence on the FreeBSD core team would benefit the project by providing a voice for the regular users: I would be someone who would think about what the average user wants -- and who would help users who are willing to pay for features find a committer who is willing to implement them. To summarize, while a core team comprising of nine Colin Percivals would be a disaster, I think that a core team including one Colin Percival would be better than a core team including none. Thank you for your time. ---- Issues raised over email ---- TRB: I feel that it is important to have some form of technical review board / group / committee. This should be appointed by core rather than elected, since elections inevitably exclude those whose talents are technical rather than electoral. (Just look at politicians: How many of them would you want to see making technical decisions?) That said, I think this group should make recommendations rather than decisions; I imagine that it would be unusual for core to not follow such a recommendation, but the final decision (and blame) should lie with the core team. I would also like to point out that the TRB should not be restricted to resolving disputes; as a member of the security team, I am aware of several times when a problem has arisen in some part of FreeBSD with which nobody on the security team has experience; it should also be possible for the security team to turn to the TRB and say "we need someone to advise us about FOO". Vision: My mother does not run FreeBSD. I don't consider this to be a problem. Nevertheless, I do not think that we should ignore the needs of "Joe Average User" entirely. None of us were FreeBSD experts when we first started using FreeBSD, and we should remember that, in order for the project to continue to grow, it is necessary that we see new people starting to use FreeBSD. In particular, I feel that we should avoid a "sorceror's apprentice" situation, where users can very easily get themselves into problems from which they have difficulty escaping. (Thus my creation of FreeBSD Update; people should not be in the position of knowing how to install FreeBSD but not understanding how to apply security patches.) Money: I don't think that core should take a direct hand in funding developers. However, I think that core should at offer indirect assistance; for example, if a company writes to say "we need feature X, we're willing to pay $Y", then core should at very least write back to say "well, the people working in this area are A, B, and C; those are probably the right people to ask". Communication: I think that core does a reasonably good job of communicating its decisions; however, I think that it needs improvement when it comes to communicating the fact that an issue is being considered. Without allowing such issues to end up as heated debates on the mailing lists, I think that core should more often step forward to say "this issue has come before us, feel free to send us your opinion". To be fair, this seems to have improved in the past couple of months. Rules: I feel that the rules by which the project runs should be flexible, but applied equally to all. ---------------------------------------------------------------------- Doug Rabson Last modified: Jun 5 09:42:09 2004 I've been a FreeBSD user since around the 386bsd 0.1 timeframe (and a BSD user since 4.1BSD). I've been a committer since about 1994, after Jordan phoned me and asked if I would like to just commit a load of patches that I had sent to the usenet group (does anyone still use usenet?). I served as a core team member from 1999 to 2002, first by invitation and later by election. I've worked on all kinds of things for the project, including writing the kernel linker, trying to impose some kind of sanity to the device driver chaos which existing in FreeBSD 2.0, porting the kernel to its first non-i386 architecture (including making it 64-bit clean) and helping to write the three stage loader which we've been using since FreeBSD 3.0. Because of my day job, I have a strong interest in 3D graphics and over the years, I have put some effort into 3D support for FreeBSD including writing AGP drivers, porting the DRM framework and most recently working on Thread Local Storage for the nvidia guys to use. As to what I think the next core team should be doing, I think its doing just fine as it is. The nature of the role is that it re-defines itself organically as circumstances change so as the future reveals itself, I expect the core team to change itself as necessary. Strong support for the TRB (or whatever that evolves into) and setting clear directions for FreeBSD 6.0 seem like worthy goals for a core.4 to tackle. ---------------------------------------------------------------------- Gordon Tetlow Last modified: Jun 18 00:29:51 2004 I have been a developer on the FreeBSD project for about 2 years now. I came on just in time for the last election. While I haven't written much code, I have managed the import of rcNG, the migration to a dynamic root partition, and written geom_vol_ffs. I was the principle organizer of the San Antonio 2003 Dev Summit. I believe I would make a good core team member because I have a level head and I generally am able to look at both sides of an issue to make a fair assessment. I have worked with developers in the past (usually behind the scenes) to help smooth over issues by making them see the other side of the coin. I have tried to interject myself before it became a public issue. While I have a busy work life, my boss supports my effort in running for the core team (if that helps sway anyone =). At the last election, candidates put people they thought they would be able to work well with inside of core. Of those currently running, I have worked with Warner, John, Peter, Scott, Robert, Wes, and David on various projects in the past with good results. Nothing against the other folks running, I just haven't had the opportunity to work with them. Q&A: Q: What about this TRB thing? A: Dispute resolution should be handled by one group: Core. Whether it is technical in nature or merely a conflict in personality, one group should be able to sit down and handle the dispute. If it is beyond the capabilities of core to resolve a technical dispute due to lack of familiarity with the code, that's where the TRB comes in. The TRB isn't about resolving disputes (we have core to do that), the TRB's job becomes helping core see the merits of both sides so core can make an informed decision. To that end, core should appoint individuals that are experts in their particular area of the tree. Q: What about the vision for FreeBSD? A: FreeBSD is not for everyone. My mother will never use FreeBSD and that doesn't bother me. I think FreeBSD should be geared toward areas that it has typically served. FreeBSD is infrastructure. All the places that I have been able to convince people that FreeBSD is most appropriate are in infrastructure roles. Companies like Y! or Pair that use FreeBSD as a platform to do business. Companies that St. Bernard that use it as a base for embedded applications. These are the roles that FreeBSD excels at, and I think we should focus on it the way we always have: stability, correctness, and openness (in both source and understandability). Q: What about funding FreeBSD developers? Is that something core should try to get a hand in? A: I don't think anyone would dispute that direct and indirect funding is good for the project in the long run. The problem is how to manage the funds. A lot of the problem stems from the FreeBSD Project not being a legal entity. It's much easier (administratively) to run the project without the need to have a legal framework setup around it. Having said all this, I think we do need some organization to stand up and take funds. Fortunately, we already have the FreeBSD Foundation. It is even setup as a non-profit for tax-free donations. The problem with the Foundation mostly stems from the lack of time that they are able to put into fund-raising and other activities. Summary: I think core should stay away from funding. Let other organizations step up and run with that ball. Core might want to stand up and say "The FF needs some voluteers for X purpose, anyone interested?" ---------------------------------------------------------------------- Brian Feldman Last modified: Jun 9 04:06:03 2004 In recent years, FreeBSD has grown immensely to a proportion that cannot easily be handled without increased infrastructure. Much of this infrastructure has come in the form of the perforce server, donations@, bento, FreshPorts, TinderBox builds, and all of the thankless bits and pieces behinds the seen that various contributors, committers, and core members have made possible. This is a Very Good Thing! The increased growth is also accompanied by increased stagnation. There are fewer resources visibly being dedicated to cleaning up or removing old (and sometimes quite broken) interface, implementations, and subsystems. Because there are so few known users of these, brokenness goes unnoticed unless either the build breaks or the users manage to just happen to find the last few persons@FreeBSD.org who has any knowledge of ${insert old feature here} and get their attention. The mailing lists and GNATS database are currently the primary ways for problems to be made known. Separating signal from noise (whether genuine noise or just those things you are not interested in), as any kind of FreeBSD contributor, is daunting. I feel that as a member of Core, it is most important to identify these things that stand in the way of connecting users with problems to contributors with desire and knowledge to fix them. To this end, (wait for it...) the first important thing that can be done, I feel, is that a team would be set up to enact a strawman BugZilla database that would replace our rapidly aging GNATS set-up and allow the developers and users to try out a system whereby maintainers/watchers of parts of FreeBSD can be automatically assigned/notified of bugs, users can vote to show support of how critical it is to fix them soon (before new users desert FreeBSD for more rapidly-changing operating systems), problems can be verified (or not) so developers do not waste their time on setup issue, tasks that must be done before certain times/releases can be associated with them... basically, a complete overhaul of the glue between FreeBSD and FreeBSD users. While I feel that this is the most important thing to try out, I think other things need to change. Duplicate features need to result in removal of whatever the inferior is, and Core needs to take charge and show that there isn't support for keeping around the broken and obsolete or for adding subsystems with short-sighted implementations. There is a lot of work still to do before FreeBSD 5.x-STABLE, much less bringing FreeBSD truly up to speed with developments in other operating systems in some areas requiring sweeping source tree changes, but I think that Core is absolutely critical in providing whatever it is that as the next step in communications infrastructure that will allow all of this work to happen without FreeBSD collapsing under its weight. Updated, regarding the TRB: I feel that the composition of the TRB should reflect more the whims of the committers, directly, than the Core team alone. The single aspect of the United States's government that I despise the most is that despite infrastructure that could support much more fine-grained legislature than the House and Senate provide, the individual's voice in the end is not what matters. I feel that there can be a happy medium where TRB can act as a fact-finding group that acts quickly and then provides every FreeBSD developer a final vote -- when it is appropriate to do so. Small technical disputes can easily turn into a flame war when too many individuals try to get their voices into the fray, but a simple blind voting system (like the Core Elections) should allow the final say for disputes to be handled with a little more fairness than a simple appointed group allows, but not prolong the process unduly. Still, I am happy to see the TRB appearing to do what it's supposed to: separate Core duties so those who are best at moving the project forward as a whole do not have to be the best at moving the project forward technically. As FreeBSD grows, there are less individuals who can give expert guidance in all areas of the system. No matter the make-up of Core, TRB should always be able to reflect expertise wherever review is needed. Updated, regarding a "vision": I don't feel that FreeBSD has a unified vision -- and I don't think that this is a problem. Most operating systems don't have a unified vision that I personally perceive, and NetBSD and OpenBSD having the "visions" that they do distance themselves from the pack in this regard. Various individuals in FreeBSD do, however, have their own strong visions! Among these are standards compliance, scalability, hardware compliance (with the newest stuff on the market supported here before anywhere else, often times), security (MAC being the most complete open source security framework around), network protocol support, unified external software management.... How could we choose just one? Thanks for your time and consideration of my views. I hope that the FreeBSD project and its leadership continue to work to provide the best all-around, affordable-hardware operating system for many years to come. ---------------------------------------------------------------------- Hiten Pandya Last modified: Jun 9 23:38:02 2004 Dear developers, I am Hiten Pandya and I am actively involved with FreeBSD and numerous other related projects. My interest in engaging with FreeBSD originally sparked off when I met Jordan Hubbard at EuroBSDCon 2001. I have done a lot of documentation work, kernel hacking, writing custom BSD based applications for various clients, freelance. In the last few years (well, since 2001), I have had the privilege to work with some of the most brilliant people in the Open Source community at camp FreeBSD; when you work with a lot of different people from all over the globe, the word `perspective' gets a whole new meaning. As to why I want to join the Core Team, no political agenda, just that I have a considerable amount of free time and over the past four years, I have experienced and learnt a lot about community structure, what makes people tick, how to calm inter-personal disputes and how to be a good listener and make conscious decisions. I know my resourceful and active nature will prove highly useful to the Core Team. Thank you for your time. -- oo --- oo -- Below are the answers to Bosko Milekic's questions to potential CORE candidates. I have discussed these with Bosko and he has agreed upon me releasing this to the public. Date: Mon, 7 Jun 2004 05:29:17 -0400 (EDT) From: Hiten Pandya To: Bosko Milekic Subject: Re: Question to potential CORE Candidates I would like TRB to be committer-elected; there are a few reasons for this: * The number of appointees on Core is not diverse enough to select a TRB. * The committers know better (based on inter-personal communcation, and working with some of these developers) For example, a developer's ability to resolve an inter- personal problem might not be as good as his kernel skills; that would make him a less-than-optimimum TRB member; there are less chances of such developers being chosen to represent the TRB with a community-elected TRB. We need a TRB that can resolve inter-personal problems, and to give a truly unbiased opinion. A TRB member's decision should be supported by atleast another two other TRB members and/or a person who has significant knowledge of a particular piece of work. Secondly, our TRB needs to be diverse enough to understand what is going on. A Core Team elected TRB will not provide the required amount of diversity. We also need people on TRB that can envision how current changes will affect things that will be done in the future. Another thing I would like to reduce if I get elected to the Core Team is the amount of favourism and elitism; and often use my Core hat to stop bikesheds when it is still smoke and before it turns into a fire; far too often I have seen old Core Teams not stepping in to stop bikesheds until the last minute; Core should know exactly when to step in, and not wait till the last minute... People in any kind of a management board (be it TRB or Core) need to be confident and resourceful, i.e, they should not hesitate to communicate their thoughts with people who are more educated on a particular subject *outside* of the FreeBSD community if need be. We should also strengthen our ties with other BSD communities like DragonFly, NetBSD and OpenBSD. -- oo --- oo -- ---------------------------------------------------------------------- Warner Losh Last modified: Jun 9 17:08:16 2004 I've served in core for several years now. In that time, I've spear headed many efforts to improve the operation of the core team and the project. I've spent a lot of time making PC Card and CardBus functional in the system, as well as attacking underlying infrastructure issues that get in the way of device driver development. I've taken on many unfun tasks to improve the project. I work daily with FreeBSD, both for my personal enjoyment and as part of my current employment. core.3 was able to get the dispute process under control. After some initial extreme swings, there seems to be a good balance now. Core.3 has managed to setup an atmosphere where many disputes are mediated before they blossom into full fledged problems. I've taken a lead at mediating the technical disputes that have arisen in the project. Many disputes have not had to go to core due to the activism of some of its members. Much remains to be done. With FreeBSD 6 development starting soon, core.4 will need to resolve the lingering questions about the TRB. While the TRB has worked well when it has been asked to arbitrate a dispute, it is seen as not functioning otherwise. Part of the problem is that when members of the TRB participate in discussions, credit isn't given to the TRB doing its job. Part of the problem is that by its very nature, it is hard for a large group of people to discuss and post in real time. That's why it has worked well for disputes, but less well for other things. Members of core.4 will need to take a leading roll in defining what FreeBSD 6 will be. I like the idea of writing up a plan for big projects that developers wish to do. Core would them review and approve them, giving a certain amount of protection from bikesheds that happen down the road. Folks working on those projects report to a core liaison as often as necessary in the most appropriate form. Smaller projects a simple 'I'm still alive' on IRC might be enough from time to time, while for larger ones a more comprehensive report on what was accomplished so far as well as how the implementation experience has reshaped the original design. The core liaison would help ensure that the project's interfaces to other projects within FreeBSD were well coordinated as well as reporting to core (and indirectly the monthly core report). It is clear from the questions submitted to the candidates that there's a number of issues facing FreeBSD today. I'd like to encourage the FreeBSD committers to choose candidates that have the time and energy to work on FreeBSD core issues at least 10 hours a month on the average. With a core team that has time, the details will attend to themselves. With a core team that doesn't have the time, anybody's detailed ideas won't come to fruition and will be irrelevant. ---------------------------------------------------------------------- John Baldwin Last modified: Jun 2 14:33:00 2004 I've been an active FreeBSD developer for several years. I started out working on the documentation tree and subsequently wandered over into the boot code and kernel source. I am currently very privileged to be employed nearly full-time to work on FreeBSD under my own direction. Being a firm believer that privilege comes with a corresponding amount of responsibility, I choose to spend some of my funded time doing administrative work so that other developers can spend their volunteer time doing more of the fun work. To that end, I have worked on release engineering in one form or other since 4.2-RELEASE. I am also completing my first term as a core member. I intend on continuing to work on both tasks if permitted. As far as what core.4 should be working on, there are a few things that core.3 has not completed including reorganiznig core itself into pseudo-subcommittees as well as seriosuly looking at some different development models to see if there are changes that need to be made to our current one to better scale with the ever-increasing number of developers. I will also give some warnings about how the core team works and setting realistic expectations for future teams. 1) Committers are by and large a self-selected group of engineering type geeks. It also seems that having the desire and ability to do the work we do seems to bring along some very "interesting" personalities as well (Hey, if we're all stud coders then our faults have to be elsewhere, right?). The least pleasant tasks of core are to try to settle disputes that don't really have much of a technical basis but are more matters of personal style. There are no cookbook recipes for dealing with people like there are for computers. Thankfully, the occurrence of such disputes has been decreasing as of late, but it is always there. 2) Core moves slower than a glacier. If you want to come in and make a bunch of changes, prepare to be disappointed. :) It is also subject to the other half of the bikeshed analogy. That is, if you spout off an e-mail proposing some big change, expect little to no response back. This just seems to come with the turf. Partly, almost all core team members are volunteers with limited time. Even those of us who are funded have families we like to see on the weekends. Thus, when a "big" proposal comes across the table, it's easy to write it off because taking time to come up with any sort of reasoned response is just going to take up more time than his available right now. Also, the Project has a good bit of inertia what with ten years of history now. Finally, for better or for worse, the people elected to core tend to be non-confrontational and thus squeamish about pushing through big changes. Part of this could be due to the fact that committers elect "safe" core team members who they feel aren't going to shake up the world. :) Sheesh, that's probably enough rambling for now. ---------------------------------------------------------------------- Juli Mallett Last modified: Jun 23 05:46:59 2004 I've been a FreeBSD developer for about two years now, and I've tried to at least keep aware of goings-on, even when I've been too busy to participate in the cycle of code. More and more I see we need people who are willing to think outside of the box and on the fly helping steer the internals of the project. We're becoming much more complex than we once were, and the issues are less obvious than the personality and political issues we see. Like making it more visible for people to fund FreeBSD work, etc. We've clearly got to figure out a lot of what being part of the developer community means, in the new world order. I really want to stand up as part of the much-younger (not to be confused with the just-plain younger crowd, which seems to mostly be defined by not having large gray beards) crowd and bring some more abstract thought to the table. I have no real strong opinions on how people should participate in the project, outside of being civil. I find one of the best things about any collaborative project is that you get to work with and know cool people, and do good work. I'm interested in seeing that nurtured in FreeBSD, cause it can be a great thing, and a lot of the people in it are amazing in unique ways. So basically I want to run for interpersonal reasons, and to nurture the project as a whole, not any one technical facet or team or goal. I'm planning to be available at all hours and help out in any way I can in the day to day aspects of core, as well as the broader vision of things. I'd also like to try to organize more FreeBSD-related events. I really find that meeting other developers, even if you never get along with them, is a fun and exciting part of our little community. I don't feel that the project lives or dies based on whether I get elected, but I'm offering up myself and my time to serve the project, and if you want me, you can have me. I don't really feel comfortable trying to play the political side of the election. Of course it's political, and I'll gladly stand up for anything I believe in that someone wants me to believe in, and if I don't have a side picked, I'm more than willing to stand by and observe objectively until it's clear to me what's right, or I can at least make a recommendation in my personal opinion. I feel comfortable representing FreeBSD, and really I feel comfortable with everyone running for Core representing FreeBSD in their own way, and I'm sorely grumpy that I can't vote for 13 people. That said, I've voted, but because I think everyone you're considering is pretty much great, I'm not going to bother telling you who I voted for after all, if you want to know, or if you want to ask me a specific FreeBSD question or even a general or personal one, I encourage you to find me on IRC or send me an email. Good luck to everyone, and long live FreeBSD! May our leaders be as reliable and representative of FreeBSD as our filesystems. :) ---------------------------------------------------------------------- Josef El-Rayes Last modified: Jun 10 08:41:59 2004 Hello friends, for those who do not know me yet, I am a 22 years old student of computer science, living in Austria. I am part of the FreeBSD developer team since January, and besides my work for the doc/ and www/ tree, I focus my work on advocacy. I write articles about the Project for magazines, help out/organize booths at conferences, produce FreeBSD articles like posters and CD sets and give talks. My highest priority task, as an active part of the core team, would be to improve the way the project interacts with the public. I think the project should try to make more noise when a new version gets released. I also think we should try to get better contacts to the press, encourage journalists to write about how much they like FreeBSD. Additionally we should make changes more public, announce new features etc. I have contacts to german magazines and it will be easy to make new contacts to international magazines. I believe advocacy is really something FreeBSD needs to push. In short: FreeBSD is a superior operating system, and we really should tell people. Another point what I think is very important, is to have a well balanced Core Team - well balanced in terms of age and localization. I think it is good to have young guys with fresh ideas motivated as well as experienced seniors. I also think it is good to have members of Core Team not only in USA, but also in Europe, Asia and other parts of the world, to be able to deal with local issues. Although i think all of the listed candidates will be excellent members for the new Core Team and I deeply respect all of them, I would like to underline my opinion that the Project would benefit from a certain amount of 'fresh blood' in the core-team. I think a good balance of 'experience' and 'new ideas' would be beneficial. So i would propose that perhaps two or three of Hiten, Brian, Juli, Simon, Maxime, Kirill, Colin and me, get the chance to give the project's lead new impulses. Of course, I will be happy to work with everyone of the candidates and every other one that needs my help or support. Questions not previously covered in statement: 1.) > What do you think about TRB? In my opinion there is no need for a Technical Review Board as a separate body to decide on technical issues. I think that the Release Engineers and the Core Team are able to serve what we would expect a TRB to do. While the Core Team defines the way to go with a long-term view, the Release Engineers actually decide what goes into next Release. Conflict resolution is also something that Core Team should handle. I think we should work with common sense not with laws. I also prefer open discussions of issues. If developer A and developer B are not able to resolve an issue, there should be a proper discussion and if there is no solution then the Release Engineers should try to handle it. I think Core Team should be last instance of decision. 2.) > Future vision of FreeBSD? I think we already have a proper vision for which FreeBSD is well-known: Stable, high performance OS for popular architectures. 3.) > Where are the FreeBSD articles in the trade-rags? I think it is necessary to improve the communication between developers <-> press. I never saw any sign of press indicating willingness to publish FreeBSD related articles spread to the developers. I am willing, as stated above, to work on this: To support the press/media in finding people who are interested in writing articles for them. I regularly write FreeBSD-related articles for a german magazine myself, I earn money, I support FreeBSD and the magazine is happy to get stuff they can publish. This works very well and I am sure that this will work for others too. It just needs some initial push. 4.) > Unexploited funding opportunities: In my opinion every developer should decide himself how he affords his involvement in the project. I do not think that a project driven funding project is a good thing. I am sure that this will sooner or later result in big disputes - this always happens when money is involved. Every developer decides on his own how much time he wants to invest in the project, so why not let every developer decide on how to finance his time? I wanted to work for FreeBSD in my summer holidays, i looked for an enterprise that sponsors my effort. It is as easy as that. And i am absolutely sure that no other developer will be angry at me for this. 5.) > I believe core is overworked, IMHO due to core attempting to serving too many roles [...] I do not think that the work the core team is responsible for, is too much per se, i would rather blame their daily life that makes it hard to find enough time for handling all the work in shorter time. People should only apply for core team if they are really able to work for the project as the project needs it. > - src committer approval This happens perhaps once a month and is imho a rather simple decision. > - architectural direction I think that Release Engineering team is well capable of taking some of the work-load from here, as stated above. 6.) > Core needs to communicate better [to outside world] I think it would be a good idea that the core team publishes, as a part of scott's bimonthly report, some of their decisions/guidelines on overal FreeBSD development direction. A higher frequency of press releases would also be beneficial. 7.) > Core needs to establish disciplinary guidelines The content of committer's guide says it all, it is more a matter of enforcment. If a committer does a questional commit and there is some backup request he ignores, core _has_ to step in and do some action. If committer start acting as they like we do not need coreteam and can make the whole cvs tree world writable. Every one has to understand that FreeBSD only works when people work together. The project comes first, not the individual developer. It is also important that a developer sees a backout request not as a personal affront. I am happily looking forward to work with the other candidates on two successful years of FreeBSD. Have a nice day, Josef ---------------------------------------------------------------------- Kirill Ponomarew Last modified: Jun 4 12:54:44 2004 I've been ports and doc committer for about one year. It has been a great pleasure for me to work on our ports' PRs, which I have been doing pretty actively. The improvements to our ports tree would be impossible without continuing efforts of our many ports committers, whom I would like to thank here. We simply do our job and try to do it well, although it's not as easy as it sometimes seems. You might ask, why I am running for core, and how do I think I can help if I elected. I would like there to be a better coordination between our various `brands' of committers, as well as inside our existing teams, like cvs@, trb@ for example. We all are striving for the same goal, and concerted efforts can only help to improve the FreeBSD project. I have enough time to try and help with that. When 6-CURRENT appears, there inevitably will be a number of debates, conflicts, and even quarrels between developers. It will be a task for core.4 to resolve many issues, at least non-technical ones. Thank you for your attention. ---------------------------------------------------------------------- Jun Kuriyama Last modified: Jun 7 03:23:23 2004 In last two years, I hope I did my best as one of core@. In that period, I found I have a lot of things I can do within/without core@. So I don't care whether I re-elected or not. I'll going to work for FreeBSD where I can serve for. In core.3, I tried to be fair, comment along with common sense, keep my activity not to discourage Wilko. :-) All I can say at this stage is not so much, just I'll do as I did. As I'm originally ports committer, I hope I can keep a good relationship with ports team and portmgr@. And I'm still managing some area of Japanese translation team, so I'll take care of www/doc area, too (I have a plan to refresh doceng@ member for more activity). I'll also be a speaker for Asian community. Anyway, being core@ is not so important. Please vote me only if you think I should work on core@ and it will make things better. ---------------------------------------------------------------------- Marcel Moolenaar Last modified: Jun 9 03:22:18 2004 I got my commit privileges in Juli 1999 because of my work on the Linux emulation support. This pretty much grew out of hand and I found myself fixing and improving various parts of the source tree as well as working on the various ports to support Linux emulation. After what can best be described as a short break from FreeBSD due real-life events, such as relocation to the San Francisco Bay Area, I was able to apply my IA-64 knowledge and exposure to FreeBSD. It started off slowly and carefully, but again grew pretty much out of hand. Again I find myself working on the most varied problems, and they are not all ia64 specific. Yet, it's ultimately for the good of ia64. I really can't say exactly why I decided to run for core. It just feels like something I should be doing because I believe I'll make a good candidate. There's really nothing else to it. I don't have an agenda other than the one I already have as a developer and I also don't feel I suddenly need to become very outspoken in every aspect of FreeBSD. The project belongs to the developers and the users and I see core merely as a means to make things happen, not as a means to unilaterally control it. Below answers to questions I (and presumably others) have received: Q: Do you think the TRB should exist? A: No, I don't think the TRB should exist. It just creates elitism. Discussions should be held on the mailing list and if we have a technical debate that doesn't seem to reach concensus, I'm more in favor of 1) simple votes, 2) compare actual implementations (the department of "show me yours and I'll show you mine" :-), or 3) create a taskforce for this particular instance. The problem with a TRB, in whatever form, is that it's based on a predetermined group of people. As such, we a priori select people to resolve problems without knowing what those problems will be. I have no doubt that given enough time those people can and will resolve an issue, but I very much doubt that we can give them that time (as a community). I think it's more attractive to select the people we need for the job at hand. Q: [FreeBSD] ... still need a vision. What is our vision? A: We don't have a vision. At least, that's how I experience it. We seem to have gotten into a mode where every developer just does what he or she feels like doing, but the collective is without direction, without drive. Q: What should be the underlying shaper of all the work that we do? A: I think that excellence or quality is probably the best aspect to get the developers to shape up. Of course we need more. I pretty much have a vision for ia64, which boils down to supporting the high-end enterprise servers (32 or 64-way NUMA machines) and doing it in a way that benefits research. For i386 and amd64 I hope to see a more desktop oriented focus. Of course both focusses should be beneficial for all platforms. Of the other platforms, sparc64 and powerpc seem to have the brightest future, although I'm not clear exactly in what shape or form at this time. Q: Will you continue to be as technically active as you are now? A: If I can help it, yes. I may not know exactly why I decided to run for core, but I know for sure that it's not because of a desire to change how I contribute. Unfortunately I don't have it entirely under control. History tells us that developers can at times look towards core to resolve issues that aren't really for core to resolve or which core cannot resolve without full support from the developers themselves. In such situations the amount of time and effort that a core member needs to devote to core duties may make it practically or emotionally impossible to also contribute on the technical front. I personally think that core is mostly there in support of what developers like to do, not to do the things developers like to see, but I don't know how core will need to operate in practice... The following questions have been rephrased to make them suitable for public display (as requested by the submitter): Q: What do you think about the concept of having src-mgr? A: We already have doc-mgr and ports-mgr, and given my visibility, they appear to function adequately. Having a src-mgr to handle the same kind of tasks makes sense. The role of src-mgr in the context of disputes could be one that overlaps with what others like a TRB for. Although I would be wary of having src-mgr *be* a TRB. I expect that a src-mgr would mediate in conflicts. However, there are some gotchas. Moving tasks from core to src-mgr means that core will have to shift focus. Let's for arguments sake assume that core will get an outward looking focus and that the internal chores of the project are dealt with by the *-mgr teams. Would the core you vote today be the core you'd vote then? How do *-mgr coordinate? Do we need core as the glue between them? Would core have enough focus left for the outside world? Would core take over from donations@? Will core beef up advocacy? As you can see, more questions. So, we really need to understand the project first. What do we perceive. What do others perceive. What are our strengths and weaknesses. What are our goals and how do we currently pursue them. If we have a clear picture of what goes on in this project, we have a better chance to put an orgchart on top of it. Heck, we may even find that core should go in its current form and simply have it be a group of delegates of other groups with the sole purpose of making an unity. Whatever is the answer: we should look at what goes on and adjust to the trends we see. We should not become bureaucratic or create powerseats. It has been shown that people like to work on FreeBSD because they feel they can make a difference, that they can change its shape and form. We should not take that away from them without fully understanding what we're getting into if we did. Q: Do we have enough people who understand the whole kernel and if not, is this a problem? A: The kernel is getting larger and more complex. As such the number of people who understand it in all its beauty (and beastiness) has already dropped to 0. Nobody understands everything under src/sys. And this is ok. That is, we cannot expect that people understand each and every aspect of what makes up FreeBSD. Trying to achieve that is a lost battle. However, we do need to make sure that knowledge and understanding is not as volatile as the people who have it. There are various ways to achieve that, but unfortunately they all depend on somebody doing something. And frankly, we're not exactly cooperative and forthcoming when it comes to action. We seem to like to talk about how things should be done, without actually doing it. We all have good intentions, but if push comes to shove, we're all too busy. To tell the truth, I don't have the answers. Maybe the wisdom is in letting it grow worse, so that people will see for themselves that we need to do something about it... Hmmm, was that a rant? Yes, it was! I guess I have an agenda after all. Funny... :-) Back to the question. The problem is therefore not that people don't understand the whole, the problem is that we need to make sure that it's easy enough for people to obtain the knowledge when they need to. This requires discipline and it sure is not something that core can fix on its own. Q: Should core take on some of the responsibilities of the Foundation or otherwise meddle in its business? A: A dangerous question to answer during an election period. So, let me cop out by saying that I haven't given it any thought and I also don't have the visibility in how the Foundation works. However, core is elected by the developers and will be held accountable by the same developers, whereas the Foundation has no formal ties with the project. Accountability is towards the donators only. Power is also differently obtained. Core is given power by the developers, whereas the Foundation has power through monetary leverage. This is not exactly the recipe for guaranteed conflict free cooperation so to speak and it is important that the Foundation and the project are on the same page with respect to what is important for the project. Q: What can core do for FreeBSD to grow mind-share? A: Another tricky question. In this case the question implicitly caries with it the assumption that it is core that has to find the answers. I don't think that's realistic. We, as a project, can benefit from cores involvement in whatever shape or form we, as a project, think core can be the most effective. Q: How do we get qualified developers to work on improving our release "product"? A: This question pretty much falls in the same category as the previous question, although this better overlaps with what we expect from core. The bottomline is that we need to know, as a project, what is important to us and based on that work out an action plan. With that core will likely play a pivoting role. Vote conciously. ---------------------------------------------------------------------- Mark Murray Last modified: Jun 4 19:02:33 2004 I've been a (Free)BSD'er since the DrDobb's journal articles by William Jolitz came out. In the early patchkit days, I created a crypt(3) patch for the international folks. For a long time I maintained the internat.freebsd.org International Crypto Repository while the US crypto laws made this impractical in the USA. For a long time I did primarily security/crypto work for FreeBSD, but as I now do this professionally, I'm doing other more utilitarian stuff. The Random Number Generator (/dev/random) is my baby. I've done a pile of lint/WARNS fixes, and I dream about the day that I can significantly lower the kernel lint-warnings count. I do FreeBSD because its fun. I think that it is VERY cool to work on a project that is as high-quality as this one, with talent as good as we have, and I intend to stay with the project for as long as I continue to have fun. Of late, the project has been running pretty darn smoothly, and a couple of folks have commented on this. The Chill Pill is a good tool, and taking breaks to work on problem has done general sanity wonders. If re-elected, I would like to work at getting an architectural/design ethic further built into the project. This means all-or-some of a design group (I'm avoiding using the "TRB" term on purpose!), encouraging folks to publish large designs before implementing them, and trying to keep the project more up-to-date with respect to current documentation. The documents team are doing an excellent job, but they need info in the first place if they are to do their jobs. The basics are already there; it needs to be encouraged more and built on. In general, I am a bit "anti-rules". I don't like rulebooks all that much, I don't like mechanistic application of rules, and I HATE disputes that consist of folks throwing rulebook extracts at each other. For the most part, our mentoring process has been doing an excellent job of teaching folks the right way to do things, but I still intend to target some of the less useful rules. Don't get me wrong; I am not an anarchist. I just believe that developers should use their social graces to solve problems rather than getting stuck over rigid over-interpretation of words in a file. I urge committers to vote for a team. Pick folks that will get on and work together, and go for some variety. Core needs designers, mediators, gurus, grunts, organizers and more. ---------------------------------------------------------------------- Murray Stokely Last modified: Jun 4 05:07:29 2004 The election timing has caught me a little off guard as I am just now returning to the San Francisco area after 4 months in Europe. I've had the pleasure of meeting many FreeBSD committers over the past 5 years, so I think that many of you know who I am. I'll try to keep this as short as possible, with an abbreviated list of my accomplishments in core.3, and then some thoughts about future administration of the FreeBSD Project. I. Background / Core.3 Accomplishments Summary : During the past 2 years I have primarily divided my time between advocacy, corporate relations, release engineering, and documentation issues. Over the next 2 years I will again devote my time to these activities. Details : I gave FreeBSD presentations at universities or conferences in Sweden, Japan, Russia, and the U.S. I met with FreeBSD user groups in the above countries plus, China (PRC & Taiwan) and Ukraine. These visits almost always culminated in various emails sent to core@, portmgr@, or mirror-admin@ about various administrative issues that the local FreeBSD communities needed help with. As for corporate relations, according to the core.3 agenda file, I placed over 20 phone calls or emails to Wind River Systems relating to the FreeBSD Trademark. After a registered letter and a few phone calls to the Chairman, I finally got a trademark assignment document out of WRS and I sent this along to the FreeBSD Foundation. In cooperation with another ex-BSDi employee, Matt Olander, I was able to make some significant advocacy progress with a number of FreeBSD segments on the 'ScreenSavers' segment on TechTV. Matt and I did the first two segments ourselves, talking about the advantages of FreeBSD, and then performing a live install head-to-head with Linux. When TechTV called us up requesting that I talk about clustering, I put Brooks Davis (brooks@) in touch with them and he did an excellent job in our third and final FreeBSD segment on TechTV. Matt and I also collaborated on the 10 year anniversary party for the FreeBSD Project in San Francisco. We rented the DNA Lounge (nightclub) for the event, and convinced Yahoo!, Apple, and many other corporations to sponsor t-shirts, awards, and food for the event. As far as release engineering, I was the primary release engineer for FreeBSD 4.4, 4.5, 4.6, 4.6.2, 4.7, 4.8, and 4.9. My involvement with FreeBSD 5.0 peaked before DP1 and then rapidly subsided as Scott Long became more involved (and started doing an excellent job). During the first half of my core.3 term I created a release engineering area of the website (www.freebsd.org/releng), wrote a charter and had core@ ratify it, and spread out the responsibilities to transform the hat of "release engineer" from a post for a single person (jkh@) into a team. In addition to the visible release engineering work that takes place in the CVS tree and on the mailing lists, I am also involved in a lot of the behind the scenes work to create CDROM and DVD products for FreeBSD Mall, Inc. For documentation issues, I spent most of my time working on the FreeBSD Handbook. As with the second edition, we maintained a separate Perforce branch for our work on the third edition. This branch includes a number of changes to increase the aesthetics of the print output. At the beginning of my core.3 term, I spent a lot of time merging back our changes into the main repository (where appropriate), and mentoring several new documentation committers. I have not been as active in doc/ recently as the final stages of the 3rd edition publication process took place outside of CVS. However, this summer I expect to again spend a large amount of my time working directly on the Handbook in CVS. During the early part of core.3 I took the lead in forming the doceng@ group based on Nik's emails to core@ about divvying up his responsibilities as doc-steward. As with re@, I helped formulate the different ideas that we had about the scope of this new group, posted the charter as a web page, and had core@ ratify it. In addition to my work on the FreeBSD Handbook, I also wrote a few articles for FreeBSD Press, a dedicated FreeBSD print magazine in Japan. I also submitted letters/articles to the Economist and other more mainstream publications about FreeBSD, BSD/Linux, and licensing issues, but as of yet none have been published. One of my letters to the editor of Login was published last year to clarify the security features of FreeBSD vis-a-vis OpenBSD. I am currently serving as the session chair for the UseBSD SIG at the Usenix 2004 Annual Technical Conference in Boston. I was involved in organizational issues for both FreeBSDCon '99 and BSDCon in Monterey. I would like to continue working with Usenix and other potential conference organizers to ensure we have the opportunity to meet face to face at BSD technical conferences. II. Future Goals On the subject of general organization, my thoughts have evolved quite a bit through my term on core.3. Last time around, we were rapidly moving in the direction of more committees. This worked well for release engineering and security, so I thought we could replicate that model elsewhere. It took me a while to realize how very different these individual teams can be. doceng@ is nothing like portmgr@, which is again nothing like re@. Treating all of these committees as identical, or imposing the same organizational structures on all of them is a big mistake. Some tasks are just not suitable for this kind of organization at all. One persistent problem we had in core.3 was the need for an architecture review board to resolve technical disputes. The temptation was to create a new committee to handle such disputes. I still think that a TRB is necessary, but I no longer believe that it is as important as having a coherent MAINTAINER policy to obviate such disputes in the first place. I was very happy with the results of PHK's recent funding drive. As part of FreeBSD Mall, Inc., I have made sure that corporate profits are continually reinvested in the FreeBSD Project. We have done this both by hiring our own FreeBSD staff, paying modest cash awards to developers for various FreeBSD projects, and by running funding drives and donating thousands of dollars to the FreeBSD Fondation. The Project needs to do a much better job at reaching out to corporations to support FreeBSD Development. Matt Olander proved that just in the San Francisco Bay Area we can raise $10,000+ easily (in just a few weeks time) for FreeBSD. Poul-Henning went a step further in showing how many companies are out there and willing to donate. The FreeBSD Foundation is a good vehicle for fund raising but we should not be complacent in thinking that only those people need to worry about this. We still need more funded developer time to make 5.X successful. Thank you for your consideration. ---------------------------------------------------------------------- Maxime Henrion Last modified: Jun 4 23:52:18 2004 I've been a FreeBSD developer for more than two years now. During that time, I mainly focused on kernel coding, happily hacking various parts of it, as you might know. The FreeBSD project is evolving significantly these days, and I find it is very exciting to contribute to it. We are seeing more and more people joining us and billions of new features on the technical side. Needless to say, the way the project is managed had to evolve too, and I believe core.3 has made a very good work of it. But this is not finished (I should say, hopefully!); there are issues that need to be taken care of, and more will come with time, that we will need to address as well so that the project can grow smoothly. FreeBSD is a moving target, and that's one of the things that makes it great. I believe the next Core Team will have to focus on the following items (this is not intended to be an exhaustive list) : - We need to continue to delegate some tasks to teams when it makes sense. This has already proved to be very beneficial with the so@, re@, donations@, portmgr@, docmgr@, etc teams. It relieves core@ from some of its burden, because those teams are specialized, they are very responsive. - More particularly, we need to clarify the status of the TRB and make it a reality. For now, this very important committee is not well defined and lacks visibility. - When the re@ team will have decided it's time to switch to 5-STABLE, we will need to manage the creation of the 6-CURRENT branch, and to define and manage our new priorities for this branch. - Disputes between committers have greatly decreased recently, and we need to keep going that way. The Core Team needs to act as a mediator when there are no other solutions. The TRB should handle technical disputes. I am well aware that being a core member implies sacrifices, donating time to the project. That's actually what I want to do. After having so much fun being a member of the FreeBSD project, I now want to give as well (no, code doesn't count, it's part of the fun!). I want to help fix all the above-mentioned issues. I want a reactive core team, that is able to take advantage of every opportunity we are offered. And last but not least, I want to ensure that coding for FreeBSD remains an enjoyable experience. I believe I should have absolutely no problems working with Robert, Peter, John, Mark, Scott and Warner. I have been in contact with them via IRC since quite some time now, and I know we have similar views with respect to the FreeBSD project. Thanks for your attention. ---------------------------------------------------------------------- David E. O'Brien Last modified: Jun 7 20:18:33 2004 I've been a FreeBSD committer since 1996. At one time I had the highest port maintenance count of over 130 ports -- thought that record since been surpassed. :-) I've maintained parts of the toolchain for over 5 years. Other activities include much work in src/contrib and general code cleanups. I've been part of the release engineering since 4.1. I also wrote part of the FreeBSD Handbook & Porter's Handbook. My commit stats are: src/sys: 1035 (#13) src (-sys): 4277 (#2) ports: 3073 (#8) www+docs: 166 (#31) I am very involved in our multi-platform efforts. I purchased one of every of our platforms with my own money as I believe in this dream and have put much release engineering effort, keeping non-i386 platforms in sync with i386. After 9 years, I still do all I can for the project, including advocacy and thru my efforts contacting and pushing hardware vendors much equipment has been donated to the FreeBSD project. I think one of the most important things for a Core member to do is be very active with in The FreeBSD Project before being elected, and once elected to make Core activities a high-priority among all things in their life. (This also goes for all the other "hats" in the project.) A Core member should not wear too many FreeBSD "hats" or they cannot fully serve their responsibilities well. I also think Core members cannot shun their responsibility to the project and to manage it. The past Core(.3) team has done some very good things as a whole and are leaving a great basis for building on; though mostly due to the hard work of a few members. However one short falling I feel is the in the area of technical review and steering. I saw a huge need for a TRB (Technical Review Board) and advocated its creation in the developers@ email list, and saw its creation be part of some of the current Core(.3) team's running statements. However, its implementation has failed to server its purpose. I knew the existing TRB would not serve The FreeBSD Project from its first day of creation the way it was implimented. I would like to be part of shaping this most important functionality into something that will serve the project's needs well. I also feel our 5-CURRENT (from the 4-STABLE branch point) to 5-STABLE transition has hurt the project and is an issue Core(.3) failed to adequately shepherd. I also think more "no objection" Core votes should have been a vote of real opinion ("yes" or "no") as that says to me the Core member put time and thought into the issue vs. taking a cop-out. I feel too much discussions of late are labeled a "bike shed" and immediately discounted. I believe the project should pay more attention to letting all committers state their position and having their position considered in direction and decisions. My most applicable attribute as a candidate is that I 100% dedicate myself to things I commit to. Core needs active members. I have dedicated myself to The FreeBSD Project for the past 9 years and made FreeBSD a major part of my life. I've found I have opinions on how The FreeBSD project operates, and well... I've mentored several new committers and I'm now offering to to become a larger part of making things happen. If elected I will dedicate myself to Core activities -- putting them above any other FreeBSD (and personal) activities. I do not feel it is appropriate to mention support for other candidates in ones candidate statement, so I'll stop here and hope for a great Core.4. ---------------------------------------------------------------------- Peter Wemm Last modified: Jun 16 21:18:45 2004 Well, its that time again. Time for soul-searching and grand plans. I fell into the trap of writing a manuscript again, something that I really do not like doing. So, here's an attempt to cut it down. Most of the old-school folk know that I've been around for nearly 10 years. For the last few years I've been lucky enough to work at Yahoo on FreeBSD. Apart from a few incidents with house moving and illness I've been able to dedicate 8-12 hours a day on FreeBSD things for most of that time. What do I stand for? Well, first of all, my firm belief is that it should be enjoyable to work on FreeBSD, and being able to get the satisfaction of being able to do something *right* is paramount. That is how FreeBSD started and is probably the most important thing to keep in mind when making day-to-day decisions. Most of the other challenges that we face as a project can be framed in terms of that goal. For some people, satisfaction comes from seeing the fruits of their efforts being useful and used by the community at large. Others get satisfaction from seeing code worked out and in in the tree. And so on. This diversity helps us. The project faces scaling challenges. Friction between developers directly hurts us and the larger developer community makes this increasingly difficult to manage. We're facing burnout in some of our old-school developers for many reasons (including things like dealing with email volume, developer friction etc). We've tried a few things and need to keep trying more. The TRB issue is still unresolved and needs to be clarified. core.4 needs to be willing to both try things *and* cut losses if it isn't working out. I'd even be willing to give a src-mgr thing a try. The project source repository issue is going to need to be dealt with by core.4. We also need to be realistic about what we can achieve as a project. I think we need to be more willing to retire old code, at least for the kernel. Doing something once for enjoyment is one thing, but doing it over and over again (eg: for drivers) is another thing entirely. After the 5-stable branch starts, I think we need to take a critical look at what is in the tree and do some spring cleaning. Who do I think would make a good core team? I'm going to try and resist the temptation to name names, but I believe experience in the project and dedication to FreeBSD is critical. Everybody needs to be level headed and a team player. (core.3 suffered internal friction for quite some time.) Above all, they be able to see the Big Picture. Participating in FreeBSD is *supposed* to be enjoyable, and that is where I would (hopefully) continue to direct my efforts. PS: Don't forget to consider Gordon and Maxime. :-) ---------------------------------------------------------------------- Robert Watson Last modified: Jun 9 03:58:42 2004 Statement: Over the past five years, I have been working for FreeBSD wearing a broad range of hats and in a wide variety of roles: the FreeBSD Core Team, Security Officer Team, Release Engineering Team, FreeBSD Foundation Board of Directors, the TrustedBSD Project, not to mention organizing developer summits and teleconferences, attending many conferences, and advocating FreeBSD to many audiences all around the world. I've had the opportunity to work closely with many members of our developer, ports, and documentation teams, as well as interact with many consumers of FreeBSD using FreeBSD in many ways -- be it using FreeBSD as a product to make their web services run faster and better, or companies that build complex appliance or operating system products based on FreeBSD. It's clear from these experiences that what draws so many people to FreeBSD is our commitment to technical leadership, the deep experience base of our developer and user communities, the chance to work with so many other competent and dedicated engineers, and the quality and history of the results. The primary objective of the FreeBSD Core Team is (and must remain) to support the FreeBSD Project in these areas. There are a lot of mundane administrative tasks on the plate of the Core Team; these have been happening, and need to continue happening (and ideally with continued effort to improve timeliness and responsiveness). Likewise, conflict resolution is an important area that the current Core Team has made significant strides in. However, the areas that the Core Team will need to focus on over the next two years are clear: (1) The most important will be managing the transition to 6-CURRENT as the primary development branch. The release engineering team is currently guiding the 5-CURRENT branch towards -STABLE after several years of aggressive development. The RE team will continue to lead refinement 5.x and control the flood-gates from the 6-CURRENT branch, as well as work to control divergence. However, it will be Core's responsibility to help identify and coordinate major new development projects, such as buffer cache work, continued SMP and threading performance optimization, etc. (2) To support (1), it will be necessary to revisit the need for a formal system architect. The FreeBSD Project moved away from having a system architect hat, with this role largely being played by consensus on the RE team (and elsewhere) relating to an impressively ambitious 5.x feature set. However, as work begins on 6.x, it will be necessary to carefully scope it, as well as make sure that work occurs to accomplish well-defined end goals for the 6.x branch. While the answer is probably not to re-introduce a single system architect position, some notion of authority will be required to navigate 6.x successfully, as not all projects that will be proposed will be mutually compatible in the desired time span. 5.3 will have accomplished some extremely impressive goals--6.x will have to be somewhat more restrained in that (as with the 4.x releases) it will represent honing and optimization of the capabilities introduced in 5.x. This won't preclude big new features, but will require a careful balancing act. (3) Introduce a more formal testing and QA regime to the FreeBSD Project. Over the last ten years, FreeBSD has largely relied highly skilled design and implementation work, code review, and wide field testing to maintain a consistently high level of quality for releases. With more aggressive feature goals and fundamental architecture work, combined with a user base that increasingly tracks changes between releases, we need to explore regular formal performance and functionality testing. We need to develop a set of regularly run regression tests and performance baselines to chart progress towards specific goals. This will require a substantial investment of resources, both in time and materials, but also offers substantial pay-offs. We will gain stronger insight into the work we do, and also be able to translate this insight directly into quality and performance benefits in our product. (4) Continue to bring in competent and experienced developers to the FreeBSD Project. Some of the project's newest members are some of its most enthusiastic and capable. I'm proud to have cajoled, sponsored, subtly manipulated, and mentored a number of these new committers into the project; however, continuing the growth of the project will require us to continue the work of seeking out new developers and draw them into our community. (5) Work to improve advocacy efforts for FreeBSD by improving transparency of the project. By introducing regular developer status reports, being the first Core Team member to write Core status reports several years ago, writing articles and doing interviews, and regularly presenting at a variety of conferences on the on-going work of the project, I've contributed to a broader awareness of our work in and beyond the BSD community. However, this is not enough! A coordinated effort to bring in and support new users, foster user groups, develop supporting material for advocacy, and work with other organizations with parallel interests will be critical. Many people are already working in these areas, but the FreeBSD Core Team can bring resources and legitimacy to bear in support of these activities, as well as providing a constant source of speakers for events, help in answering user questions, and help in guiding FreeBSD developers to address the most critical technical concerns for our user base. I believe I have contributed substantially to the growth of the FreeBSD Project in both technical and non-technical areas. My hope is to be able to continue to work on the Core Team in the future to continue this work, and expand our horizons. Somehow, every year is a critical year when it comes to the future of the project, and as usual, this coming year is more critical than the last. A strong Core Team will be vital as we move forward. Questions: (1) What about TRB? I think the current TRB suffers from the best of intentions by core, and a lack of truth in advertising when TRB was created. When the current core set out to create TRB, it was looking to create a technical review team that could review changes for technical appropriateness and provide a broad set of insights into the breadth of the system. TRB members signed up to provide technical review, and indeed have a breadth and depth of knowledge that any project would be proud to have on a technical review board. This approach was in part the result of a leaning by elected Core Teams over several years to attempt to address concerns that the Core Team should play a more administrative role, and a less technical role. While the TRB concept is not a bad one: providing access to a formal review team has proven valuable in many successful projects, I think the notion of divorcing technical dispute resolution from conflict resolution has not played out as hoped. ---------------------------------------------------------------------- Scott Long Last modified: Jun 4 07:55:31 2004 I've been using and developing on FreeBSD since 1994, prior to there even being a 'FreeBSD'. I was granted a commit bit in 2000 and have used it to develop and maintain a number of drivers, filesystems, and general infrastructure. I'm currently working on locking down CAM, porting the NetBSD ESP driver, and am dabbling in desgining a next-generation installer. I've been a member of the Release Engineering team for te past 2 years and have been the lead for the 5.x releases. My interest in the Core Team stems from my long-standing committment to FreeBSD and my desire to see it suceed. I think that the current core team has done a decent job over the last two years and I hope to continue the example set by them. Out of the candidates that are standing so far, I would vote for Peter, Warner, Marcel, Wes, and Robert. ---------------------------------------------------------------------- Simon L. Nielsen Last modified: Jun 17 20:25:02 2004 I have been a FreeBSD doc developer for around a year, and have been using FreeBSD for many years before that. While being a doc committer I have been working mostly on fixing many smaller issues in www/doc/manual pages, and trying to use a part of my "FreeBSD time" on developer/user relations, mainly through the PR system. My main reason for running is from a desire to help the FreeBSD project where I can, e.g. by doing some of the more administrative tasks so the really good src people can have more time to work on actual coding and improving FreeBSD. Since I'm a doc guy I'm sure that for at lot of the really technical src/ related issues that core probably will be faced with. I will, if elected, need to listen a lot to other people, but I still do a lot of coding (just not for FreeBSD at the moment), so I do feel that I will be able to handle those issues as well. I think a srcmgr group/role would be a good idea for handling new committers, and a TRB, in some way, shape or form, is also a good thing. Poul-Henning Kamp's recent funding campaign shows that is it actually possible to get people to donate money to specific projects. I think core should work to encourage such activities, but it is still important that it is not the project itself that handles the money to avoid potential problems for the project. Finally, I'm sorry for having no proper statement here for the first week, but I was out of town without proper Internet access very shortly after deciding to run. ---------------------------------------------------------------------- Wes Peters Last modified: Jun 13 17:49:54 2004 I am Wes Peters, and I've been involved in FreeBSD one way or another since 1.0. I've used FreeBSD since the start to develop applications for my "day job," which has changed a number of times in the past decade. I currently design and develop information appliances based on FreeBSD at my day job, and work on FreeBSD in other areas as the interest grabs me. In FreeBSD, I am a middle-of-the-road committer. I'm roughly in the middle of the list on number of commits, and roughly balanced between src, ports, and docs, though docs has been lagging a bit lately. In terms of real skills, I'm what used to be called a "system programmer," somebody very accustomed to the kernel ABI and many of the system utilities and comfortable working in both realms. I am a member of the current Core Team, and am generally pleased with what core.3 has managed to do. After a tumultuous unplanned start due to the resignation of members of core.2, core.3 made important progress in more fully defining the role of the Core Team in FreeBSD. The leadership of FreeBSD is much more distributed than ever before, with fully functioning teams fulfilling critical roles, including Release Engineering, Security, and the management of the ever-growing Ports system and it's cadre of developers. This Core Team has also reached the goal of openness I sought for in running for this position originally. I can faithfully and honestly report that the monthly reports prepared by Wilko really represent what the Core Team has worked on during the month. (The details elided in the Report you see fall into two categories: trivia and gossip.) This does not mean that core.4 can go into "cruise control," however. One area I feel core.3 failed in is providing a viable technical leadership panel for FreeBSD. We tried, in the form of the Technical Review Board, but failed to understand what was needed, and therefore failed to create panel that could effectively steer FreeBSD. I feel this will be the most important issue core.4 will face. The second issue I see is in some ways just as important: advocacy. I am regularly amazed at the inaccurate and untruthful information I hear about FreeBSD, ranging from the downright silly (it's possessed by devils) to outrageous lies (it won't run MySQL because it's GPL). I think I can help FreeBSD on these two important issues. FreeBSD Technical Leadership I think I have learned enough about how the FreeBSD community operates, and about how such a large project moves forward, to help create an organization that can be effective. I also believe I can help pick a set of people who are capable of making wise architectural decisions and who fully understand the wide range of uses FreeBSD is called upon to support. Bosko and others have asked for more details on what we think will work along these fronts, so here it comes: The RE and SO teams work because there is a single person in charge, who makes sure the work gets done. A successful architecture board will need this too. I propose we call this position "System Architect." We (the SA working in concert with Core) will provide the SA with a team of people with the skills and qualifications to judge design proposals on their technical merits. Experience with core.3 has taught us the most effective way to deal with any issue is to have 2 or 3 people who are active and interested in a subject deal with it and report back. I propose to hand this model to the SA as the initial working model for the Architecture Team. The SA will, of course, be able to call on other specialists in the FreeBSD community for their advice and counsel as needed. I don't think we need to elect this team because I don't think we need another election. We pick the Core Team by election so they can serve at the will of the FreeBSD community and make good decisions, including appointing officers like SO and RE; there isn't a compelling reason to do otherwise with the SA role. If the Core Team screws up horribly and appoints an architecture board that goes off on a tangent, we recall the Core Team, revert back to a previous CVS revision, and proceed. I'll note that the Ports team seems to be rapidly approaching a similar point in their growth curve, where they may need to begin putting together teams to focus on managing the influx of new ports, maintaining and developing the ports infrastructure, etc. This is a sign of their incredible success and I think this core team can help portmgr push through this next growth phase. Advocacy The only avenue I see to getting the word out, given our advertising budget, is more articles in the mainstream trade press. We have some very talented writers who write regularly about FreeBSD; I believe I can help in several ways. In addition to simply writing more myself, I can also help bring together people with technical details of interest to the community and people with writing talent to describe these projects. I can help organize the advocacy community along the lines that have worked so well for some of the other roles core.3 organized. What I need to know from you, fellow committers, is if you believe I can accomplish these goals better as a member of the Core Team or not. Thank you for your consideration. ----------------------------------------------------------------------