On Mon, 10 Dec 2018 at 11:44, Daniel Pocock <[email protected]> wrote: > > > > 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. >
For me this is major reason not to include the resulting content in the main proton repository and further indication it should at least partly be maintained independently (wherever that may be) as its essentially separate from the proton release itself and simply uses it. If the commits, and all the related branches/tags for specific debian releases/packages that then result, aren't actually building toward output in/as proton source releases (which is what we as a project release and distribute and direct users to per foundation policy) then it doesnt seem like it should actually be in the main proton repo. It could be referred to in the main repo, perhaps even be utilised there (e.g in testing scripts), or steps maintained there to help generate initial required output for use with a particular release, but it doesnt seem like the related output and branches+tags etc should actually live in the main proton repo. > 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. Related to earlier comments above, visibility, creation, and utilisation are things I think can perhaps be addressed in other ways, but are not me reason themselves to include the essentially independent resulting output and branches/tags in the main repo. > > As mentioned earlier, one of the main motives for this is that nobody > has been contributing to the fork I set up in Debian. > Your original mail in this thread is the first instance I could spot in my mail history of this being referred to on a qpid mailing list, so I think that could that be as much a part of any awareness issues as anything? > > > >>> 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 > Great! > Regards, > > Daniel > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
