coapp-developers team mailing list archive

[Vincent Povirk <madewokherd@xxxxxxxxx>]

Whoops, forgot to include the list just now. Sorry for the confusion.

> How do I do it?

I've explained this in my previous post, and you appear to have
understood. If there's something still unclear, please let me know.

>> (And I REALLY don't want to have to install
>> bzr or hg or perforce on my machine to update a package, EVER.)
>
> You don't have to if you don't want to.
> The option I described is only valid in case there is software
> hosted in Subversion which one wants to package for CoApp.

I do if I want to update a fork that YOU have published by converting
the history from bzr or hg, or if I want to fork an existing bzr or hg
project without offending someone. If I want to update one of your
forks from Subversion, I have to learn git-svn, instead of just having
to learn git.

My intention in listing requirements was to illustrate that all of
them can be satisfied by importing snapshots. They are also satisfied
by your approach.

> Indeed. That's why we need to host complete sources of upstream in
> revision-controlled system,
> in GitHub, with tags and branches from upstream.

We need to host the complete sources, but I don't see the need to host
the complete history. We only need to preserve enough of the structure
of the history that we can understand our own changes and use Git
effectively with them. I would argue that the individual patches in an
upstream project do not matter to us at all.

> Just look how Subversion workflow works.
> 1) trunk -> upstream, development
> 2) I want to release 1.0, feature freeze, make branches/1.0
> 3) I release, then I tag form branches/1.0 as tags/1.0.0
> 4) I have fix for 1.0, then I merge fix into trunk/ and into branches/1.0
> 5) I make bugfix release from branches/1.0 so I create tags/1.0.1
>
> If we have mirror of this SVN repo in GitHub, then we just release new
> package updated
> from tags/1.0.0 to tags/1.0.1. We don't have to maintain
> releases/version of upstream on our own.

Except that someone has to keep that mirror updated, which is a
different sort of work from the rest of it. Someone who understands
git can import only those tags, but can't necessarily update an svn
mirror.

AFAICT the only advantage for you is that you can automate the process
of updating the svn mirror, but updating another person's svn mirror
is harder. I've actually failed at updating a git-svn clone before,
and had to start over (which would be unacceptable for anything but a
private repo, as the resulting commits are different). I'm sure it was
fixable, but apparently I was not smart enough to fix it.

Cherry-picks from upstream may also be more convenient, but you should
be able to backport any change you need without Git's help.

>> That approach looks like this:
>>  * Create a new Git repository with a branch named 'upstream' (or
>> something like upstream-2.6 if we need to track multiple upstream
>> branches).
>>  * Download a tarball of a release of this project, dump the files in
>> the repository (without the project-version prefix they usually add),
>> and commit them.
>>  * Create a master branch based on the upstream branch, and do the
>> packaging work.
>>  * Create a repository in the coapp-packages organization containing
>> both the master and the upstream branch. You can have mirrors in your
>> own github account if that is how you like to use github. I won't
>> judge.
>
> If this workflow is sufficient to what we need, it makes sense.

I believe it is.

> Do we consider having -devel packages from development version of codes?
> I think it is important to be able to create CoApp packages for mylib-devel.

That would require updating more often, but one can certainly do that
with snapshots. It doesn't require having every point in the history,
just every point where you want to make a -devel package. Instead of
using a tarball, you would need to get the files from the project's
RCS.

> AFAIU, you are proposing Vendor Branches, aren't you?

I've never heard the term, but the description does sound like what
I'm proposing. I just saw the approach used elsewhere and thought it
made sense here.

> Basically, there are two common approaches to maintain thrid-party sources:
> 1) git svn
> 2) vendor branches made from release packages of third-party sources
>
> They are similar but slightly different: 1) preserves complete history
> and may make it
> easier to generate patches and contribute changes back to upstream.
> Thus, this is my preferred appraoch.

I don't think preserving complete upstream history is important, and I
don't understand how it makes it easier to generate a patch.

> My general point is, let's not reinvent the wheel for new workfllow.
> The problem we are trying to solve is an old one, well-solved
> and developers are familiar with solutions. It is like with design patterns.
> If CoApp uses common approach, it will be easier for contributors to adapt.

I think we agree on most of it, and it is only on the use of git-svn
that we differ. I think git-svn (and any other automated tool that
converts complete history to git) adds unnecessary complexity and
shouldn't be used.