Re: hard-to-reach upstream. looking for advice
On 4/12/06, Yaroslav Halchenko <debian@onerussian.com> wrote:
> Dear DDs and DPMs (Debian Package Maintainers who might not be a DD)
>
> The problem is really is that original upstream author is hard (if
> possible at all to reach) -- there is no official webpage since
> mozilla.org rejected some recent version of it and upstream author
> didn't bother to proceed or smth like that, thus
> https://addons.mozilla.org/firefox/14/
> has only 1.0.1. I've tried to reach upstream via email but got no reply.
Then use others...
> There are few derivatives available
>
> 1. floating around "original" release from upstream 1.1.2 which is
> compatible with fresh firefox. (available from the website of 3 -- look
> below)
seems to be a dead end
> 2. Bookmarks Synchronizer 3 (https://addons.mozilla.org/firefox/1989/)
> which is merely a fix of 1.0.2 to make it work with FF 1.5
seems to be a hack
> 3. Bookmarks Synchronizer SE
> http://www.trasduzione.com/bmsync/ -- fork from 1.0.2, which now reached its
> own 1.1.8 version. It has multiple bug fixes and improvements. But also
> seems to be without any changes since 28 Jan 2006. I left multiple
> inquiries and sent emails to those authors, but got no reply (besides
> comments to my first question among the comments on
> http://www.trasduzione.com/bmsync/). Also they switched to another
> prefix in mozilla configuration parameters, thus anyone who will upgrade
> to bmsync SE will have to reenter their configuration -- should not be a
> big deal, since new prefix seems to be used by 1.1.2 from the original
> upstream anyways. Also probably a package name has to change to
> mozilla-bmsyncse which would be more appropriate
that is correct; make a package which should "Replaces:" the old
version and "Conflicts:" with it since I suspect they will oerlap and
there is no sense in keeping both; Also, you will need to create a
transitional package which is empty and shall depend on the new one;
the bad thing is that this new package will be new (it seems
reasonable to change the nameof the source package, thus will wait in
the NEW queue.
You should describe in the changelog that the replaces is done because
o dead upstream
> I am not sure which way I should proceed -- I really want to see that
> extension upgraded but absence of contact with upstream holds me away
> from simply choosing 1 or 3. 2 is just a hack on top of 1. so I would
> prefer to stay away from it.
>
> How usually people deal with such problems with upstream?
If neither of the upstreams is responsive, the you have 2 choises -
kill package and declare dead upstream or you become upstream.
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
Reply to: