Re: Working with gbp and older releases
> > I am trying to work on an orphaned package maradns. It uses quite a
> > lot of patches managed with quilt. I created a repo on alioth [1] to
> > manage different versions. I imported all the versions (debsnap and
> > git-import-dscs). Now I am stuck with two problems:
>
> Thanks for adopting and your contribution to Debian!
Frankly I am still thinking about adopting. It is a great software, I
use it quite often but while adopting I came to a few disturbing facts.
The first is the fact that upstream stated on [1] as follows:
"It would require some large company or government agency paying me a
full-time living wage to add significant new features to MaraDNS.
Since this is unlikely to happen, especially in today's economy, I am
declaring MaraDNS finished: While I will still fix important security
bugs in MaraDNS, and will probably still fix other critical bugs, I
currently have no plans to add new features to MaraDNS."
Additionally, his mail signature gives makes me doubt that his
commitment to his open source project is full, as in [2].
"Note: I do not answer MaraDNS (including Deadwood) support requests
sent by private email without being compensated for my time. A MaraDNS
support request is any and all discussion you may wish to have about
MaraDNS in private email; if you want to email me to talk about
MaraDNS then, yes, that is a support request. I will discuss rates if
you want this kind of support. Thank you for your understanding."
Also I can see that the package has plenty of patches that could be
forwarded to the upstream but for some reason were not forwarded or
accepted. I will try to contact the former mainatainer and upstream to
be 100% clear on that.
I have little experience what should be done in such a case, maybe I
have too high expectations on upstream.
>
> > 1. Should I keep the source unpatched in git or patched. If I keep it
> > unpatched, after patching (dquilt push -a) gbp complains that I have
> > uncommited changes. What should be done here?
>
> The patches should not be applied.
> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.building.html#GBP.BUILDING.PATCH
> should give you hints.
Thank you.
>
> > 2. I can see the newest maradns 2.X branch was installed only for
> > experimental. The latest in unstable/testing was 1.4.12-5. It is now
> > unusable, due to [2] and procpidfile change. I think the first release
> > I would make is fixing this, so people can use it again (now it does
> > not start). Is this git workflow correct ?
>
> If you want to adopt you're free to do so. But you can also start with
> the new upstream version if you think it is ready for primetime.
>
I think I will start. The former maintainer had builds of the new
branch in experimental, I already prepared a package with the newest
upstream version.
>
> > I will checkout debian/1.4.15-5 tag, bump the changelog to 1.4.15-6,
> > make changes in d/* and release with a new tag. Now, say I want to
> > release the new 2.X version. I go back to master, add the changelog
> > entry for 1.4.15-6 and work on the new release?
>
> Otherwise please explain your intentions...
>
For now, let's forget about it. Releasing the newest upstream is the
proper solution as you said.
>
> PS: You should change bug's title #739084 to ITA: .... and set yourself as
> owner of it
I sent the email changing O to ITA, it has not been yet processed I
think.
>
> >
> >
> > [1] http://anonscm.debian.org/gitweb/?p=collab-maint/maradns.git
> > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709826
> >
[1] https://github.com/samboy/MaraDNS#maradns-future
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573970#10
--
Pozdrawiam,
Dariusz Dwornikowski, Assistant
Institute of Computing Science, Poznań University of Technology
www.cs.put.poznan.pl/ddwornikowski/
room 2.7.2 BTiCW | tel. +48 61 665 29 41
Reply to: