Date: Sun, 1 Oct 2000 11:29:44 +0200 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: security@FreeBSD.ORG Subject: Re: cvs commit: ports/mail/pine4 Makefile (fwd) Message-ID: <20001001112944.A5065@speedy.gsinet> In-Reply-To: <20000930234530.A18517@mithrandr.moria.org>; from nbm@mithrandr.moria.org on Sat, Sep 30, 2000 at 11:45:30PM %2B0200 References: <20000930160432.A15451@mithrandr.moria.org> <Pine.LNX.4.10.10009302333451.29650-100000@jamus.xpert.com> <20000930234530.A18517@mithrandr.moria.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 30, 2000 at 23:45 +0200, Neil Blakey-Milner wrote:
>
> On Sat 2000-09-30 (23:37), Roman Shterenzon wrote:
> >
> > I can give you an example: ipfilter in the FreeBSD.
> > It still doesn't have a startup script in /etc/rc*
> > And it's not because it doesn't exist - in fact there's
> > conf/20202, but nothing is being done with it.
I still see this as partially caused by me (the originator). But
after your feedback and proofreading I (finally) plan on replying
to the PR with a cleanup -- to collect all the essence in a
single message. That's what I hope makes this proposal easier to
review, judge, commit and MFC. :) It will happen in the next
week's beginning, when I have Darren's response (see below).
> I can't see how this was shot down. Darren just doesn't seem
> to have done anything about it. Reply to the PR, and ask if he
> still intends to do anything about it, and if he doesn't, then
> we can assign it to someone else.
That's what I've done yesterday (ask Darren about which form of
input makes the patch the most comfortable to handle), the reply
is still on its way. And I don't blame Darren for not committing
the patch yet. In the current form it's not very attractive or
easy to handle; and FreeBSD work probably has lower prio in his
busy job.
BTW: May I point to <20000915203531.E27034@speedy.gsinet>?
-------------------------------------------------------
Date: Fri, 15 Sep 2000 20:35:31 +0200
From: Gerhard Sittig <Gerhard.Sittig@gmx.net>
To: "freebsd-security@FreeBSD.ORG" <freebsd-security@FreeBSD.ORG>
Subject: Re: ipf logging
-------------------------------------------------------
Therein I asked this very question "What can *I* do to make it
better?" (i.e. reduce reluctance or reasons for ignoring the PR
without baffling anyone and thus making things worse) -- there
was no response. But I guess it was due to its being buried in
another thread.
> While it would be nice if developers regularly chased up things
> assigned to other developers and left for a while, it's best
> for the originator or stakeholders to actually _say_ something
> about it _in the PR_ and to the relevant lists if things go by
> too long.
When Darren cannot or won't act after the next f'up within a
couple of weeks I will step up with the request to have the PR
assigned to some other committer. Since it doesn't deal with
ipf's internals but "only" invokes utilities in the startup
scripts I don't see a problem with this. It's not about changing
architecture or topology. It's not about forcing ipfw users to
change. It's just about reducing conflicts for those utilizing
ipf in a FreeBSD environment. Until then everyone is free to
extend rc.network by himself (we're talking about admins here
able to take their own actions after deciding themselfes for a
tool).
And I'm very well aware of the fact that invoking send-pr doesn't
give any warranty about being heard or committed. But I would
like to get negative feedback as well if anyone sees a need for
objection. Up to now there was only positive feedback (and
silence:).
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001001112944.A5065>