[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEP-2: Debian Package Maintenance Hub

On Sat, Jan 28, 2012 at 03:18:51PM +0100, Raphael Hertzog wrote:
> 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.

Well, this "distribution wide statistics" and the todo list below formed
together in my mind. I'd like this new interface to know about release
goals for instance. It should thus be possible to a) list packages that
need handling, b) list the goal on the package's page, c) produce a
stats page about it, possibly including comments. I admit, it's rather
unspecific. No idea how it would work or even look like.

> > 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.

Yes, that way my main point. It should be possible to add comments to,
well, a lot, particularly packages. And it should be easy.

(This was always a show-stopper when I thought about proposing such web
interface. I don't know how UDD would deal with such quick write
attempts given its load with batched writes it has now already. Anyways.
That's "just" a matter of implementation. :))

> > 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.

I would like DPMH to show, I don't know, VCS stats or recent activity or
whatever. If anyhow possible, scanning recent commit messages for bug
number would be nice. This is definitely something DPMH could be
extended by later, though.

For MIA purposes it's always a good idea to check VCS activity. Not all
maintainers tell bug reporters about their progress (or even their
starting to work). Agagin, this is not to be done as a first step. I was
just throwing it in...

> > 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.

It'd need transition time anyways. I'm curious though how many places
would need fixing if we decided to drop those fields. Anyways, I get the
idea and I support it. If we ever get to the day when all packages in
Debian have 'Maintainer: source@pkgmaint.debian.org', then we can still
see if we can get rid of it.

(Paul's thoughts about DMUA are interesting here.)

> > 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.

Ack. Again, I wanted it to be thrown into the brain storming area.

> > 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).

Alright. I just thought it might be interesting to use this for other
purposes like MIA work. Having roles from db.d.o being made available
would make this easier. But then, maybe all this changes anyways. I
agree we should keep it simple for now. (SSO would still be nice :))

> > 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.

Full ack.

Thank you for considering my ideas and thoughts!


PS: I'm subscribed to -qa, no CC needed.

 .''`.   Jan Hauke Rahm <jhr@debian.org>               www.jhr-online.de
: :'  :  Debian Developer                                 www.debian.org
`. `'`   Member of the Linux Foundation                    www.linux.com
  `-     Fellow of the Free Software Foundation Europe      www.fsfe.org

Attachment: signature.asc
Description: Digital signature

Reply to: