Re: [Caml-list] Re: [OSR] Ports-like package management system

[Berke Durak <berke.durak@exalead.com>]

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