coapp-developers team mailing list archive

[Mateusz Łoskot <mateusz@xxxxxxxxxx>]

2011/12/20 Vincent Povirk <madewokherd@xxxxxxxxx>:
>> 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.

I was typing my reply while reading, so later on I got it clarified indeed.

>> 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.

I agree with you on this.

My original opinion was biased by the fact that in most cases, I rely on
development version of projects I use. I usually pull source codes from
trunk/master upstreams directly.

This is not necessary for packaging.
Unless one wants to create -devel package, but that can be solved
separately from normal workflow.

>> 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.

Yes, true.

> 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.

It's hard to not to agree with you on this :)

> 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.

I have experienced similar issues myself too.

>>> 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.

OK, but...
IMO it is like Vendor Branches.
Could you take a look at the links I gave about Vendor Branches
and compare to your concept?
I know you have outlined the concept above, but you know your idea in
very details
so you may find important differences.
IMO, it's easier to base communication on known patterns, unless we
need to design
something different.

>> 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.

Yes.

>> 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.

OK, then I assume we both understand the workflow you proposed in the same way.

Simply put, I think we need to achieve something like this:

http://happygiraffe.net/blog/files/wordpress_vendor_branch.png

Picture taken from
http://happygiraffe.net/blog/2008/02/07/vendor-branches-in-git/

If my understanding is still wrong, would you mind to "visualise" the
idea with Git
commands to show complete workflow sessions for:
- initial import
- update cycle
- custom changes maintenance
- generate patch to port back to upstream

We need to document it anyway :)

>> 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,

Yes, I think so too.

>  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.

Yes.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net