[00:47:26] --- reuteras has left [01:19:01] --- dragos.tatulea has become available [01:28:43] --- dev-zero@jabber.org has become available [01:57:43] --- manfred furuholmen has left [01:57:57] --- Simon Wilkinson has become available [02:02:07] --- Simon Wilkinson has left [02:03:38] --- Simon Wilkinson has become available [02:07:00] --- Simon Wilkinson has left [02:09:05] --- Simon Wilkinson has become available [02:21:55] --- Simon Wilkinson has left [02:23:33] --- manfred furuholmen has become available [02:28:07] --- Simon Wilkinson has become available [02:30:59] --- Simon Wilkinson has left [02:45:26] --- Simon Wilkinson has become available [02:50:47] --- Simon Wilkinson has left [03:02:57] --- manfred furuholmen has left [03:04:41] --- manfred furuholmen has become available [04:07:41] --- mmeffie has left [04:15:01] --- Simon Wilkinson has become available [04:18:42] --- Simon Wilkinson has left [04:18:43] --- Simon Wilkinson has become available [04:26:47] --- Simon Wilkinson has left [04:55:06] hello all [04:57:25] --- Derrick Brashear has become available [05:00:13] hi [05:00:28] gm [05:00:45] I hope everyone slept well [05:00:57] well, it's morning anyway, it's too early for it to be good :) [05:01:14] it's about the usual time for me [05:01:44] asanka may join us after he gets on Amtrak [05:02:16] cool cool [05:04:01] we have an hour so I think we should get started. First, I would like to thank Jake for taking on this project. communication with the user community is one of the most important aspects of any software organization and it is something that I feel openafs is particularly poor at. [05:04:47] I'm more than happy to be of use [05:04:51] The gatekeepers have a rough idea of what we want but simply don't have time to do all of the necessary leg work. [05:05:37] I think a good place to start is to review some of the goals. [05:05:42] (or, necessarily, web design skills) [05:06:31] First, the resulting web site should be primarily focused on the user, not the developers. [05:07:16] there had been talk before SoC about maintaining the current site, and having that be directed towards developers. I assume that's still a possibility? [05:07:35] well, it wouldn't be the same [05:07:54] but i assume things like source browsing, deltas, release notes etc would be a virtual site (developer.openafs.org?) [05:07:55] developers have a different set of needs and I believe they should be addressed on a different site [05:08:40] entirely disconnected? or just a sub-site, as Derrick suggests? [05:09:12] a link from the www.openafs.org but other than that it does not have to use the same design [05:09:14] it doesn't matter [05:09:29] alright, that's reasonabel [05:09:33] reasonable* [05:10:02] the rest of the site should provide an integrated experience [05:10:20] the developers will figure out what they need. [05:10:41] lets talk about the needs of developers another time [05:10:45] ok [05:11:29] I still believe that http://www.freebsd.org/ is an excellent site. Even better in some respects than Apache and Mozilla [05:12:15] though the analog of the "get freebsd now" button should use your user agent to offer openafs for your platform, first [05:12:28] (with a link to take you elsewhere if you want openafs for something else) [05:12:43] see e.g. getfirefox.com [05:13:06] right, I agree. [05:13:45] (for the purpose of configuration you can assume apache. obviously whatever you load on top of it is to be determined, but for configuration etc, it will be apache) [05:13:48] Organic? http://www.mozilla.com/en-US/firefox/organic/ [05:14:49] I don't know that I like the bottom box on freebsd.org [http://freebsd.org], also, I don't know that OpenAFS has a need for it [05:15:14] how so? [05:15:18] right now the front of www.openafs.org is a running "current news" [05:15:19] or how not? [05:15:27] that design would allow a much more elegant way of doing it [05:15:50] because right now the layout conflates "current" with "things you need to know which are no longer current" as well as "upcoming" [05:16:00] and that design would mostly handle it [05:16:10] that's all true [05:16:11] my q. was to jake [05:16:23] understood, i was telling him why i thought we did need it [05:16:25] want it [05:16:44] understood, I want to understand why Jake thought we didn't [05:17:41] it seems as though a lot of what would be there, for OpenAFS, would go unchanged for long periods of time, with the exception of releases [05:17:47] that's fine [05:18:15] it's already true of our existing front page and it's not necessarily a bad thing [05:18:23] nor do we have to use the columns the exact same way [05:18:37] but security alerts pobably want to show for a while [05:18:42] (for instance) [05:18:53] that's fair. I'm not wildly opposed to the bottom box [05:18:57] even assuming that is true. it is important for users to be able to easily find workshops. and if had a better way of displaying the info it would make sense to add user group meetings in various locations. [05:19:23] Errata notices are not something we would use at present. [05:19:51] right [05:19:52] Nor do we get a lot of media attention although that is certainly something we will get once the Foundation is created [05:19:53] I do like that all of those have RSS feeds affiliated with them [05:21:24] The most important thing for me is that the top level page has the important topics right in front of the visitor. There isn't a lot of guess work as to where to go next [05:21:58] --- Evan Macbeth has become available [05:22:20] yes, I agree [05:23:46] "Get OpenAFS Now" and more general release news. "New to OpenAFS" are critical functions we don't have. "Support". I like the Mozilla support http://support.mozilla.com/en-US/kb/Firefox+Support+Home+Page better than the FreeBSD support page but it will take time for us to build up a working knowledge base [05:24:17] what do we have in the way of documentation? [05:24:43] the original IBM documentation, which is out of date [05:24:45] the man pages [05:24:53] which are not out of date [05:25:02] the documentation for the various releases [05:25:15] (release notes, change logs) [05:25:17] what we have is on the existing site. the old IBM install / admin guides, the new man pages, our wiki content, mailing lists, irc/jabber logs, ... [05:25:44] those are currently searchable using a custom google search off of the openafs.org page [05:26:21] most of them. the search probably needs to be updated to cover the jabber logs [05:26:57] I'm fairly sure I added them [05:27:15] that the box is effectively a feed makes life easier for adding content to them; you can manage it as a feed [05:27:28] true [05:27:36] and what that means is you have your choice of tools for managing such things [05:27:46] and can pick something which suits needs well. [05:28:16] I've been under the impression there are also various unofficial documents floating around for setting up a cell, etc. [05:28:19] the ideal situation (still) is that we get something which is capable of outputting a web site composed of static pages (and javascript if needed) [05:28:27] do we care about them? [05:28:35] so we can deploy single configuration worldwide without needing to replicate a database [05:28:46] (though a readonly database in sqlite could be replicated in an afs volume) [05:29:08] we probably care about them though it's not necessarily your problem to merge them [05:29:15] ok [05:29:35] in particular, they probably want to be updated to reflect [05:29:38] --- Evan Macbeth has left [05:29:39] 1) current reality [05:29:43] 2) as many systems as possible [05:29:44] --- Evan Macbeth has become available [05:30:26] in that sense either an expert or many contributors who are experts at platform level will need to contribute [05:30:52] lets talk about specific goals for this week [05:31:01] so some form of user content addition would be nice [05:32:18] (1) we should decide on a survey method (2) finish a first draft of a survey (3) create a wiki page that is just a running list of ideas for the site [05:33:18] (including the things discussed here) [05:33:19] script and tools will be nice too [05:33:30] manfred: in which sense? [05:34:37] for example a collection of tool like http://www.eyrie.org/~eagle/software/ [05:34:56] ah, you mean you'd like us to distribute them [05:35:03] I don't know a central repository or a simple links [05:35:06] or just refer to them [05:35:07] as [05:35:28] while i don't disagree and the web site will need to accomodate, there's not much in terms of site design which will need to be done for it [05:36:25] it would probably be a set of feeds organized by category [05:36:40] for me a wonderful thing will be a "resume" of the week .. [05:36:51] in much the same way that per-platform, releases could be modeled as a series of feeds also [05:36:57] why a resume of the week? [05:37:00] > for me a wonderful thing will be a "resume" of the week .. [05:37:10] subversion did this with not much apparent success [05:37:16] something like a lwn.net [05:37:17] how does that benefit end users? [05:37:26] (like, the focus developer of the week sort of thing?) [05:37:47] where you can give the feeling on development or support [05:38:13] an end user organization of the XXX makes more sense when it comes to selling the product [05:38:21] convincing orgs that they want to use it. [05:38:33] shadow: yes, something that the people can read every day the jabber,irc .. [05:39:23] i'm failing to parse. but regardless i suspect it's something who wants to get afs or learn why they should deploy it aren't going to care [05:39:27] jeff: if nothing else, it shows that the project is still active [05:39:58] we had that for project jxta. I think developer / product of the week makes sense if your target end users are developers. I do not think it is appropriate for a project whose target audience is end users. [05:40:03] a project roadmap, showing goals and progress, could be used for that [05:40:29] bar graphs of project timelines against time, for instance. [05:40:42] true [05:40:46] jake: the project will be seen as active if new releases are issued, if documentation is updated, and if there are organizations willing to be showcased [05:41:34] we absolutely need a project road map [05:41:44] yes, I agree. a daily/weekly/monthly status report or what-have-you would be more granular, which some might appreciate [05:42:01] --- Simon Wilkinson has become available [05:42:10] the gatekeepers actually write those reports now. they just never make it anywhere visible [05:42:43] are they opposed to it being visible? [05:42:48] no [05:42:58] there's no one who has time to edit them into a form suitable for display [05:43:15] laura stentz has, as she has had time, made reports of elders meetings available and we have published them [05:43:16] I see [05:43:29] and as these have been submitted in that forum they would logically have appeared there [05:43:41] (though in the future that would not be true) [05:46:50] I think a wiki of ideas and planning is a good idea (if not a google doc spreadsheet to manage tasks...) [05:47:23] I would like to have a monthly newsletter but that is another project. We need to find someone to be the editor of it like MozillaZine [05:47:45] --- Doug Hirsch has become available [05:48:09] An ideas or projects list is probably a good plan. The problem with managing tasks is that that's very hard to do when the resources aren't yours to manage. [05:48:14] it would contain a summary of what is going on with OpenAFS. Summary of gatekeeper reports, important discussions on the openafs-info list, new releases, etc. [05:49:52] we have a projects and road map list now. ideas that are submitted and thought to be good ones for OpenAFS are added to it. Our problem that we run into at every non-OpenAFS conference we present at is that we can't commit to delivery timelines for most of the work [05:50:19] likewise that no project plans appear with the items on it [05:50:50] estimate release date should useful [05:51:02] many places do both projects/roadmap and a 'requested feature list' [05:51:15] manfred: that's not really something you need to in a web site design [05:51:50] I think a list of projects, along with rough difficulty would be a good idea. It helps trigger people who are looking for something to do. [05:52:06] manfred: we would love to. without the ability to control the resources we can't make commitments. as Derrick says, it is off topic for this discussion. we have ten minutes left. can we focus on what needs to be accomplished this week by Jake? [05:52:09] It also reduces the scramble to produce ideas lists for things like Summer of Code. [05:52:34] shadow: I know you and simon say " we are ready when it is ready" and it is right, but today many project try to move in a "deterministic way" .. see ubuntu .. postgres [05:52:50] GSoC was not a scramble to produce ideas. It was a scramble to produce designs. That is a very different matter. [05:53:00] manfred: wait 10 minutes [05:53:18] I wish I was a moderator so I could set the topic. [05:53:32] pardon [05:53:45] Jeff, your list above was reasonable, I can send anyone interested a quickly pulled together list of questions for review in a few minutes [05:54:07] jake: do you have an account on the wiki? [05:54:11] I do [05:54:18] did i approve you for posting? [05:54:29] you did, I put the pioctl doc up over the summer [05:54:35] excellent [05:54:41] (note: any wiki poster should be able to approve any other; i'm just the only one who gets email nagging me) [05:55:15] --- Evan Macbeth has left [05:55:22] --- Evan Macbeth has become available [05:55:59] then yes, if you can summarize the list of things we talked about on the wiki, and post a link to the mailing list to encourage people to update things we might have missed, that's probably a good place to start from. [05:56:13] please put up a project page for the web site design. a separate page for content ideas. another page for survey questions. a page to discuss strengths/weaknesses of content management solutions. and a page to record info relating to the survey methods we might use [05:56:37] can this dialog continue on that project page? [05:57:01] ideally the dialog best would continue here, as wiki is not really a discussion medium [05:57:05] this forum is logged [05:57:58] jake: next please do more research on survey engines so that we can make a decision early next week as to which route to take. [05:58:39] I think conditional branches for the survey are important. [05:58:50] Jeff, ok. Do you have a set of criteria that we're looking for? [05:59:00] I tend to agree that conditional branches are important [05:59:54] and the analysis tools must be accessible and easy to use. We can put up a page of our own with a series of questions. Analyzing the responses will be the hard part [06:00:44] I think being able to add graphics to the questions would be beneficial. [06:00:56] although we can certainly live without it [06:01:03] from my small amount of research last night, it looked as though it was hard to tell how easy to use the interface was without testing [06:01:10] agreed [06:01:24] please test at least the free functionality [06:01:42] yep, was planning on it anyway [06:02:40] --- Simon Wilkinson has left [06:02:45] thanks. [06:03:14] I'll get the wiki pages up hopefully today or tomorrow, Thursday at the latest [06:03:22] excellent. thank you. [06:03:25] finally, bug me to add an outline of a site map to the wiki after you have the page up [06:03:46] --- Doug Hirsch has left [06:04:13] lets schedule regular meeting time. it doesn't have to be this one. I think we should meet twice a week at the start. [06:04:20] what works for you? [06:04:28] let me check, hold on [06:05:56] MWF any time after 3:20 CST [06:06:17] Tuesday any time after 12:30 CST [06:06:39] Thurs, between 2:00 and 4:00 CST [06:06:44] or early mornings [06:07:53] do we need a full hour? [06:08:00] I would like a range of times so that folks on the West Coast are able to participate. How about Mondays at the time we met at today 7:00CST and Thursdays at 14:30 CST [06:08:00] tues and thurs 3:30pm cst? [06:08:14] > How about Mondays at the time we met at today 7:00CST [06:08:38] while i don't care because i'm up i bet we kill our participation by "monday early" [06:09:12] Monday afternoons is very full for me meeting wise [06:10:21] I'm ok with whatever. I would tend to prefer later meeting times, but I can do mornings also [06:11:18] does late night work better? [06:11:34] then we can just make everyone unhappy [06:11:38] for me, but presumably not for people with normal jobs and things :) [06:12:33] anyone here with a normal job please raise your hand. [06:12:35] ;) [06:12:38] I can just suck it up and stop being a stereotypical college student, I'm ok with that [06:14:10] lets meet at Thursday at 14:30CST and we can confirm Monday at that time. [06:14:27] I motion for end of meeting [06:14:39] manfred, back to your question on release schedule: [06:15:14] my hope is we can publish something more formal in the next month or so, moving to a schedule of something like 2 or 3 stable releases per year. [06:15:58] new features would be targeted for a given release, and obviously bugfixes incorporated as needed. [06:16:03] but right now, that's a pipe dream [06:16:38] you have volunteers, effectively, doing the work on hardware which in many cases is volunteered by a different sets of people. [06:16:55] so, you can want it, and i can tell you it would be good and well to give it to you [06:17:03] but, beyond that promising anything is hard [06:19:17] First of all, sorry to put a "off topic" item [06:20:30] I can understand, I 'm agree with you, but as you said is a pipe dream .. of many people [06:20:50] sure [06:21:24] cynically: if those people want to provide hosted hardware and dedicated resources to make keeping a schedule possible, they can write the check today :) [06:24:31] I think on the hardware side like building farm, it is possible in a resonable amount of time [06:24:34] --- Simon Wilkinson has become available [06:24:46] money or developer is quite difficult [06:24:50] sure. got one for us? that supports aix, hpux, irix? [06:25:15] Wouldn't it be better to actually have a schedule and put things like 'builds' into a separate category? ie, a lot of open source projects do source releases as the core release, and the binaries are more 'case-by-case'. [06:25:19] still irix ? [06:25:32] It seems to me that if AFS did a similar approach, that might ease some of the pressure on releases. [06:25:45] still irix [06:25:47] s/case-by-case/contrib/ [06:25:51] postgres and samba use an intresting approach .. [06:26:11] steven: catch up on the last 10 minutes? [06:26:14] the problem is that often builds on one platform identify bugs on others. [06:26:23] I have very old hw by sgi .. i will turn on .. [06:26:52] shadow - that's what I did, and why I responded w/what I said. [06:27:00] secureendpoints - I understand that. [06:27:13] you failed to read the bit where i said we wanted a schedule, or you disbleieved? [06:27:30] I'm not saying it would be problem-free to change the release model, just wondering if that wouldn't be a bit easier. [06:27:42] shadow - neither. [06:28:03] an organization that uses openafs wants to be up to upgrade all of platforms to the same release [06:28:20] so... fit your comment into what's already been said, since "neither" sort of fails to mesh [06:28:29] ie,your answer is "if we have more money & resources, we can do more regular releases"; my feedback is "could we change how we do releases to make it easier to do regular releases" [06:29:10] only if you don't care about testimng [06:29:12] secureendpoints - I understand that desire and agree w/it. [06:29:16] and in that case i can do them today [06:29:32] --- jhutz@jis.mit.edu/owl has become available [06:29:38] if you want a source code release you can take the current stable tip whenever you want [06:29:52] --- Simon Wilkinson has left [06:29:52] --- Evan Macbeth has left [06:29:57] jeff, that's explicitly not true [06:29:58] --- Evan Macbeth has become available [06:30:17] --- Simon Wilkinson has become available [06:30:21] That's why we have _releases_ on stable [06:30:26] (realizing this may come across fairly harsh): if a group wants a particular platform supported but yet doesn't step up to help get the testing & building done, then, well, 'sorry'. [06:30:28] its as true as it would be for any platform that did not have a build done for it [06:30:46] http://www.pgbuildfarm.org/cgi-bin/show_status.pl [06:30:52] steven: well, if you want to start a project that works that way, go nuts [06:31:44] build farm != test farm [06:31:46] I'm not suggesting a fork, but just suggesting that we might look at our release model differently. [06:32:29] you're suggesting moving to a model where instead of looking for support up front we cut off people who are on some platforms unless they support us [06:32:52] yes: but is the second step ( or 3rd) if you use unitest [06:33:05] might as well stop working on any of the clients [06:33:07] unit tests of kernel modules aren't exactly simple [06:33:24] also the name in the pg is not complete true, because at end of compile task they run the application test [06:33:27] regression [06:33:42] steven: i don't think there's much critical mass behind that model here. certainly i can tell you i have no interest in it [06:33:59] either we support a platform or we don't. if we do, we do. [06:34:12] shadow - a lot of details would need to be worked out, but I don't think the community would be against a list of supported systems vs 'best effort', with the proviso that anyone can help provide resources to move something from 'best effort' basis into 'supported', but that the 'best effort' systems would not be in the critical path for releases. [06:34:31] Actually, user-mode unit tests probably are possible for much of the code that is intended to run in kernel mode. [06:34:44] if we fixed libuafs, yes [06:35:01] Yes, and we should fix libuafs. [06:35:11] But it doesn't solve our kernel testing problem completely. [06:35:15] no, even if we didn't. unit test doesn't mean testing the whole. It means testing the individual units, and much of that code can be pulled out into pieces and linked into a user-mode test program. [06:35:30] without resources to test (which may then be smaller) i still think doing scheduled releases is not a player. and at that point you might as well go the last few yards and do it eright [06:35:42] but ==simon, there will always be some tests that can only be done on a real kernel. [06:35:49] which is useful but it still won't handle any of the issues related to VFS layer interactions [06:36:18] --- Evan Macbeth has left [06:36:19] ==secureendpoints. Where we get broken (as opposed to where we break things) is in the VFS interactions. [06:36:24] --- Evan Macbeth has become available [06:36:47] also vm system interactions. but yes [06:37:06] --- stevenjenkins has left [06:37:07] only because some of the kernels we deal with don't have anything resembling a VFS provider interface. If they did, we could write test harnesses that simulated them and help with a large portion of issues. [06:37:32] Yes. But until we drop Linux, and BSD, and ... we're not going to get there. [06:38:01] For example, Windows' driver interface is apparently sufficient stable that, at least for some kinds of drivers, there are tools that let you load them into Linux [06:38:08] so sad [06:38:34] We're not going to win the interface stability battle. [06:38:53] we don't even win it with MacOS X [06:39:14] No, we don't have powerful enough weapons for that. I suppose we could try telling everyone to migrate to opensolaris. [06:39:54] their interfaces have the "well, not all ssubsystems are documented period, so we reserve the right to document and change *those*" [06:40:09] anyway, I think I partially agree with steven. For a lot of people, a "best-effort" platform that is in the code and which we try to avoid gratuitously breaking but also don't do testing or binary builds or hold releases for, is better than a platform that is not supported at all. [06:41:16] only if it is not the platform they use [06:41:34] I'm not sure. I can see we don't want to indefinitely hold releases. But I also don't think a time-based release schedule works for a project which is as resource strapped as OpenAFS. [06:41:49] none of that gets things tested on the platforms we do have. linux has been the biggest issue, i'd guess that one is not "best effort". so what's the point, gain? [06:41:54] Sun has traditionally cared a lot about stability of interfaces once they declare them stable, and had a better track record even with others. For example, the nsswitch provider interface has not changed significantly in a very long time, until sparks, which defined a new one, documented it, and advanced its stability. [06:42:01] --- stevenjenkins has become available [06:42:21] in which case what we end up with is a situation in which we release x.y.0 and then the best effort folks come back and say "it don't work", so we fix a bunch of stuff, and then must issue a new x.y.1 [06:42:53] No. Even if it is the platform they use. A platform I can compile and run the code on is better than one on which I cannot, even if I have to run something a bit older or fix some bugs myself. Jeff, I say this from years of experience building and deploying software for our computing environment. [06:43:32] No, we don't do a new release just to fix the best-effort things. We keep track of the patches and merge them so they are in the next release. [06:43:50] I think the problem we respin very late to fix build issues. [06:44:00] s/problem we/problem is that we/ [06:44:28] If we had better tinderbox/buildbot coverage we could perhaps avoid this. [06:45:22] "latest kernel" coverage is hard [06:45:52] if you bug me later i will explain a model i think buys more than steven's. not right now. [06:46:03] Okay. I will bug you later. [06:46:30] I was more thinking of issues where the release build for 'X' is the first point that build problems on it are found. [06:46:33] --- agoode has become available [06:46:40] Like we've had on Irix in the past, for example. [06:46:44] But I'll bug you later [06:46:55] --- Evan Macbeth has left [06:47:04] --- Evan Macbeth has become available [06:50:35] I do think we should target a regular release schedule. I try to issue monthly releases for Windows which address the bugs that have been identified in the previous period. that is much easier to do for a single platform than for many. [06:51:17] We'd scare away a lot of Unix shops with a 'stable' release schedule that was that frequent. [06:51:30] what typically happens to us is that if a stable *nix release takes 4 to 6 weeks to get through the beta period, linux pulls the rug out from underneath us before we get to the end [06:52:48] I'm not sure that we need 'stable' to track current Linux quite so aggressively. [06:53:08] Only if you expect to run "stable" openafs against bleedy Linux [06:53:17] ==simon [06:53:42] that isn't the problem. the problem is that users have openafs installed and their linux kernel gets updated through an automated update process and we lose [06:54:51] Yes, but the rate at which you lose is slower. [06:55:07] That doesn't happen because we take 4-6 weeks to go through the beta cycle. That happens because we go 9 months between releases. [06:55:15] s/9/7 [06:55:44] Typically, we're tracking kernel.org releases. [06:56:31] openafs-1.4.7 source tarballs were created april 28. It looks like the release happened around May 3 or so. We'll be lucky if we get 1.4.8 out by the start of December. [06:56:58] would it help to track distro kernels as well as kernel.org ones? That seems that it would address the concern secureendpoints has [06:57:11] 1.4.8 was tagged. the builds are already copying in [06:57:35] luck has nothing to do with it [06:57:53] Luck has everything to do with how many build problems we'll find. [06:57:53] i have ideas which would handle the linux issues. i will explain later. [06:58:06] No. Tracking kernel.org lets us be the latest and greatest. [06:58:23] The distros will typically lag, between several weeks and 'never'. [06:58:25] linux is done. beyond that i expect no build problems, and i'm 99.9% certain of that. [06:58:54] No, we don't need to track distro kernels. The fun new problems virtually always come from upstream. As long as we track kernel.org reasonably well, and do releases on a reasonable schedule, then all that is needed is for people packaging openafs for their distros to push out openafs updates in time to support new kernels for that distro [06:59:00] simon - so your saying the automatic kernel update problem isn't really a problem. [06:59:11] It's not a problem at release time. [06:59:14] it's not *the* problem [06:59:30] It can be a problem between releases, but then we'll typically just pull in patches and push out a patchlevel RPM. [06:59:42] I don't really see Linux as a big issue here. [06:59:51] can we reconvene in an hour and discuss it? i really want to change locations. [06:59:57] ==sxw The automatic kernel update problem is a symptom of upstream changes making it into distros before we've had a chance to deal, or at least before we've released, because we're lame. [07:00:15] We're not stopping you from changing locations. [07:00:35] --- Evan Macbeth has left [07:00:41] --- Evan Macbeth has become available [07:01:14] i'd also like to *discuss* it, which if i change locations now... [07:01:29] your statement, however, was 100% correct if useless. [07:02:36] Okay, so let's leave it an hour. [07:02:55] But when it comes to releases, I really don't see RPM-based Linux (or Debian Linux) as a real problem. [07:04:01] So, the kind of statement you'd make. :-) [07:04:08] No, me either. [07:05:10] --- MacDeveloper has become available [07:05:23] --- MacDeveloper has left [07:05:41] --- Claudio Bisegni has become available [07:05:59] --- Simon Wilkinson has left [07:18:05] --- agoode is now known as Adam Goode [07:21:02] --- matt has left [07:21:36] --- Adam Goode has left [07:24:32] --- Derrick Brashear has left [07:24:53] --- Claudio Bisegni has left [07:25:12] --- Simon Wilkinson has become available [07:26:29] --- agoode has become available [07:29:52] --- Evan Macbeth has left [07:30:41] --- Evan Macbeth has become available [07:33:58] --- Simon Wilkinson has left [07:40:25] --- Derrick Brashear has become available [07:43:02] --- matt has become available [08:00:50] i'll have a web page with a draft of what i propose in 5 minutes [08:06:44] --- floh has left [08:08:44] /afs/andrew.cmu.edu/usr/shadow/release.html [08:13:29] looks fine to me [08:16:10] --- Claudio Bisegni has become available [08:18:00] although it should include a time frame for when patches must be submitted by in order to be considered for the release. Do we want two weeks or four weeks before the first pre-release build for patch submissions? [08:20:37] 2 [08:24:52] updated, same place, to reflect patches needing to be in for review 6 weeks before... [08:31:01] --- Evan Macbeth has left [08:44:15] --- Simon Wilkinson has become available [08:56:19] --- Simon Wilkinson has left [08:58:41] --- Simon Wilkinson has become available [08:59:15] --- Claudio Bisegni has left [09:01:06] --- dragos.tatulea has left [09:04:04] --- Simon Wilkinson has left [09:11:39] --- Simon Wilkinson has become available [09:13:07] --- dev-zero@jabber.org has left [09:14:28] --- Simon Wilkinson has left [09:31:32] --- manfred furuholmen has left [09:34:08] --- Simon Wilkinson has become available [09:39:09] --- manfred furuholmen has become available [09:41:09] --- manfred furuholmen has left [09:41:52] --- Simon Wilkinson has left [10:18:43] --- dev-zero@jabber.org has become available [10:30:01] --- summatusmentis has left [10:30:09] --- summatusmentis has become available [10:46:05] --- summatusmentis has left [10:53:09] --- mmeffie has become available [12:12:16] --- summatusmentis has become available [12:12:50] --- Derrick Brashear has left [12:13:01] --- Derrick Brashear has become available [12:33:47] --- dev-zero@jabber.org has left: Replaced by new connection [12:33:48] --- dev-zero@jabber.org has become available [12:49:56] --- dmontuori has become available [13:04:12] --- Derrick Brashear has left [13:14:43] --- summatusmentis has left [13:42:42] --- tkeiser@sinenomine.net/owl has left [15:03:19] --- Derrick Brashear has become available [15:15:06] --- dev-zero@jabber.org has left [15:30:52] --- edgester has become available [16:05:27] --- matt has left [16:16:45] --- summatusmentis has become available [16:33:48] --- Marc Dionne has become available [17:14:32] --- summatusmentis has left [18:19:49] --- edgester has left [19:10:28] --- Marc Dionne has left [19:24:55] --- summatusmentis has become available [19:45:24] --- summatusmentis has left [20:19:42] --- summatusmentis has become available [20:46:51] --- dev-zero@jabber.org has become available [21:09:49] --- summatusmentis has left [21:28:32] --- summatusmentis has become available [21:59:35] --- dev-zero@jabber.org has left [22:20:35] --- tkeiser@sinenomine.net/owl has become available [22:36:09] --- floh has become available [22:37:20] --- manfred furuholmen has become available [22:42:35] --- dev-zero@jabber.org has become available [22:44:07] --- manfred furuholmen has left [23:03:34] --- reuteras has become available [23:10:25] --- haba has become available [23:57:05] --- manfred furuholmen has become available