kern/85503: panic: wrong dirclust using msdosfs in RELENG_6
yar at comp.chem.msu.su
Wed Sep 7 14:42:43 PDT 2005
On Wed, Sep 07, 2005 at 09:27:12AM -0700, David O'Brien wrote:
> On Wed, Sep 07, 2005 at 04:44:11PM +0400, Yar Tikhiy wrote:
> > On Wed, Sep 07, 2005 at 03:34:16AM -0700, David O'Brien wrote:
> > > On Mon, Sep 05, 2005 at 01:50:01PM +0300, Dmitry Pryanishnikov wrote:
> > > > ftp://external.atlantis.dp.ua/FreeBSD/PR/85503/msdosfs.patch
> > > >
> > > > problem has gone away. Please, if possible, review and commit it. I think
> > > > this
> > > > patch is a good MFC candidate for RELENG_6 and RELENG_6_0, since it
> > > > prevents panic in quite common environment.
> > >
> > > I've committed it to HEAD. It is up to the RE's to get it into RELENG_6.
> > David, I'm afraid there is certain misunderstanding here. First,
> > the RE team will hardly take care of getting the fix to RELENG_6
> > without your initiative.
> There is zero misunderstanding here. I'm not going to get into a public
> debate or fight over this. My experiences to date is that it is too much
> effort to get all but the most critical bug fixes into a frozen branch.
> Someone else may take up the MFC during the freeze cause.
> > Second, the PR kern/85503 shouldn't be
> > closed until the problem is fixed in all relevant branches: It
> > should be put in the "patched" state instead according to the
> > project's well-established policy. Thanks.
> I've been a FreeBSD committer for almost 10 years now - what you claim is
> "well established" isn't. When a patch from a PR is committed to head
> the PR may be closed. The new practice of some committers to change the
> state to patched is something some committers may like to do, but I
> don't. The same for the MFC reminder and statement in the commit message
> is also newer thing that some like to use, but I don't.
> When I am free to commit to a branch and I have the time to adequately
> test in the branch, I look for all the commits I've done to HEAD, I do a
> code merge them and MFC them.
Nevertheless the FreeBSD community still can rely on bugs being
fixed on frozen branches and PR's handled according to the Problem
Report Handling Guidelines, because it's among the project's current
best practice. IMHO it would be a real shame if people judged from
your, actually private, position that the opposite was true. Frankly,
this was the misunderstanding I was really afraid of.
More information about the freebsd-arch