[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Re: Team meeting today
From:       Mark <markg85 () gmail ! com>
Date:       2012-06-21 14:49:42
Message-ID: CAPd6JnGYHp8LvpBob0JJmAosK0HuHvWebo-pmU5ErWBjk7VR0Q () mail ! gmail ! com
[Download RAW message or body]

On Thu, Jun 21, 2012 at 3:03 PM, Martin Gr=E4=DFlin <mgraesslin@kde.org> wr=
ote:
> On Thursday 21 June 2012 14:47:36 Aaron J. Seigo wrote:
>> i can see having a list of maintainers for components that are "strongly
>> maintained" by an individual, such as the comics applet (to pick somethi=
ng
>> completely at random). but then ... using git i'd be able to figure that=
 out
>> immediately as well.
> I see a very good reason to do it:
> getting an overview of what actually has an active maintainer and which p=
arts
> of plasma are currently unmaintained (my translation of "community
> maintained"). For the areas which are unmaintained it is useful to try to
> attract new developers. Maybe someone wants to take care of e.g. the boun=
cing
> ball. So just for that reason I think it would be a good thing to do it o=
nce.
>
> The second reason I think that would be useful is to use the result to ad=
just
> the default assignee/cc list in bugzilla. Having people caring about "the=
ir"
> products inside Plasma would be something nice to have. One maintainer can
> much better get a look over the bugs he is responsible for than the compl=
ete
> community maintained approach.
>
> Apart from that I doubt that this list would be maintainable, but it would
> make sense in my opinion to do this as an inventary once a year or so.
>>
>> i can definitely understand wanting to have notation for who oversees wh=
ich
>> group of technologies: e.g. who is responsible for libplasma, for plasma=
 in
>> workspace and runtime (or which large parts of it...), for solid, for
>> networking, for power management, for window management and composition =
..
>> etc. that would be useful for understanding how the overall product spli=
ts
>> down into projects with team leadership.
>>
>> is that what we're looking for rather than a module-by-module break down=
 of
>> plasma?
> That's more useful for the main overview, yes. And could include important
> Plasma components like e.g. Battery Applet.
>
> Cheers
> Martin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

I'm not sure about this but someone with in depth git knowledge can
probably clarify on this. I think git has an option to at least show
which people commited to which file. If you simply do that for all of
plasma you get a list with people that have been committing to a
specific component. Now if you sort that list by date you filter out
the inactive ones (ones that haven't been active on that component for
a year or so) and done.

Now this won't give the maintainer or any status but it does give an
idea if a certain component is even maintained. Just a random thought
that could be helpful :)

Cheers,
Mark
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]