Bug#782677: udd: scripts/update-upstream-status: should consider sepwatch
On Sun, Jun 28, 2015 at 09:47:50PM +0200, Lucas Nussbaum wrote:
> Hi,
>
> On 28/06/15 at 09:08 +0000, Bart Martens wrote:
> > It already exists. We have cgi-bin/udd-dehs which reads from mole.watch. So I
> > don't know why scripts/update-upstream-status would even run uscan.
>
> Because the UDD implementation predates a working mole.watch.
Really?
> DEHS died,
> then there was nothing to replace it, and UDD's implementation was
> created. Then someone duplicated it in mole.
The implementation in mole was already there when I added watch-requeue and
sepwatch, and I've heard about the implementation in UDD only very recently.
>
> Given that the UDD implementation works, I have no interest in switching
> to mole's.
>
> I'm not sure who are the current users of the mole implementation,
The mole implementation feeds PTS and DDPO. What does the UDD implementation
feed?
> but
> it feels quite young to bet that it will be a better basis on the long
> run.
On the contrary, mole is quite old, only watch-requeue and sepwatch were added
recently.
>
> Also, even if I understand the problem that sepwatch is trying to solve
> (= provide a faster update path for some packaging metadata),
That's basically what sepwatch does.
> I think
> that this is a problem that should be addressed more globally, by
> centralizing that metadata somewhere managed by ftpmasters, in a way
> similar to what happens with overrides: the maintainer suggests a value,
> but it can be overriden. That way, upstream checkers won't even have to
> unpack source packages.
Well, the values from sepwatch override the values from the watch files in the
packages, so quite similar, just not by ftpmasters.
>
> However, if someone did the work to implement sepwatch in UDD's
> implementation, I would welcome the patch.
I'm not sure it's worth the effort, since the mole implementation with sepwatch
already feeds PTS and DDPO. Then again, I don't know why the UDD implementation
exists, see my question above.
Regards,
Bart Martens
Reply to: