Re: Guidance required for GSoC project PTS rewrite in Django
On Fri, 26 Apr 2013, Paul Wise wrote:
> > On the contrary, I see the PTS evolving in something much more interactive
> > and dynamic. As an example of future extension (outside of the scope of
> > this GSOC), it would be nice if people could fill missing debtags directly
> > in the PTS and then package maintainers + DD could approve them. Or if
> > people could fill-in upstream metadata (upstream VCS, BTS, etc.) that we
> > don't want to store in debian/control currently.
>
> I expect this move will be unpopular, one of the members of DSA has
> already registered their disapproval in the other thread.
You will always find grumpy people when you try out new things. But
more dynamic doesn't necessarily mean less efficient and all the other
bad things that you might think about.
When the dynamic part happens on the client part with javascript (with
reasonable fallbacks for users without javascript), the impact is null
on the server side.
When the dynamic part is on a (HTML-based, not browser-based) tab loaded
on demand, the same is true. But it allows us to add useful new features.
> IIRC Enrico is planning to add ways for other folks to approve debtags changes.
That doesn't mean that debtags couldn't be more tightly integrated/coupled
in the PTS.
> The upstream metadata apart from homepage is stored in
> debian/upstream:
>
> http://wiki.debian.org/debian/upstream
> http://wiki.debian.org/UpstreamMetadata
> http://dep.debian.net/deps/dep12
That DEP is still in DRAFT stage and I don't particularly like the fact
that we abuse VCS and source package to track this information. It doesn't
allow easy collaboration with non-maintainers.
If the PTS provides an alternative implementation, and if it turns out to
be more convenient, what's the problem ? :-)
> Perhaps a hybrid approach is appropriate, distributed static files for
> information display and main site for modifications etc.
This is certainly something that can be considered. I'm still not convinced
with the fact that pre-generated static files are the way to go to build a
good fallback solution.
> > It's still interesting to authenticate people so that we can subscribe
> > them to packages more easily (for a better integration with the mail
> > part).
>
> Hmm, I suppose so.
Or to let people store some display preferences that can last longer
than a cookie. Etc.
> None of the user submission sites (debtags, screenshots, description
> translations, watch files) require logins and I suggest we continue
> that tradition if you want to move those to the PTS instead of having
> them on their own domains.
Certainly, I don't want to impose further restrictions when none were
deemed required. But I want to have the possibility to provide an enhanced
experience to users who have opted to register (or who have authenticated
with a pre-existing account, like DD have).
In general all those services are under-used and getting them more tightly
integrated in the PTS could fix this. It could also make it easier to
define a standard communication workflow between maintainers and all those
services.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
Reply to: