Re: DEP-2: Debian Package Maintenance Hub
Hi,
On Fri, 27 Jan 2012, Jan Hauke Rahm wrote:
> I'd like this new interface to be able to produce distribution wide
> statistics regarding QA matters. I think this is covered by the
> proposal.
Can you elaborate?
I don't see any problem with this in theory, but your description is
rather vague.
> I'd like it to produce a distribution wide todo list. It should be
> possible to send a bored developer or new contributor to a generic place
> where they can find stuff to do. Given the idea of replacing O/RFH etc.
> and given that interaction with the BTS is needed anyways (may it be
> through UDD), this should be possible.
Yes, definitely. I have added a paragraph in "Goals" to explain this.
> Seeing someone looking at random problems, i.e. a random orphaned
> package, they should be able to leave a note within this system. It has
> to be possible to see that a package has just been touched/checked by
> someone else even if they didn't find anything to work on. For instance,
> a perfectly healthy orphaned package should be left with a note saying
> "I just had a look at it, looks good to me. $timestamp". It might even
> influence the result of the todo list I mentioned above.
Why not indeed. We already can leave "notes" in the PTS (they appear in
the "news" or "static news" section) but it's so painful to do that nobody
does it.
I agree if it's easy to enter something, we could see interesting uses of
it like you mention.
> I very much like the idea to join enough information for MIA purposes.
> Though it might be worth considering how to integrate information from
> VCSs.
I don't see the link between MIA and VCS.
> The proposal suggests to change all Maintainer fields to a generic
> value. I'm questioning the whole field if it contains a computable
> value.
We certainly don't want to drop it... and all the infrastructure uses it
to send mails (BTS, dak, etc.). So we rely on it.
> And what would the Uploader field hold?
Probably that we keep using it like now, we put there people who are
uploading the package. But it no longer serves as the canonical reference
of who is maintaining the package.
> Should all this information be kept out of the package and be held in a
> central database?
Well, the idea is certainly to have this information in this
infrastructure. Now whether it duplicates it or replaces it, remains to
be seen.
I would very much like to make this new infrastructure the canonical
reference whenever you have a package with source@pkgmaint.debian.org in
the Maintainer field.
> Given a new central source of information, should stuff like a watch
> file or even the Homepage field be moved out of the package into the
> database?
Probably not at the start. I agree it would be interesting to move this
kind of information out of the package where it can be updated
independently of any package release but there's enough to design
for now and we should concentrate on the core parts first.
> Authentication should ideally be done using db.d.o plus whatever is
> needed to allow non-DDs. Given the interest of teams like MIA or DAM,
> should the interface allow roles as specified in db.d.o? (Could the MIA
> db vanish and be instead put here?)
Authentication should not be done using db.debian.org unless DSA provides
some SSO or the like. I requested something like this long ago and they
refused to setup OpenID (even though I provided a working patch). I don't
know if they
I believe that a simple mail authentication should be enough. We know the
emails of the DD, if the person is able to read the mail of the DD, we
should be able to consider that he is the DD. Later if we have more
important operations handled through this infrastructure, we might want to
require some sort of authentication via GPG (the content of the mail might
be crypted, or similar).
> I don't want to over-complicate or over-think stuff. This was just
> random thoughts I had while reading DEP2. I'd like to discuss my ideas,
> obviously, and I think we should use this opportunity to re-think a lot.
It's good to think a lot about what we want to be able to do with it in
the future, at least to ensure we design it in a way that doesn't forbid
those things... but we should not be too ambitious at the start, because
otherwise we will never deliver anything.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
Reply to: