Re: Introducing myself

2009-03-26 Thread James Westby
On Thu, 2009-03-26 at 18:40 +0100, martin f krafft wrote:
> Maybe the best way forward would be to abstract across
> SVN/Git/Bzr/Hg for the simple operations needed for package
> maintenance, and then to implement a tool like svn-bp for Debian,
> except that it uses the abstraction layer and can thus work with any
> repo type.

I'd note that bzr-builddeb is almost there already. Thanks to Jelmer and
bzr's abstractions it already works on svn checkouts (and when called
with a repository URI I guess), and as bzr-git and bzr-hg improve then
it will work for those as well. It also attempts to transparently pick
up the svn-buildpackage configuration, so it will work for the 
packages using mergeWithUpstream.

It may be that currently it wouldn't really satisfy users of SVN, as it
has been written so that those who prefer bzr can use it, but that's 
fixable.

bzr may be a larger abstraction interface than you would like, but it's
available now, so it may be good for prototyping at the very least.

Thanks,

James


___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss


Re: Introducing myself

2009-03-26 Thread martin f krafft
also sprach Jan Hauke Rahm  [2009.03.24.1153 +0100]:
> After some thinking I started implementing a Repository class as an
> intelligent wrapper around SVN::Client (OOP in perl is weird by the
> way).

… don't get me started. :)

> Writing a new VCS based packaging helper does not make any sense
> without considering current efforts in abstracting things. And
> basically that's why I'm here now: I don't want to write a tool
> that's about to be replaced anyways any time soon.
> 
> So, how far have you come by now? Is it worth putting energy in
> vcs-pkg and is there any chance that we get a working replacement
> for svn-bp out of it before squeeze freezes? Otherwise I would
> have to concentrate more on svn-bp since it really needs a new
> version (it won't work with squeeze's archive because of Format
> 3.0 (quilt)!).

This is a hard question to answer. By comparison with svn-bp,
vcs-pkg has not really gotten anywhere yet: we do not have any
output in this sense. To date, vcs-pkg has mainly been discussions
and a commonly shared goal to unify package maintenance across
distributions and version control systems.

One nice output of this project would be something akin to svn-bp,
a tool that you run from a checkout, which does everything needed
for the distribution you asked it to. Part of the charm of this
approach is to be able to build packages for multiple distributions,
and encourage and facilitate exchange between distros.

I am very much of a bottom-up person, but I am unsure it's the right
approach in this situation. Look at svn-bp: it grew such that many
projects only track the ./debian directory; for many, this is now
a major showstopper in trying to migrate to distributed version
control. At the same time, svn-bp does not make use of branches,
probably because svn doesn't really know what a merge operation is,
and advocates tracking patches in version control. If you've ever
tried to debug one of those, you'll join me: Ugh!

I don't know what the vcs-pkg tool will look like or what it'll do,
because I only really know a few workflows used in Debian. From
brainstorming sessions at conferences, I know that other
distributions are essentially doing the same (after all, we all just
track changes to the upstream source to make the package work with
our distro), but I don't really know how the others do it.

There is also the question of whether a single vcs-pkg tool has any
future. It's going to be hard to design it, and we will all have to
work together, which is unlikely to happen within a short timeframe,
giving the limited time we all have.

Trying to standardise a single tool is kind of a wasted effort. But
trying to standardise interfaces is not.

Maybe the best way forward would be to abstract across
SVN/Git/Bzr/Hg for the simple operations needed for package
maintenance, and then to implement a tool like svn-bp for Debian,
except that it uses the abstraction layer and can thus work with any
repo type. Furthermore, maybe the tool could support different
workflows, e.g. support tracking patches in debian/patches alongside
TopGit-like functionality to track those features in proper
branches. This would allow people to use the tool for their existing
packages, and slowly move to other maintenance methods, without
having to migrate all the existing stuff.

Once such a tool works for Debian, maybe other distros will take
a look and see how it can be tweaked to their use-case. After all,
except for 'debian/patches' and the 'dpkg-buildpackage' command it
eventually calls, there's nothing inherently Debian-specific in any
of this. Maybe it'll be trivial for e.g. Fedora to use the tool
after exchanging those components with their own versions. And then
we could learn from each other and improve the tool.

I've probably nicely danced around your actual question, but maybe
what I've written can help a bit. If instead of working on svn-bp,
you'd be interested in helping to make the above happen, then
I think you should. I'll gladly assist wherever I can.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
the english take english for granted.
but if we explore its paradoxes,
we find that quicksand can work slowly.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss


Introducing myself

2009-03-24 Thread Jan Hauke Rahm
Hi everybody,

my name is Hauke (yes, I use my middle name for everyday talk) and I'm a
Debian Maintainer who's interested in this project.
Enough introduction? :)

Some time ago I started contributing to svn-buildpackage, a build helper
for Debian packages which are stored in subversion repositories.
Unfortunately it's quite buggy and needs some major re-engineering. When
I first brought up that point I felt like the contributors escaping --
obviously they don't want to make svn-bp better. OTOH that means I'm
almost free in what I'm doing about it. :)

After some thinking I started implementing a Repository class as an
intelligent wrapper around SVN::Client (OOP in perl is weird by the
way). It became more and more difficult and I already thought it could
go as a Google Summer of Code project but...

Writing a new VCS based packaging helper does not make any sense without
considering current efforts in abstracting things. And basically that's
why I'm here now: I don't want to write a tool that's about to be
replaced anyways any time soon.

So, how far have you come by now? Is it worth putting energy in vcs-pkg
and is there any chance that we get a working replacement for svn-bp out
of it before squeeze freezes? Otherwise I would have to concentrate more
on svn-bp since it really needs a new version (it won't work with
squeeze's archive because of Format 3.0 (quilt)!).

Hauke

PS: I'm thinking about attending debconf this year. If there were any
discussions about vcs-pkg it would be incitement. :)


signature.asc
Description: Digital signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss