Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

On 11/1/05, Junio C Hamano <junkio@cox.net> wrote:
> git-tla-import, git-cvs-import, git-svn-import, ...::
>         Importers, one per foreign SCMs.

I concur generally with the plan, except that I think we should wrap
the import/export scripts together(*). One-script-per-package is
pretty awkward, and yet the dependencies for a
git-export-import-scripts packages are going to be awful as they'll
often pull a whole raft of SCMs.

Hmmm.

Perhaps git-tla-glue, git-cvs-glue, git-svn-glue, where glue stands
for importers, exporters, tools, etc?

*- I'm starting to think that the script to replay git commits into
cvs that I posted last week (cleaned up patch coming soon)  should
follow the git-cvsimport convertion and be something along the lines
of git-cvsexportpatch, to be followed by git-cvsexport which would
automate discovering what patches need exporting and drive
git-cvsexportpatch.

> git-docs::
>         Generated documentation from Documentation hierarchy.
>
> git-core::
>         All the rest, plus man pages.  We could separate out
>         commit walkers if we wanted to, but I do not think that
>         is necessary.

git-gitk ;-)

> I am currently generating i386 RPMs and i386 debs myself but I
> am not particularly proud of the current setup.  I do not have
> an RPM based machine that I can install the result myself to
> test (which is what started this thread).  Since I am not a
> Debian developer (and I do not particularly wish to become one
> myself), the debs I generate will not be official anyway.
> Personally I'd be happier if I can just lose rpm and deb targets
> from the "upstream" Makefile (git-core.spec file and debian/
> subdirectory as well while we are at it), ask "packaging
> maintainers" to pull from kernel.org/ tree and do RPMs and Debs
> outside.

I'd say you can probably keep the current setup, and as distro
(format?) specific maintainers show up and start maintaining bits and
pieces, merge from them. git should make that easy ;-)

I'm not a DD -- but I'm on the 'NM queue' which means I'm in the
process of turning into one (delayed at the moment, but hapenning
soonish). Have a package in the archive, and a few sponsors who are
generally happy to upload my work. Would be happy to give it a go if
noone else steps up.

(Sebastian _did_ indicate interest, and fought a long, hard battle in
debian-devel about the naming of the git and cg utilities. I haven't
seen him around lately (last post:
http://marc.theaimsgroup.com/?l=git&m=112747921603277&w=2 ). May be on
holiday? CC'd)

> On the other hand, having the basic support for packagers in the
> upstream might be easier for port maintainers.  I honestly do
> not know.

I think it'd be easier for all people involved if each port/packjage
maintainer keeps a published repo and you merge from them. Patches
have higher visibility and easier path towards "upstream".   
Maintainers want to keep the delta between their package and upstream
to the bare minimum.

> One thing we could do without breaking much of the current
> arrangement is to have a team of people to help porting for
> major packaging formats (RPMs and Debs mostly but I know we have
> OpenBSD and Darwin people here too), and ask them to feed me the
> updates to rpm/deb/whatever target in the Makefile as needed.

That's another good strategy. I suspect that you can push work towards
maintainers, so they publish 2 branches: one of forupstream patches
and one of 'local' patches. They have to do that anyway ;-)

cheers,


martin
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html