On 2015-05-03 15:31:28, Stefano Zacchiroli wrote: > On Sun, May 03, 2015 at 02:50:17PM +0200, Iustin Pop wrote: > > PS: Long-term, the current codebase needs some redoing - e.g. it uses > > cheetah as templating engine, and that's not available under Python 3, > > etc. > > I very much agree. This is why, from an idea coming from Lucas, I've > included in the scope of the upcoming GSoC work on Debsources [1] the > following: > > 2) a "patch tracker" web app to publish details about the source code > differences that Debian packages carry with respect to upstream > releases of the same software. > [...] > implement on top of Debsources a new web app, similar to the (now > defunct) patch tracker > > [1]: https://wiki.debian.org/SummerOfCode2015/Projects/Debsources%20as%20a%20Platform > > From an ecosystem point of view, Debsources already have both packed and > unpackages source packages, updated daily via push. On top of it adding > a tiny web skin that presents the patches is not much of a work --- in > comparison with the general infrastructure overhead of having a source > mirror, unpackaging it, etc etc. This is why I'm interested in giving a > try to recasting the old patch-tracker.d.o on top of sources.d.n (to > that end I've temporarily booked patches.d.n), rather than deploying > them as separate services. Makes a lot of sense, indeed. > OTOH, the patch-tracker.d.o code base already exists, and Debsources is > not yet a *.d.o service (mostly due to my lack of energy in doing the > migration, nothing else). So YMMV on what is the best course of action > for having back a web app exposing Debian patches w.r.t. upstream. My only goal is to have a patch tracker - I'm less concerned about how it is implemented, except that: > In terms of technologies, Debsources is both Python 2 and 3 (although > currently still deployed on Python 2), and Flask based. If you, or > anyone else, is motivated more on working on these technologies than in > modernizing the old patch-tracker.d.o code base, please come and talk to > me. To be honest, I'm not interested in working on any python code base long term. If I were to take on the old patch tracker, my second step after bringing the service up would be to rewrite (at least the web application) in a different language. I mentioned Cheetah/Python 2 only in the context that it can't stay like this for too long. So: - we could have the current patch tracker resurrected easily as a stop gap measure; not sure what the policies are around debian.org services, but from the point of view of just the patch tracker, probably about one weekend effort; or: - we could ignore the current patch tracker, since the GSoC will implement the same functionality anyway, just presenting the patches should be rather simple, and we're not in a hurry I'm fine either way… What do people think? thanks, iustin
Attachment:
signature.asc
Description: Digital signature