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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140218191951.ga19...@blackstar.cs.put.poznan.pl
