Re: I'll be rolling a 4.1.1 release on September 25th
Peter Radcliffe wrote: However, I don't know who the committers are, Read the handbook if you really want to know... or where they hang out. [EMAIL PROTECTED] -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
ds1 pcm and fxp suspend/resume bugs (was Re: I'll be rolling a 4.1.1 release on September 25th)
On Sat, Sep 16, 2000 at 06:07:37PM -0400, Peter Radcliffe wrote: Jordan Hubbard [EMAIL PROTECTED] probably said: standard configuration, I'll be rolling a network-only patch release to 4.1 called 4.1.1. If you therefore have anything to MFC, please do the following: Can we _please_ get these two patches into at least -stable before or after this release cut ? Many of us have been using them for months and they make the built in ether and sound work through a suspend/resume on my laptop; http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18756 http://www.freebsd.org/cgi/query-pr.cgi?pr=20255 cameron grant committed an alternate (and cleaner) fix based on PR 20891 to -current for the yamaha ds1 pcm suspend/resume problem a couple weeks ago. here's the commit message: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=399173+0+archive/2000/cvs-all/2903.cvs-all i just got around to patching this into my -stable system earlier today, and while there are some minor issues (stuttering during suspend, suspend/resume stops xmms), it's a big step in the right direction: the audio device is usable after a resume. presumably this will be mfc-ed eventually. i'll write up a more detailed report (i.e. a patch) for those minor problems hopefully within the next few days, if nobody beats me to it... the fxp fix (PR 18756), on the other hand, has gone nowhere. david greenman expressed concern about one bit of the patch (see the PR for details), then disappeared. i've sent him a couple messages (on may 22, also in the PR, and again august 26th in private mail) asking if he had any advice on how to fix the fix, but i've gotten no response. i saw a message on cvs-all a few days ago suggesting that he had "resigned in a huff a few months ago", so perhaps this got orphaned then? more importantly, maybe somebody on this list can help? briefly: after a suspend/resume on some sony laptops, the fxp device needs to have certain PCI registers reset, notably including the memory mapped base address registers. in several places the fxp driver issues a command, then busy-waits on a DMA indicating completion. if such a command is issued before the base address registers have been reprogrammed, the kernel will wait forever for a DMA that'll never occur. CSR_READs will hang the kernel similarly. the patch in PR 18756 does several things, mostly based on ideas from the netbsd and linux drivers: - saves and restores sufficient PCI registers across suspend/resume. - adds timeouts to DMA busy-waits. - attempts to avoid handling interrupts before the device has been resumed, to prevent hanging on the CSR_READ at the top of fxp_intr(). it's the latter that DG thought might be a problem. the intent (and effect, at least on my sony z505hs) was to protect against shared interrupts delivered before the device is resumed. on my machine, the fxp and uhci devices share irq 9. if the uhci controller is resumed and generates an irq before the fxp device is resumed, the fxp_intr() routine is also called and the machine freezes. i wouldn't be at all surprised if there were a better approach than simply ignoring interrupts when the device isn't running, but it's not clear to me what that would be. if anybody has any suggestions as to how to clean this up, i'm all ears. alternately, if any committers want to take this on, that'd be swell too. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: I'll be rolling a 4.1.1 release on September 25th
On Sat, 16 Sep 2000, Garance A Drosihn wrote: Poeple often pop up right before a release is due to be rolled, and ask for some patch to "make it into the release" - often it doesn't, and they go away until the next release is announced. This isn't how the FreeBSD development model works, and you're targetting the wrong group at the wrong time. You need to get your patch applied to *FreeBSD-CURRENT* preferably a month or more before the release, and then get it merged back to -stable. You left out the exact steps on how someone who does not have commit privs is supposed to "get their patch applied". I, for one, have found that process frustrating. Someone writes a PR, including a patch, and often the PR just sits there. It is up to the same person to find some committer, and pursue that person until they have time to apply the update. The most obvious person for a given piece may be swamped at the time, at which point the patch-writer has to go around hounding other people. Those other people, in turn, will feel uncomfortable because they're not familiar with that area of code -- and besides, they're already busy with other code that they already know. The patch-writer tries writing messages to public mailing lists. They try to be polite. They try do stir up some interest. They hope that someone somewhere will pick up the patch and apply it. This is a fairly accurate assessment of the usual way this goes. Unfortunately the existing FreeBSD committers as a group don't seem to do much work with code submitted via PRs, except for PRs which fall within a specific person's area of responsibility (at least, this is my impression) - in other words, we don't have many people who take care of all of the "miscellaneous" PRs. I fully understand it makes it annoying and frustrating for submitters, but I don't know what the solution for non-committers is except for cornering and working closely with an individual committer and making them promise to take care of it - if you just submit and forget, it's not likely to have swift results. The problem is that when we get a new committer, they invariably become tied to a particular area of the tree after some length of time which takes up all of their attention, and the net result is that PRs which are in areas where no committers have their attention focussed have noone to champion them. After spending ten times more effort trying to get someone to apply the patch than was originally spent MAKING the patch, they give up. Yes :-( FreeBSD always needs more committers. Traditionally the way you get committer status is to work with an existing committer in some area of the system, and once they've seen you've "got what it takes" (i.e. ability to work with the impact of changes on an OS-wide level) they'll be able to sponsor you to -core and be able to stand up for your competence. A release is announced. They get a bit excited, and hope once again to get someone interested. They are then told that they are "not following the FreeBSD development model". As near as I can tell, the "freebsd development model" is that either you yourself are a committer, or that you pray to the deity of your choice that a miracle happens. Well, it's a simple fact that patches don't get freshly applied to -stable without maturation in -current. Given that it can be difficult to get minor changes applied, then following this path and sending mail to a non-developer group at release time is a misdirection of effort. Given that it is clear that writing a PR is insufficient to getting a patch applied to current, I suggest that the reply to any PR which includes a patch should also detail what the remaining steps are. Who *is* someone supposed to bug? What *are* they supposed to do when the "obvious someone" honestly is too busy to look at their PR? If this is "the wrong group" at "the wrong time", then what is the RIGHT group, and at exactly WHAT time will that group not be frantically busy with other work to do? The appropriate "development" mailing list, either -current, -net, -alpha, etc. The time is any time, although away from the release cycle there are more committers who aren't tied up doing release work so chances are higher. So, let me add a disclaimer here. I realize the committers are busy. Fine. But don't just dismiss someone who sent in the PR as if they weren't following some obvious set of rules, and thus it is their own fault that it takes years to get a reply to a PR. The PR's aren't answered because there's still more work to do than there are people to do it. Period. It wasn't intended to be dismissive - but since this is something which I see repeated around the time of most releases I wanted to point out to people why it doesn't work. Do not kid yourself, and insult the rest of us, by claiming that if we just wrote one more message to "the right place", then PR's which include patches might
Re: I'll be rolling a 4.1.1 release on September 25th
Kris Kennaway [EMAIL PROTECTED] probably said: My point was that you need to either ask one of the committers directly, or ask in a forum where the committerss hang out. Thats not -stable - there are only a few of us here, so asking here is almost akin to asking in a vacuum. Ok, some partly useful information. However, I don't know who the committers are, or where they hang out. 5) I know how the system works, but it requires someone to commit the patches and no one will. Works for you..they have to go through -current first in case they break I was talking about the committing system, not my computer system. I know how the committing system is supposed to work and it going through -current first. I'm not a raving newbie, please don't treat me like one. Reply-To: [EMAIL PROTECTED] Mail-Followup-To: [EMAIL PROTECTED] So your MTA should take one or the other, not both. My question still stands, can these patches get in, somewhere ? You're still talking to the wrong list. You're still not giving me any information on which list to talk to or what else to do. I don't run -current, so I don't read freebsd-current. I run -stable. Around the 2.1.* era I spent time working on things, this problem is one of the reasons why I never bother developing or tracking down problems that don't directly impact me - even if I do, that information can sit in a PR for years and never be touched. Once something is in a PR, that needs to be looked at by someone with the ability to say "yes, this is good and should be committed to current" or "this needs some work or could be done better" or "this isn't appropriate". This often doesn't happen (even allowing for the volunteer nature of the project) and IMO is impacting the project negatively. P. -- pir [EMAIL PROTECTED][EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: I'll be rolling a 4.1.1 release on September 25th
On Sat, Sep 16, 2000 at 08:30:50PM -0700, Kris Kennaway wrote: FreeBSD always needs more committers. Traditionally the way you get committer status is to work with an existing committer in some area of the system, and once they've seen you've "got what it takes" (i.e. ability to work with the impact of changes on an OS-wide level) they'll be able to sponsor you to -core and be able to stand up for your competence. In Kris's case, he was just too big a pain in the ass and I had to figure out some way to make him stop bothering me. ;- -- Bill Fumerola - Network Architect, BOFH / Chimes, Inc. [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: I'll be rolling a 4.1.1 release on September 25th
At 6:19 PM -0700 9/16/00, Kris Kennaway wrote: On Sat, 16 Sep 2000, Peter Radcliffe wrote: Kris Kennaway [EMAIL PROTECTED] probably said: On Sat, 16 Sep 2000, Peter Radcliffe wrote: Can we _please_ get these two patches into at least -stable before or after this release cut ? Poeple often pop up right before a release is due to be rolled, and ask for some patch to "make it into the release" - often it doesn't, and they go away until the next release is announced. This isn't how the FreeBSD development model works, and you're targetting the wrong group at the wrong time. Let me note that there are two discussions going on in this thread, right in the above paragraphs. Peter is asking about a specific set of updates. Kris is (at least partially) responding to a general topic. "Speaking to the audience", instead of the individual who brought up a question. (I have done this in the past myself, in comp.sys.next newsgroups, and generated much confusion in the process...) Sorry for being short, but I'm on my way out. 1) they're not my patches, but they're useful to me. 2) I didn't specificly ask for them to make it into this release, I said "before or after". 3) I've asked before and go no response. 4) I can't commit things to -current. My point was that you need to either ask one of the committers directly, or ask in a forum where the committerss hang out. That's not -stable - there are only a few of us here, so asking here is almost akin to asking in a vacuum. Again, Peter is making it even more explicit that he is wondering about a specific set of patches. From various comments in this thread, it seems these patches have been brought up in several contexts over many months. I think Kris needs to say "I don't know about this specific set of updates", lest more confusion result. 5) I know how the system works, but it requires someone to commit the patches and no one will. Works for you..they have to go through -current first in case they break for someone else. Assume he meant "I know how the freebsd development model is supposed to work, but what is a person to do if they do not have commit access and can not seem to get anyone's attention?" An explicit list of steps would be nice. "Send a message here. Wait one month. No reaction? Send a message to this other place". For the *specific* question, Peter seems pretty flexible about getting the updates in "before or after" the release, so ignore the deadline of 4.1.1 or even 4.2. Just list the steps in the "Freebsd development model". My question still stands, can these patches get in, somewhere ? You're still talking to the wrong list. And this still did not provide an answer, not to the specific question, nor for the "speech to the audience". Where do we find these mythical committers who have time? Here we all are, debating this topic on a saturday night. My guess is that we are all available right now because we're busy working on something that we didn't have time to finish during the normal work week. I still stay it boils down to a simple matter of too much work for too few people. That may be frustrating, but it is not as infuriating as implying that there is some magical "freebsd development model" which would always get patches-in-PR's incorporated if people would "just follow the steps". That only makes things worse for people who see their PR's sit around, because it seems like they must be getting deliberately snubbed, instead of just being too far down the list to look at. I think that's probably enough for me to say, at least for the weekend. I don't suppose anyone knows why my bpf devices aren't working for me, even though I *know* I had used them fine under freebsd at one point? Sigh. saturday nights --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
