Re: Release Schedule for 1.8
On 1/3/07, Matthew Dillon [EMAIL PROTECTED] wrote: : : Include ALTQ in generic? Hmm. I would personally rather not, unless : a really good case is made for including it. : :The only reason why I say this is the fact that many would like to use BSD flavors as home routers with transfer rate limiting, and regular lines don't require a too powerful computer, an 586 or 686 will do (we were NATing 10Mbit with a PI-133 and 48M EDO RAM.) On these machines, kernel building takes hours. Well... you do the build on a faster machine and copy the binary? that requires some other dfly machine, does it not? : We *are* including : kernel sources on the ISO now, so perhaps a better solution would : be to create a section on how to set up a kernel build infrastructure : given just a freshly installed ISO. : :Do you mean the nativekernel target? : :-- :Gergo Szakal [EMAIL PROTECTED] Yes. It should theoretically only require the sources tar'd up on the CD to build a new kernel. That is one of the things that we have to test for this release... can you unpack the sources stored on the ISO in a chroot'd environment and actually build the kernel without the rest of /usr/src ? Inquiring minds want to know! -Matt -- Miguel Sousa Filipe
Re: Release Schedule for 1.8
On Thu, 4 Jan 2007 19:09:33 + Miguel Sousa Filipe [EMAIL PROTECTED] wrote: On 1/3/07, Matthew Dillon [EMAIL PROTECTED] wrote: : : Include ALTQ in generic? Hmm. I would personally rather not, unless : a really good case is made for including it. : :The only reason why I say this is the fact that many would like to use BSD flavors as home routers with transfer rate limiting, and regular lines don't require a too powerful computer, an 586 or 686 will do (we were NATing 10Mbit with a PI-133 and 48M EDO RAM.) On these machines, kernel building takes hours. Well... you do the build on a faster machine and copy the binary? that requires some other dfly machine, does it not? No, it's enough to put the HDD into another, fast machine for that time. I have done it a couple times. -- Gergo Szakal [EMAIL PROTECTED] University Of Szeged, HU Faculty Of General Medicine /* Please do not CC me with replies, thank you. */
Re: Release Schedule for 1.8
On 1/2/07, Justin C. Sherrill [EMAIL PROTECTED] wrote: On Tue, January 2, 2007 1:45 am, Karthik Subramanian wrote: Is there someplace where there's a list of release-oriented code bits/features, so that people can pick off stuff that they're interested in testing? I'm moving to a different city/state in a week or so, so i'm not sure if I can contribute to any testing right away - but I'd like to take a look all the same. That would be a good thing for the wiki. In fact, if you want to help out... I'd love to - but I'm going to be off the internet for around a couple of weeks starting Friday, and I'm not sure how much I can do before that :(
Re: Release Schedule for 1.8
:Matt, what about the SMP kernels? :Oh, and may I request ALTQ be compiled into it/them by default? : :-- :Gergo Szakal [EMAIL PROTECTED] :University Of Szeged, HU :Faculty Of General Medicine I don't think we're going to be able to include SMP kernels on the release ISO for this release, when it was brought up last time a number of issues were pointed out that would require us to have at least two and maybe even four different kernel binaries (and related module directories) to cover all the bases. Include ALTQ in generic? Hmm. I would personally rather not, unless a really good case is made for including it. We *are* including kernel sources on the ISO now, so perhaps a better solution would be to create a section on how to set up a kernel build infrastructure given just a freshly installed ISO. -Matt Matthew Dillon [EMAIL PROTECTED]
Re: Release Schedule for 1.8
On Wed, 3 Jan 2007 12:58:11 -0800 (PST) Matthew Dillon [EMAIL PROTECTED] wrote: Include ALTQ in generic? Hmm. I would personally rather not, unless a really good case is made for including it. The only reason why I say this is the fact that many would like to use BSD flavors as home routers with transfer rate limiting, and regular lines don't require a too powerful computer, an 586 or 686 will do (we were NATing 10Mbit with a PI-133 and 48M EDO RAM.) On these machines, kernel building takes hours. We *are* including kernel sources on the ISO now, so perhaps a better solution would be to create a section on how to set up a kernel build infrastructure given just a freshly installed ISO. Do you mean the nativekernel target? -- Gergo Szakal [EMAIL PROTECTED] University Of Szeged, HU Faculty Of General Medicine /* Please do not CC me with replies, thank you. */
Re: Release Schedule for 1.8
Timothy wrote: On Tuesday 02 January 2007 12:11, Matthew Dillon wrote: Well, my biggest issue for this release is that all the packages that compiled and ran on 1.6 also compile and run now... ...I'll do a compile of kde and gnome, that should wring it out pretty good. Yes! And thanks for joining the DragonFly community, Timothy. There are a few chronic difficulties with a few pkgsrc packages, caused by Matt's ongoing changes to the data structures in the kernel. These changes have affected mostly apps which require access to kernel statistics like CPU/memory usage, network load, etc. Things, e.g., that 'top' displays -- and therefore similar userland packages like gnome's libgtop2, and system-monitor-like packages from kde. The other big category of problems I've noticed is with any package that needs access to CD hardware. This is due to changes in the location of header files in the DF source tree. (These are trivial to fix once you know where to find the header files.) So, please build away, and report back with problems. Thanks!
Re: Release Schedule for 1.8
On Tue, January 2, 2007 1:45 am, Karthik Subramanian wrote: Is there someplace where there's a list of release-oriented code bits/features, so that people can pick off stuff that they're interested in testing? I'm moving to a different city/state in a week or so, so i'm not sure if I can contribute to any testing right away - but I'd like to take a look all the same. That would be a good thing for the wiki. In fact, if you want to help out...
Re: Release Schedule for 1.8
Well, my biggest issue for this release is that all the packages that compiled and ran on 1.6 also compile and run now. One thing I would like people with extra (test) machines to do is to do a clean install and then build their packages starting with a clean slate and see what problems pop up. People running HEAD can do the same thing without reinstalling by constructing a chroot environment, if you happen to have enough disk space. I'd also like to see that packet filter bug found and fixed. I went through the code but I couldn't find a smoking gun. On the driver front, NATA is still considered experimental and will not be the default for this release, so it doesn't need any serious testing until after the release cycle. I would like to make it the default for the 2.0 release 6 months from now. The network drivers all need testing. Both wireless and hard wired adapteres. Sepherosa has done a phenominal amount of work on the network front. GCC-4.1 is in the tree but it is not the default for this release and does not need to be tested. We will probably make 4.1 or 4.2 the default for the 2.0 release 6 months from now. So just don't worry about it for now. dhclient needs some testing, because none of the patches were being applied after we made the changes to the auto patch system months ago. I just fixed that a day or two ago. It seems to work on my test box. -Matt
Re: Release Schedule for 1.8
On Tue, January 2, 2007 1:11 pm, Matthew Dillon wrote: I would like to make it the default for the 2.0 release 6 months from now. Is it going to be 2.0 so that we don't have a 1.10, or are there other targets for that release? I was hoping (without any idea of feasibility) that 2.0 would mark the arrival of ZFS or the departure of the BGL.
Re: Release Schedule for 1.8
On Tuesday 02 January 2007 12:11, Matthew Dillon wrote: Well, my biggest issue for this release is that all the packages that compiled and ran on 1.6 also compile and run now. One thing I would like people with extra (test) machines to do is to do a clean install and then build their packages starting with a clean slate and see what problems pop up. Ok, I have a amd k7 3000 with a 36gb scsi hd and 1gig of mem. I'll be glad to volunteer it for a clean install. The question is should I download and build from a snapshot or do you want a full cvs build? I'll do a compile of kde and gnome, that should wring it out pretty good. Timothy
Re: Release Schedule for 1.8
:On Tue, January 2, 2007 1:11 pm, Matthew Dillon wrote: : I would like to make it the : default for the 2.0 release 6 months from now. : :Is it going to be 2.0 so that we don't have a 1.10, or are there other :targets for that release? I was hoping (without any idea of feasibility) :that 2.0 would mark the arrival of ZFS or the departure of the BGL. I don't want to have a 1.10. We'll see how much gets done in 6 months but it is going to be 2.0 regardless. -Matt Matthew Dillon [EMAIL PROTECTED]
Release Schedule for 1.8
* The CVS tree will be branched in two weeks, on Sunday, January 14th * The 1.8 release is slated for January 28th. I would like people to start testing release oriented bits if possible. We have about two weeks before the CVS tree is branched, and two weeks after it is branched for fine-tuning and package building. So if there are things you want to get into the 1.8 release but haven't gotten to yet, now is the time. -Matt
Re: Release Schedule for 1.8
On Mon, Jan 01, 2007 at 01:00:31PM -0800, Matthew Dillon wrote: * The CVS tree will be branched in two weeks, on Sunday, January 14th * The 1.8 release is slated for January 28th. I would like people to start testing release oriented bits if possible. We have about two weeks before the CVS tree is branched, and two weeks after it is branched for fine-tuning and package building. So if there are things you want to get into the 1.8 release but haven't gotten to yet, now is the time. What's the status of VKERNEL stuff? was one of the major things for this release. We are having a lot of problems with our IRQ routing code, i remember you proposing a solution for it some time ago, do you think that it's doable in time for the release? I wouldn't like to ship with stability problems and in my opinion we should delay the release until that is fixed. About testing, i think that we should start looking to do automated regression testing of the system as much as we can. TET[1] looks like a very good solution and FreeBSD is probably going to use it[2], so we could get a lot of regression tests for free that apply to DragonFly. [1]: http://tetworks.opengroup.org/ [2]: http://wikitest.freebsd.org/TetIntegration -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros.
Re: Release Schedule for 1.8
:What's the status of VKERNEL stuff? was one of the major things for :this release. I am going to try to get it done in 2 weeks. No guarentees. It can't hold up the release. But it won't be production for at least two months after that. e.g. we'll need to write a network driver and do some other bits to make it truely useful. Once I get the initial virtual kernel working I will impose on other developers to work on some drivers for it :-) :We are having a lot of problems with our IRQ routing code, i remember :you proposing a solution for it some time ago, do you think that it's :doable in time for the release? I wouldn't like to ship with stability :problems and in my opinion we should delay the release until that is :fixed. The IRQ issues are the same we've had since inception. i.e. no better and no worse then before. We have workarounds (build SMP without APIC_IO,and use the emergency interrupt poll sysctl). I don't think we can rush a solution in two weeks. :About testing, i think that we should start looking to do automated :regression testing of the system as much as we can. TET[1] looks like :a very good solution and FreeBSD is probably going to use it[2], so we :could get a lot of regression tests for free that apply to DragonFly. : :[1]: http://tetworks.opengroup.org/ :[2]: http://wikitest.freebsd.org/TetIntegration I dunno. I'm always skeptical about such frameworks and wonder whether porting them actually saves us any time over building our own. I do think testing will become a lot easier with the virtual kernel giving us a totally self contained environment for three files (kernel binary, memory image file, disk image file). -Matt Matthew Dillon [EMAIL PROTECTED]
Re: Release Schedule for 1.8
I would like people to start testing release oriented bits if possible. We have about two weeks before the CVS tree is branched, and two weeks after it is branched for fine-tuning and package building. So if there are things you want to get into the 1.8 release but haven't gotten to yet, now is the time. I'm hoping to have the [get|set|make|swap]context functions ported to DFly in time for the release. I have all the code bits in place (kernel, libc, libc_r) and am working on debugging right now. Regards, -- Matt Emmerton
Re: Release Schedule for 1.8
:About testing, i think that we should start looking to do automated :regression testing of the system as much as we can. TET[1] looks like :a very good solution and FreeBSD is probably going to use it[2], so we :could get a lot of regression tests for free that apply to DragonFly. : :[1]: http://tetworks.opengroup.org/ :[2]: http://wikitest.freebsd.org/TetIntegration I dunno. I'm always skeptical about such frameworks and wonder whether porting them actually saves us any time over building our own. I do think testing will become a lot easier with the virtual kernel giving us a totally self contained environment for three files (kernel binary, memory image file, disk image file). Just my 2 cents as a guy who wrote part of a test framework ages ago :) I agree with Matt, rolling your own is the best way to go - simply because it's very difficult to get hold of something that does everything that you want, and does it well. Far better to write your own test framework in Python or the like, and get away with it. It doesn't take a long time, and it's worth the effort. Is there someplace where there's a list of release-oriented code bits/features, so that people can pick off stuff that they're interested in testing? I'm moving to a different city/state in a week or so, so i'm not sure if I can contribute to any testing right away - but I'd like to take a look all the same. Cheers, K.
