From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29350 invoked by alias); 11 Sep 2003 13:38:26 -0000 Mailing-List: contact rhdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: rhdb-owner@sources.redhat.com Received: (qmail 29329 invoked from network); 11 Sep 2003 13:38:25 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 11 Sep 2003 13:38:25 -0000 Received: from redhat.com (totem.toronto.redhat.com [172.16.14.242]) by touchme.toronto.redhat.com (Postfix) with ESMTP id AE0B2800348; Thu, 11 Sep 2003 09:38:24 -0400 (EDT) Message-ID: <3F607AD0.7050009@redhat.com> Date: Thu, 11 Sep 2003 13:38:00 -0000 From: Fernando Nasser Organization: Red Hat , Inc. - Toronto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Bowen Cc: rhdb@sources.redhat.com Subject: Re: rh-postgresql in Taroon References: <1063249082.14632.10.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-q3/txt/msg00012.txt.bz2 Peter Bowen wrote:> The rh-pgsql.patch in rh-postgresql-7.3.4-2.src.rpm in almost 175,000 > lines long. It appears much of this patch simply makes changes to > CVS/RCS keyword lines. Has there been any thought of trying to break > this patch out into individual patches, similar to other patches to > packages? > Hi Peter, We maintain, test and release our own version of the PostgreSQL database (thus the 'rh-' prefix). Our version lives in a CVS repository where development occurs, merges between changes in the community version are checked in, conflicts solved, etc. The big patch represents what is different between the Red Hat Edition of PostgreSQL and the community release and obtained by a diff of their tar ball and of our release branch. As the CVS repositories are different, the keyword lines differ. We did attempt to eliminate those with patterns for analysis but that is not safe enough for production purposes (the patterns are not *that* specific). We could try to find a point where the changes are at minimum, create a diff, and from that point on collect a numbered set of additional patches. However, a patch would have to be generated for every check in, for every merge, etc. It would require some tight control and frequently verification that the sum of patches indeed produces the release branch tip etc. And I forgot to mention that we may have development branches for specific projects. We just don't have the man-power for implementing this level of control in a reliable way. An alternative would be to just use our release branch sources with no patches. Would that be preferable? Regards, Fernando -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9