Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]

On Mon, Sep 10, 2018 at 06:23:52PM +0200, Daniel Vetter wrote:
>> Hm... For the purposes of cregit or repository hosting?
>
>For cregit integration. Tbh I don't even know how the current mailing
>lists hosted on freedesktop.org infrastructure are integrated into
>cregit. But I assume they are somehow, since that's were all the drm
>talk is happening. gitlab will also be hosted on fd.o infrastructure
>for us.

Cregit only considers LKML and the mainline tree -- at least right now.  
So, as long as all patches and discussions are cc'd to LKML, they will 
be within cregit's reach. I'm not sure there are any plans to look at 
any other lists at this point (I'm only very tangentially involved in 
cregit's development). Kate Stewart would be the right person to ask 
this.

>> That shouldn't be necessary in the near future. There is work under 
>> way for
>> patchwork to accept message-id based URLs, so using the
>> lkml.kernel.org/r/message-id URLs in commit messages should be enough for
>> cregit to provide a link to the relevant patchwork thread. We will also
>> probably end up integrating lore.kernel.org/patchwork with git in a way that
>> would associate patches with final commit-ids and auto-archive them. It's
>> not going to be 100% accurate for various reasons, but will at lest provide
>> more hooks for projects like cregit to provide extra details about git
>> commits.
>
>There's at least 4 forks of patchwork :-/ The one we have on fd.o has
>been doing this since ages. We added the Link: stuff so you can easily
>go from e.g. git log to the patch discussion, without a detour through
>google.

It's too bad that this hasn't percolated up to ozlabs, because I believe 
numeric-ID based patch links are actually harmful because they are 100% 
lossy.

-K

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]