ports/75551: [PATCH] Correct a 'post-patch' entry in the port's Makefile since a files/patch-* seems to do the same thing.

Ion-Mihai Tetcu itetcu at people.tecnik93.com
Tue Dec 28 19:31:21 UTC 2004


On Tue, 28 Dec 2004 20:16:17 +0100
Pav Lucistnik <pav at FreeBSD.org> wrote:

> Ion-Mihai Tetcu pí¹e v út 28. 12. 2004 v 21:11 +0200:
> > On Tue, 28 Dec 2004 16:59:38 GMT
> > Pav Lucistnik <pav at FreeBSD.org> wrote:
> > 
> > > Synopsis: [PATCH] Correct a 'post-patch' entry in the port's Makefile since a files/patch-* seems to do the same thing.
> > > 
> > > State-Changed-From-To: open->closed
> > > State-Changed-By: pav
> > > State-Changed-When: Tue Dec 28 16:59:05 GMT 2004
> > > State-Changed-Why: 
> > > Maintainer promised to integrate this patch into his next update.
> > 
> > Pav, why is the state "close" more appropriate that analyzed ?
> > I mean I could forget about them ;)
> 
> First, I trust you that you will not forget about them.
> 
> Second, I fear that those PRs would be forgotten in analyzed state once
> the port is updated and the matter settled. So I rather closed them.

I try not to forget to say about the PRs that should be closed when my
PRs supersede them.

> > > (Bottom line here is that you should approach maintainer directly,
> > > without the detour via send-pr)
> > 
> > For two stylistic ones yes, but for the dir permissions (75549) and
> > "UntrustedDeliveryAgent" and "QuarantineAgent  (75548), I tend to
> > believe a pr is OK.
> 
> Always, always, always, when there is an active maintainer around,
> direct contact with a maintainer is strongly preferred.
> 
> It's really an ugly habit to send-pr patch and Cc maintainer.

Better that send pr and not cc the maintainer, anyway.

> First, a lot of maintainers don't know how to act properly on such
> emails, they just don't Cc their replies back to GNATS.

I think the problem is that the subj, must begin with
FreeBSD-gnats-submit at FreeBSD.org or else it becomes a 'misfiled' reply.
Only cc'ing seems not to be enough.

> And in last row, it creates a lot of administrative overhead for us,
> committers.

True.


-- 
IOnut
Unregistered ;) FreeBSD "user"




More information about the freebsd-ports-bugs mailing list