Subject: Re: CVS commit: pkgsrc
To: None <tech-pkg@NetBSD.org>
From: None <firstname.lastname@example.org>
Date: 01/13/2006 00:35:51
[replied to tech-pkg, for wider audience]
On Thu, Jan 12, 2006 at 03:10:54PM -0800, Jeremy C. Reed wrote:
> On Thu, 12 Jan 2006, Joerg Sonnenberger wrote:
> > Fix build of boost on DragonFly.
> I reported about boost problems on DragonFly to some boost developers back
> in August. I was told (in August) that some DragonFly fixes were committed
> then and that they would be available in version 1.33.1.
> I see we are running 1.33.0. The 1.33.1 version I now see was released on
> December 5.
> I don't know if that is related to your fixes or not (because I didn't
I didn't know that 1.33.1 was out or that it had changes in this area
applied. From a fast diff of the two versions, most of it is still
> This may help you because maybe some of the fixes may have already be
> done. And this may help other pkgsrc developers who update packages
> because they may have to recreate the patches. Coordinating with the
> MAINTAINERs may be a good idea just in case they are already in process of
> updating a package.
I *normally* try to contact the maintainer first, at least for more
disruptive changes. If I didn't do that and doesn't want to merge the
changes or simply can't do that easily, I don't mind if they are
reverted and I get a notification.
> Also, it would be good if all these code improvements were submitted
> upstream. That way other pkgsrc developers (or maintainers) do not have to
> recreate the patches again.
For larger, obviously active projects I normally either ask the
maintainer (prefered :-)) or try to find the upstream contact myself.
This is a bit tedious, especially when changing many packages. Just
consider the usual process of "finding home page, create bug tracker
account, submit patch" and that for packages which are often not or only
very seldomly updated. It is my hope that maintainers and updaters can
help both in this process, either by seeing the change and submitting it
upstream when sensible, or by reviewing the local changes on update and
submitting those which are still there.