Re: How to handle two repositories?
Miriam Ruiz wrote:
> 2008/5/31 Cyril Brulebois <kibi@debian.org>:
>> The first one implies a rather low learning curve, especially since
>> we've been doing the same with svn. That's also what I have been using
>> for all my packages for quite some time now (from graphviz.git's log,
>> looks like since Apr 2007), and I'm very happy with it.
>>
>> The second one means that one is stronger connected to the upstream
>> branch, and also means (I think) extra git skills to be done properly.
>> I've been thinking about it for pkg-games, but I'm still undecided
>> whether we should be giving it a shot, or whether we should just stick
>> to the "easy" one. Since I'm still in doubt, I think I would got for the
>> first layout, since I feel it's a safe bet.
>
> I'd go the the first layout you describe. We shouldn't forget that
> we're gonna keep two different repositories at once for a while, and
> the more similar they are, the easier for everyone.
>
> Any different suggestion from anyone?
I've been looking at the uqm packages towards pushing them, but
the patches are all inline in git (as with the second scenario
described). Extracting all of this to put into quilt is possible, but
a fair bit of work.
Additionally, there are alternate formats being considered for
packages (e.g. "Format: 3.0 (git)") which would expect the git archive
to be upstream-inclusive.
While I agree that there may be value in keeping things similar,
is it worth loss of package history to migrate patches from a git
repository already done the second way? Similarly, will we find the
transition to alternate packaging formats more difficult if we take
that route?
--
Emmet HIKORY
Reply to: