[pkg-bacula-devel] Starting up reviewing patches

[Luca Capello]

Hi Willem!

On Thu, 03 May 2012 16:35:26 +0200, Willem van den Akker wrote:
> Got all running.
> - downloaded the 5.0.3 package from Luca

Do you mean the one at the following location?

  <http://people.debian.org/~gismo/tmp/bacula>

Then, no need for it if you use (hint: you should) git-buildpackage on
the pkg-bacula Git repository:
  
  <https://honk.sigxcpu.org/piki/projects/git-buildpackage/>

Basically, I compiled everything with pbuilder (you could use cowbuilder
as well, but be aware of <http://bugs.debian.org/646477>) calling it via
git-buildpackage directly from the Git repository.  The _amd64.build
file on my people.debian.org space is the pbuilder output, similar to
the buildd output:

  <https://buildd.debian.org/status/package.php?p=bacula>

> - build it (got a more then a few lintian warnings and errors)

They are normal and I have not looked at them yet because I guess Hauke
fixed some of them already.

> - cloned the git pkg-bacula workspace
>
> Because the next steps are new for me, how can I proceed best? 
> Sorry for the basic question but this is my first debian project)
> - review a patch (first a simple one)

Please note that Hauke's patches are nothing more than Git commits from
the development (or development2) branches.

>   - is the description valid (bug number) ?

Those patches/commits without a bug number could simply be improvement
to the package, e.g. because of a new Debian Policy.

>   - can it be applied (quilt3) ?

The current bacula in Git is already "3.0 (quilt)"-compliant, which
means that when you build the package any changes to upstream sources
will be saved in a debian/patches/FILE.  Basically, one workflow is to
modify the upstream sources as much as you want, build the package and
then manually adding the information to the debian/patches/FILE:

  <http://dep.debian.net/deps/dep3/>

>   - can we rebuild the package?
>   - is the package still working?

The package must at least be rebuilt and checked with debdiff (included
in devscript, be aware that checking .dsc behaves differently than
checking .deb), with no other differences than the one described in the
patch/commit.

Testing the resulting binaries is a plus, but given the complexity of
Bacula we can not test everything.

>   - must it send upstream?

This should be in the corresponding bug as the 'upstream' tag.

>   - add to the change log

Please note that in this case there are different opinions: I prefer
detailed changes in the debian/changelog simply because the Git
repository will not end up in the Debian archive (only the resulting
.orig.tar.gz, .dsc and .debian.tar.gz).  What is important is to be able
to track each change.

> - then apply it to the git space
> - commit (with valid log description)
>
> The last 2 steps I cannot do. So send my results to the list?

You are now part of the pkg-bacula, you have write access to the Git
repository.

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-bacula-devel/attachments/20120503/471f5952/attachment.pgp>