Adding support for the new Sourceforge trackers (Allura)

Olivier Berger olivier.berger at telecom-sudparis.eu
Mon Oct 19 09:29:46 UTC 2015


Hi.

Sandro Tosi <morph at debian.org> writes:

> Hi Olivier,
>
> On Mon, Oct 12, 2015 at 9:26 PM, Olivier Berger
> <olivier.berger at telecom-sudparis.eu> wrote:
>> Hi.
>>
>> I think I've now some much better solution, which includes the new
>> AlluraTracker remote, for forwarded URL directly of the form
>> http://sourceforge.net/p/PROJECT/bugs/ID/, and the handling of redirects
>> between sourceforge2 urls and allura.
>>
>> I've pushed to the allura branch.
>>
>> I guess there are probably bugs or unnecessary bits, but I won't work on
>> it until tomorow (sleep, now if the babies permit ;)
>>
>> In the meantime, if you have some comments...
>
> honestly? the changes are horrible :(
>

Thanks for taking the time to have a look and comment.... however, I
feel a bit frightened by your tone... I guess thick skin and other
related discussions shouldn't be invoked to the present situation, but
still... Anyway, I don't mind too much, and you're right, I could have
done things better.

> * you changed a huge amount of code in critical areas, and there is
> absolutely no documentation at all on what you did, neither in the
> code nor in the commit message.

OK, will try to improve

> * wgotten is terrible, really, how do you come up with that? :)

Well, spawning wget in the first place sounds a bit horrible too
;-). Now, I needed to detect redirections happening between the old SF
trackers URLs and the newest Allura URLs, to try and divert to the new
handler. Should've added more docs.

Now, I'm considering replacing wget by another harvesting mechanism,
using native Python HTTP client, which could allow handling the
redirects or other matters (like caching / throttling, etc.) in a better
way. Will have to handle that separately from the SF/Allura stuff,
though. What do you think ?

> * allura is a new bug tracking system, the fact that SF decided to use
> it doesnt mean that they have to live together, so there's no good
> reason to keep it in the sourceforce remote

You're right, although I haven't detected another instance deployed
yet. I'll try to change that.

>
> I think that the addition of the allura remote and the support for the
> already explicitly forwarded to SF bugs to allura is enough for a
> first step

Yep.

>>>
>>> However, I'm wondering how to better integrate this in the bts-link
>>> architecture.
>
> eheh yeah this is one of the major problems with bts-link atm, it has
> a very unfriendly setup to add/manage remotes
>

I've started the btspull under debugging session (in Eclipse /
PyDev... another candidate env to suggest ?), and things became a bit
clearer, but the way the queue management is performed, and
instanciation of classes is generally a bit hard to follow. Maybe
Pythonic patterns I've gotten unused to, but still... Maybe worth
documenting somehow (diagrams ?).

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)



More information about the Bts-link-devel mailing list