[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Pkg-haskell-commits] [SCM] Haskell binding to libmagic branch, master, updated. debian/1.0.8-1-3-gb0ffdb2

On Thu, Dec 03, 2009 at 08:52:31AM +1100, Erik de Castro Lopo wrote:
Joachim Breitner wrote:

Thanks, both are uploaded.

Thanks Joachim.

The hslogger Debian packages has (and had before) differences in
the .diff.gz that do not sound Debian-specific:

$ diffstat ../hslogger_1.0.8-3.diff.gz


I guess this is an artefact from the fact that these packages used to be
native package. With the next upstream release we should try to not have
any non debian/-changes in the .diff.gz

I think it may also be related to the way they are maintained in Git,
with the upstream sources in Git alongside the debian specific stuff.

It's not any inherent failure of git maintenance. git-buildpackage takes the difference between the 'master' and 'upstream' branches and uses this to generate the diff.gz. In this package there appears to be changes made in 'master' to files outside debian/. I don't know why they were made here (or why I don't seem to be able to find 1.0.8 in the wild). Probably, as Joachim says, an artefact of the package being native in the past. I cleaned up the upstream branch (re-imported the orig tarball), but some differences remain. Hopefully the next upstream release will not have these problems.

Personally I found this a real pain (git and I have our differences)
in comparison to working in Darcs with only the debian directory in
revision control.

I find the opposite - the tools for working with git-maintained packages are mature and robust, and make my life very easy. I'm happy to help you and anyone else get to grips with git maintenance on IRC. (I agree that the documentation is baroque and impenetrable). pristine-tar and git-buildpackage are excellent tools. In comparison, working with Darcs ---
especially when doing things such as new upstream releases --- feels far more
fragile. Consider that we had to bake some scripts to check out packages in a reasonably workable state.

But this obviously is all subjective. Use the tools you prefer.

Whats the policy with this? Is it still either Darcs or Git or should
we standardize on Darcs?

I would rather let people use the tools they are most comfortable with, so long as we don't end up working across every VCS under the sun (we should all be comfortable working on all team maintained packages) :).


Attachment: signature.asc
Description: Digital signature

Reply to: