Re: Working with gbp and older releases
Hallo Darius,
Am Montag, den 17.02.2014, 20:52 +0100 schrieb Dariusz Dwornikowski:
> > > 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.
Well, IMHO it's legitimate for upstream to call a program "feature
complete" and mature. I think also it is not against the sprit of open
source to only add features if being paid, its basically a business
model decision one has to make (and not everyone does coding just as a
hobby). One still have all freedoms opens source gives you, also to fork
if desired.
Of course, declaring a software "mature" marks a distinct point in the
life cycle of the software toward its end, and eventually it might be
wise at some point in the future to depreciate the package and call for
its removal. But at a popcorn of around 100, and with the statement that
upstream does at least care so much to handle security issues, I think
this is needs not to be now, especially if the package is actively
maintained (soon). and sd upstream just released a new version, their
statement to fix security updates seems not to be empty.
If the patches are not Debian-specific, I would not hesitate to forward
them to upstream and leave it up to upstream to include them or not,
even despite the statement. Some upstreams will be happy to include,
from others you won't even hear any feedback... But at least you should
try.
> >
> > > 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.
ACK. (Reading the upstreams' homepage, you should definitly go for the
latest version. The latest upstream fixes a local DoS.
As a side, please add all CVE-# which closes the new version into the
changelog, please follow the procedure as in [1]))
You should also to file a bug against maradns to document that the
current version has secuirty problemss with the CVE's
http://maradns.samiam.org/security.html has the list.
> >
> > > 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.
Great :) Again, thanks for your efforts,..
>
> >
> > >
> > >
> > > [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
>
[1]
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security
Reply to: