[Debian-ha-maintainers] Packaging workflow

Richard B Winters rik at mmogp.com
Tue Apr 14 19:01:19 UTC 2015


Hi Everyone,

I was asking in IRC (formorer and Myon), and thought I might want to
just share it, so we can all be on the same page in the end.  I'll start
with my question(s).


My biggest confusion is the packaging work-flow. The repository
structure is no problem, but I need to understand how it is supposed to
be utilized.  Here is how the work-flow is as I perceive it, I'd really
appreciate it if someone could confirm - or straighten me out.


Notes on Building the Initial Repository:

I created an empty repository.

I did not import a tarball, because I literally setup an upstream
remote, and pulled clusterlabs master into a new upstream branch (yes
there still wasn't even a master yet). I then reset (hard) our upstream
branch to the commit used for the 0.17.1 release by clusterlabs. I
thought to tag this, since it was not a tarball import; hence no tag was
automagically generated for us. From this point forward, when a new
release comes out we simply checkout upstream, pull, reset to the commit
of the next release and tag it.

I then merged said upstream branch into a branch called 'master'. This
is the base.

Since the package was already created by myself and improved upon by
Feri. Patches existed thanks to Feri's improvements. When I restructured
the repository, the patches were ofc already there, so I did an import
on them to get them into separate commits under the patch-queue branch;
which we can easily send to upstream - where they can cherry-pick to
their hearts content.

Also, I was careful to commit each of Feri's debian/* changes atop of my
previous debian/* state, on to the debian branch. When the updates were
done I then merged debian into master so I could apply said patches and
test the build. I intend to create child branches for debian (i.e. sid,
exp, jessie, etc) - however for the time being and for testing purposes
I have had no need to do that quite yet.

I had already manually created the changelog entry - so for this first
go I opt to do it by hand (updating the format as Feri suggested though
for multi-author changes). Going forward I'll utilize git-dch

The next steps - in my mind - are to build and test, and if the package
is ready to go; tag it for the release its meant for and upload it to
mentors and ping you guys/gals.

I would rinse and repeat for each release (debian release) that we're
packaging for, tagging each.

Afterwards the workflow in my mind going forward would then be (some
repetitiveness here):

1. Git pull from upstream into upstream branch, and git reset --hard to
the commit used for the next release.
2. Switch to debian/<one of exp,sid,jessie,bp> branch and make updates
that you can without patches.
3. Switch to Master and Merge debian/* into master.
4. Create patches (into patch-queue).
5. Switch to debian branch and export patches
6. Run git-dch
7. Switch to Master and merge debian
8. Build
9. Repeat any necessary steps
10. Upload to mentors and ping, or perhaps not even necessary?
11. Rinse and repeat for each debian release.


Some notes:

- When I used git-import method to start up the last packaging
repository, it created this same basic branch structure that I'm waiting
with before continuing to expand upon; and merged debian into master so
I could build. It used a tarball for upstream. It is my impression that
using a pristine-tar branch when using an upstream repo as our upstream
branch -  there is a tool which can create the pristine-tar for us
automatically from the commit, without us having to import any tarballs.



Some feedback and/or straightening out, would be so helpful to me; other
than this the packaging work is done, I only have to fix the changelog
as Feri suggested for multi-author use - and stick to git-dch in the
future.


Please advise,



-- 
Rik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-ha-maintainers/attachments/20150414/270e31ce/attachment-0001.sig>


More information about the Debian-ha-maintainers mailing list