Bug#582038: qa.debian.org: [PTS] Please link to UbuntuDiff
On 18/05/10 at 14:47 +0200, Mehdi Dogguy wrote:
> On 18/05/2010 13:46, Lucas Nussbaum wrote:
> >
> > UbuntuDiff does 3 things:
>
> … for now. It aims to be a proof of concept, not a final product. I'll add
> new feature to UbuntuDiff if people show some interest. I won't lose my
> time if it's to be used by 3 persons.
>
> > A) aggregate data about a set of packages selected by grep-dctrl
>
> "grep-dctrl" is not important here. Another "query interface" could be
> provided.
>
> > C) extract the changelog from the diff
> > => that's the main point we are interested in
> >
> > While I agree that (C) is a nice feature, it could go much further,
> > providing direct links to the patches in debian/patches, extracting
> > their description, etc. That's similar to what patch-tracker.debian.org
> > aims at doing. The problem is that we need a good script that parses the
> > diff and extracts the useful information.
> > That script could be used on patch-tracker.debian.org and patches.u.c.
> >
>
> I think that extracting patches from a debdiff is doable and not
> necessarily complicated. (I don't know for their description). It requires
> only "free time" :) But, that's planned. Did you actually read my last
> email? It says:
>
> >
> > I also have in mind to add¹ some features like: a
> > simple patch viewer, list of packages in Ubuntu and
> > not in Debian, etc…
> >
> > ¹: Any help is welcome if you {want to speed up the process,
> > are interested}.
>
> or I misunderstood your mail and shoud I take that for "I want to help"?
>
> Besides, each package listed in [1] has its own file in [2] which simply
> contains a div (whose "id" is the source pacakge) and can be used it in
> another web page.
>
> [1] http://ubuntudiff.debian.net/packages/list.txt
> [2] http://ubuntudiff.debian.net/packages/${source_package}.html
>
> maddie¹ is simple to use and extracting those html pages is as simple as
> running it with the option "-multi". There is no need for any
> configuration. You can put it in a cronjob and run it on qa.d.o if you
> have an idea about how to integrate those html bits.
>
> > Now, if we stuck to the changelog, it would be better to provide it as a
> > box that appears when the mouse cursor is over the Ubuntu patch (using
> > some cool javascript).
>
> IMHO, that's a bad idea. Sometimes[1], the text has more than 30 lines. I
> fail to see how you would display that in a "useful" way. But, if you want
> to implement that, it would take 3 lines of JavaScript.
>
> [1] http://ubuntudiff.debian.net/x/package/compiz
>
> > You don't really need a separate service for that.
>
> I think that you're wrong here. Having that script running on as a
> separate service allows me to develop it while having my hands completely
> free. Once someone finds a brillant idea how to integrate it, the service
> will be stopped. My goal is not to provide a new service, but a new
> information/tool for maintainers.
>
> ¹: the script that generates all what's on ubuntudiff
I agree that the information that you plan to provide is useful. What I
question is the best way to provide it.
Starting a separate service has many drawbacks, including a lot of
duplication of information, and the fact that people relying only on one
service will miss the information provided by other services.
That's why it sounds like a better design to have all the information
provided through the PTS (and possibly DDPO), or to replace the way
information is currently provided at external places (like patches.u.c).
What I fear is that we end up with the situation we have with build
logs, where we have 2 services that provide basically the same
information, but have never merged.
So, I think that linking to that external service now is a bad idea. But
I won't stop the PTS maintainers from doing it, of course.
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: