Adding support for the new Sourceforge trackers (Allura)

[Sandro Tosi]

On Mon, Oct 19, 2015 at 10:29 AM, Olivier Berger
<olivier.berger at telecom-sudparis.eu> wrote:
> 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.

sorry it sounded harsher than it should have been, it was late evening
yday and eventually it came out poorly, again apologies.

>> * 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 ?

that makes sense, sure, dunno if this is there right time tho: do you
think it would be just possible to add the allura remote without
handling the redirections? at least at first

>> * 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.

indeed they are not that many:
https://forge-allura.apache.org/p/allura/wiki/Allura%20Deployments/
but still better to have it ready to be used as soon as other projects
pick it up

>> 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 ?).

naah, I think the right way is to throw away all of that and rebuild
it, I have some ideas, just lack the time to prototyping it, maybe in
the coming weeks ;)

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi