Re: Working with gbp and older releases
On wto, lut 18, 2014 at 07:46:53 +0100, Tobias Frost wrote:
> 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.
Ok.
>
> 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.
I think that maybe when we upgrade to latest branch, more people will
use it. Maybe that is the reason for a low popcon value.
>
> 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.
I have already contacted upstream, he is willing to accept patches
that have "spelling fix" character. Any other patch he puts in a
"patches/3rd-party" directory, so he did with our Debian patches.
>
> > >
> > > > 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]))
Thank you, I will do it.
>
> 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.
Ok.
>
> > >
> > > > 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
> >
> >
> [1]
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security
--
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: