From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id E6D7DBC6C for ; Wed, 30 Jan 2008 15:24:22 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAI0XoEfAXQInh2dsb2JhbACQJwEBAQgKKZ8s X-IronPort-AV: E=Sophos;i="4.25,277,1199660400"; d="scan'208";a="8539248" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 Jan 2008 15:24:22 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0UEOI7P032230 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 30 Jan 2008 15:24:22 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABoXoEfBL1AZh2dsb2JhbACQJwEBAQgKKZ8t X-IronPort-AV: E=Sophos;i="4.25,277,1199660400"; d="scan'208";a="21980466" Received: from gw.exalead.com (HELO exalead.com) ([193.47.80.25]) by mail4-smtp-sop.national.inria.fr with ESMTP; 30 Jan 2008 15:24:21 +0100 Received: from [192.168.204.148] (madpc064.exalead.com [192.168.204.148]) (authenticated bits=0) by exalead.com (8.14.0/8.14.0) with ESMTP id m0UEOLpp021537; Wed, 30 Jan 2008 15:24:21 +0100 Message-ID: <47A08895.80301@exalead.com> Date: Wed, 30 Jan 2008 15:24:21 +0100 From: Berke Durak User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Sylvain Le Gall Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system References: <479F0664.2070706@exalead.com> <47A045C1.7030603@exalead.com> <47A05C59.2070900@exalead.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 47A08892.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; berke:01 durak:01 berke:01 durak:01 rework:01 merging:01 packager:01 bug:01 compile:01 caml-list:01 tree:02 module:03 patches:03 patches:03 commit:03 Sylvain Le Gall a écrit : > You are mixing software development and packaging. If you really want to > have something clean, you should avoid having changes into the source of > the upstream author (at least changes that should last). I want to combine development and packaging because packaging does not work well for developers. > Lets take an example: > * you commit source of project C, version V1 into your VCS > * you do everything required packaging, including some change to project > C to make it compile (changeset P1) > * upstream author publish project C, version V2 (changeset P2) between V1 > and V2 > * the changeset between P1 and P2 cannot merge > ... > > So what help do you get from your VCS here? You will have anyway to > rework it. The VCS manages changesets, assists you in merging, keeps a logged history, allows you to rollback, and so on. Quite useful. > Forcing a VCS is just a way to loose people who won't have access to > your VCS... I don't see a real advantage of doing it... Using a VCS as an infrastructure is not the same thing as forcing developers to use it. (See below). >> We are not forcing anyone to work using the selected VCS. We are just >> asking them to regularly publish their software to the VCS. If they >> directly work using the selected VCS, publishing commits will be easier >> for them - but they can still work on a day-to-day basis using their own >> VCS. >> > > Do they have to merge their changes with packager changes? In this case, > i really do think that upstream author won't publish their changes a > lot. If they are using VCS2 for working, they just have to commit their changeset to some VCS repository from time to time. This repository can be hosted by anyone. There won't be a mandatory central repository. Example 1: Alphonse uses Darcs to develop Nicemodule. He sets up a VCS repository (say, Mercurial, if we agree on mercurial) repository on his server. He adds the required opkg files in his source tree. Once in a while he commits Nicemodule to his Mercurial repository, but keeps working on Darcs. Bernard checks out the Mercurial and sends a patch P against the Mercurial version. Example 2: Alphonse doesn't want to use opkg or mercurial, but is the author of a really nice module Nicemodule. Bernard sets up a Mercurial repository where he imports Alphonse's Nicemodule and adds opkg information. Opkg users can then use Nicemodule by simply writing require(nicemodule). Bernard tracks Alphonse's source code and sends him back patches against his code. Example 3: Alphonse finally sees that using the same VCS as everyone else has more benefits than the extra niceness his preferred VCS has. His changes will be visible immediately in the Opkg system and he will be able to pull patches from his friends easily. He therefore uses Opkg and its associated VCS right from the start for his new project. When he has a new stable release, he simply tags it and adds a line in the release file. When Bernard starts developing a feature Y, he can directly pull Alphonse's changes and push back bug fixes. -- Berke DURAK