On 06/12/2018 19:37, Justin Ross wrote:
> Hey, Daniel. Thanks for reaching out about this. We'd love to have a more
> up to date Debian package.
>
> Some questions:
>
> On Thu, Dec 6, 2018 at 1:59 AM Daniel Pocock <[email protected]> wrote:
>
>>> I notice that nobody has contributed to the repository[1] maintained in
>>> Debian and it may be easier to maintain the debian/sid branch in the
>>> main qpid-proton repository[2]
>>
>
> Out of curiosity, what is it that makes it easier to maintain in the Proton
> tree, versus at Debian? Is it a question of access for you? I ask because
> my own practice is to keep Fedora packaging metadata at Fedora, on the idea
> that the metadata is more closely bound to the target OS than it is to
> Proton.
>
> It's not a hard and fast rule. We do sometimes have stuff like
> distro-specific init scripts in the tree.
>
> If we do end up having it in the Proton tree, I propose we place it at
> <project-root>/packaging/debian. That's the pattern we have used for some
> other Qpid components.
>
There is a major difference between Debian and Fedora:
- Fedora tends to have a single spec file
- Debian requires a group of files and they always have to be in a
directory debian/*
Notice that what I do with other projects (e.g. reSIProcate) is create a
Git branch for each Debian build. So the debian/* directory is not
present at all in the master branch. Here are branch names I use:
debian/sid
- for building unstable packages
debian/stretch-backports
- for building packages for the current stable release
(code name: stretch)
Those branches never get merged back into master.
Another difference with Fedora is that Fedora builds are done on
Fedora's build servers and those repositories only contain spec files (I
maintain some packages there too) whereas Debian official builds are
made on the developer's personal machine, at least for one platform and
then Debian servers build the binaries for other platforms. So for
Fedora it is essential to use their Git service but for Debian, it isn't
even obligatory to use Git or any VCS at all.
Some benefits of having this branch in the main qpid-proton repo:
- easier for people using ASF workflow to make changes to the branch
- the packaging is a little bit more visible to everybody upstream
- upstream developers can very quickly test package build before making
a release tag, simply make a branch off debian/sid and then merge the
latest master into it.
- people who want to contribute to the package don't need to register
for an extra account on salsa.debian.org
Notice that I have already been working this way, I simply pull from
upstream master, merge the tag into debian/sid and push that branch to
Salsa. The alternative I'm proposing is to push the branch back to the
same place where master is maintained.
As mentioned earlier, one of the main motives for this is that nobody
has been contributing to the fork I set up in Debian.
>
>>> Would you be happy to accept me as a committer in the project so I can
>>> push the branch and any future changes there? I only intend to commit
>>> on the branch and within the debian/ subdirectory.
>>
>
> I have a counteroffer ;). Would you be willing to work by pull request for
> a period of time? Once we have a record of your contributions, we can
> consider you for committership. This is generally how the Qpid community
> vets potential new committers.
>
That is fine, I'm happy to start with pull requests
>
>>> Debian will freeze for the next release very soon so I'm keen to ensure
>>> the package is well organized before that.
>>
>
> It would really be awesome to have your contribution here. I want to clear
> away obstacles if I can.
>
An important step at this stage is for people to test the packages and
open bug reports for anything unusual, whether it is just a missing man
page, a missing header file or something more dire. It is much easier
to fix stuff like that before the freeze.
On 10/12/2018 12:29, Robbie Gemmell wrote:
> Separately however, a more pressing issue is that the existing debian/
> content in the linked repo is noted as being GPLv2 and so isn't
> currently permissively licensed for inclusion.
I'm happy to relicense my contributions there
Regards,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
