Revamping the non responsive maintainer process

[Aleksandar Kurtakov]

Where is the community spirit? What went wrong with fedora community? Why on earth do you people insist on tracking people activity and not try detecting unmaintained packages?
Detecting unmaintained packages is even easier and has clearer metrics. 

Really, why noone wants people that are ready to do one thing in a year? Are many people here feeling superior than the rest of the world and think there is no need for further contributions and they can do everything alone ? I'm starting to be really worried for the path Fedora is going.

Alexander Kurtakov
Red Hat Eclipse team

----- Original Message -----
> From: "Vít Ondruch" <vondruch at redhat.com>
> To: devel at lists.fedoraproject.org
> Sent: Tuesday, November 6, 2012 10:28:11 AM
> Subject: Re: Revamping the non responsive maintainer process
> 
> Dne 5.11.2012 10:22, Marcela Mašláňová napsal(a):
> > On 11/02/2012 06:57 PM, "Jóhann B. Guðmundsson" wrote:
> >> On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
> >>> On Fri, 02 Nov 2012 16:44:06 +0000
> >>> "Jóhann B. Guðmundsson" <johannbg at gmail.com> wrote:
> >>>
> >>>> On 11/02/2012 04:25 PM, Tom Lane wrote:
> >>>>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
> >>>>> <johannbg at gmail.com> writes:
> >>>>>> On 11/02/2012 03:32 PM, Matthew Miller wrote:
> >>>>>>> On Fri, Nov 02, 2012 at 03:12:56PM +0000, "Jóhann B.
> >>>>>>> Guðmundsson" wrote:
> >>>>>>>> Dead/un-maintained packages need to be removed/reassigned at
> >>>>>>>> the
> >>>>>>>> very *beginning* of an new development cycle so feature
> >>>>>>>> owners
> >>>>>>>> and others working in the community are dealing with active
> >>>>>>>> and
> >>>>>>>> actively maintained packages.
> >>>>> How exactly are you going to force maintainers who go missing
> >>>>> to do
> >>>>> so at a prescheduled time?  Real life is seldom that
> >>>>> convenient.
> >>>> If at this point we dont have any process that can actively tell
> >>>> if a
> >>>> maintainer is present and active within the project then we have
> >>>> bigger fish to fry then the feature process...
> >>> If we have problem A and problem B, can't we work on both at the
> >>> same
> >>> time? :)
> >>>
> >>>> Seriously it should not be anymore complex than monitoring last
> >>>> login
> >>>> into the relevant infrastructure pieces to determine if the
> >>>> relevant
> >>>> maintainer is active or not.
> >>>>
> >>>> bash script + a cron job should suffice to achieve just that.
> >>> It's not at all that simple, I'm afraid.
> >>>
> >>> How long since last activity do you consider someone 'inactive' ?
> >>>
> >>> What if the packages that maintain simply don't need any changes?
> >>>
> >>> What if they are on vacation?
> >>>
> >>> What if they are active on package A, but not doing something on
> >>> package B that you wish they would?
> >>>
> >>> I've long wanted to revamp our process.
> >>> I welcome concrete proposals to do so.
> >>
> >>
> >> Surely if an individual has not logged into for several months
> >> into our
> >> infrastructure he must be inactive no?
> >>
> >> Bash script + a cron job that monitors login should suffice to
> >> check and
> >> even email him asking him to confirm if he is active encase he has
> >> a low
> >> maintenance component and only logs in when something is filed ;)
> >>
> >> JBG
> >
> > No, he can own only one package and be an upstream of the package,
> > therefore he will login only for update of the package.
> >
> > You are using your use-case for everyone. If you insist on
> > automatic
> > process, then the metric should work with more data.
> >
> > Marcela
> 
> Requiring action every 6 months, such as pressing button "Yes, I am
> still alive and kicking" in FAS after you are nagged by email, would
> be
> acceptable annoyance even for such package maintainers, wouldn't be?
> 
> And there is such script, which is checking user activity on several
> places: https://github.com/pypingou/fedora-active-user
> 
> Vit
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel