Date: Sun, 24 May 1998 14:13:03 +0100 From: njs3@doc.ic.ac.uk (Niall Smart) To: "Jordan K. Hubbard" <jkh@time.cdrom.com>, njs3@doc.ic.ac.uk (Niall Smart) Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Studded <Studded@san.rr.com>, ac199@hwcn.org, Ruslan Ermilov <ru@ucb.crimea.ua>, nick@foobar.org, freebsd-bugs@FreeBSD.ORG Subject: Re: Problem reports closed by Poul-Henning Kamp [was: Re: misc/6712] Message-ID: <E0ydaaG-0003BL-00@oak63.doc.ic.ac.uk> In-Reply-To: "Jordan K. Hubbard" <jkh@time.cdrom.com> "Re: Problem reports closed by Poul-Henning Kamp [was: Re: misc/6712]" (May 23, 1:14pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On May 23, 1:14pm, "Jordan K. Hubbard" wrote:
} Subject: Re: Problem reports closed by Poul-Henning Kamp [was: Re: misc/67
>
> > I have a better suggestion: don't commit fixes to either -stable or
> > -current unless you are prepared to commit to both. Obviously this rule
>
> But that model breaks down for a lot of situations. I don't want to
> encourage people to just slam-bam commit everything into -stable that
> goes into -current since it's:
>
> A) inappropriate in a number of cases (there are quite a few
> things which will NEVER be merged to -stable and should not be)
>
> B) not something which should happen until something has been
> TESTED in -current first.
Jordan, it looks like you hit reply upon reaching the first full stop in
the paragraph I wrote, I acknowledged explicitly in the next sentence
the two points which you repeat. My problem is not with the PR's which
fall into those two categories, but with the majority which don't.
There have been a large amount of patches which make low-risk changes to
the system utilities, or which address typos, ambiguities or obsoleteness
in documentation or code which have only been applied to -current.
These are the ones I'm concerned about, and all the following comments
refer to these type of PR's.
> Merging has to happen, yes, but in only a structured way which has
> committers willing to make notes to themselves about committing things
> into -stable after a suitable grace period and/or only when it's
> clearly suitable to -stable.
Yes, but this isn't happening, Poul is closing off PR's which apply to
both -current and -stable when the patch has been applied to -current
without any intention of fixing -stable at a later stage. Even worse,
because the PR's are closed its impossible for anyone else to keep track
of which PR's contain unapplied patches which are relevant to -stable.
A couple of weeks ago I sent in a patch for something or other which
should have gone into -current and -stable, Poul applied it to -current
and closed off the PR, when I emailed him asking to apply it to -stable
too he replied that he didn't work on -stable much anymore and that I
should go bug another committer, I think I ended up emailing you to get
it committed. It's Poul's decision as to whether he wants to spend his
time patching both -stable and -current (I think he should do both or
neither, see below) but it certainly shouldn't be left to the submitter
of the patch to chase people so the patch gets applied everywhere,
instead a new GNATS category should be created for any backlog of patches
which grow during Poul's PR auditing exorcise (misspelling intended ;)
The kind of PR's I'm talking about which fall into this category are the
recent update to /etc/services (in -current only), the recent update to
the Norweigen datedef file (in -current only), the important update to
ps that allows users to avoid paging in large processes to read argv and
environment, which that submitter (of -stable) claimed allowed him to save
20 megs on his busy boxes (in -current only). I don't think any of these
could be claimed to be either inappropriate or potentially destablising.
When neither A or B above apply there are good reasons to commit them to
-stable and -current at the same time. For these reasons I don't think a
policy of "apply to -current now, come back to -stable when someone gets
a chance" is a good one (i.e a "waiting for commiter" is preferable to
a "waiting for -stable commiter" category):
1) If they aren't committed to -stable then someone is going to have
to trawl through a list of PR's with patches which are appropriate
for both stable and current, but which have only been brought into
current. This involves reviewing (again) the correctness of the
patch, contacting the submitter (again) etc etc, all of which is a
waste of resources. Given the ease at which most patches can be
brought in to both tree's there is no excuse for doing one but not
the other. If this is the case then either apply to both, or
apply to neither and stick it in the "waiting for committer" category.
2) Needless inconsistencies between the behaviour of current and stable
systems arise; When configuration files such as /etc/services change
on only one system then you will have a network service listen on
one port on a -current system and on a different port on a -stable
system, this is obviously silly. Or, scripts created by the sysadm
will have to take into consideration that the date command prints
dates in one form in -current and another on -stable, or that ps
only takes certain flags etc etc.
3) A great deal, in fact from looking through the backlog I think a
majority, of patches are submitted by -stable users. If you don't
apply their patches, or worse, apply them to -current and not
-stable, then this source of bugfixes will dry up. I realise the
solution is a question of resources, however Daniel O'Callaghan
has recently volunteered to keep a look out in this area.
I should point out that I'm not criticising Poul's effort to clear
out all that gunk in GNATS, its just that sometimes he's throwing the
proverbial baby out with the bathwater.
Regards,
Niall
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0ydaaG-0003BL-00>