> > 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 -- 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/20140217195248.ga11...@blackstar.cs.put.poznan.pl
