----- Original Message ----- > From: "Jóhann B. Guðmundsson" <johannbg@xxxxxxxxx> > To: devel@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Friday, November 2, 2012 7:57:57 PM > Subject: Re: Revamping the non responsive maintainer process > > 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@xxxxxxxxx> wrote: > > > >> On 11/02/2012 04:25 PM, Tom Lane wrote: > >>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= > >>> <johannbg@xxxxxxxxx> 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? Wrong. Do you know how few of the problems we see in Eclipse land don't need fixes upstreams? And some of these issues require man/months (years sometimes) upstream before there is smth to show in Fedora. Don't make your assumptions based on that. So if one logs in every few months to take a look at the number of bugs (nothing more) he is active but one that does fixes upstream for months before putting into Fedora is not. You see there is no black and white here! Plus, did you intentionally skipped the part about being active on A but not on B ? So if one does a good job of maintaining 9 packages but doesn't do it for 1 because he/she is overloaded we should dump him? And please don't tell me that a good maintainer would not do that because many of us don't know the count(not the names) of the things they are responsible for so it's more than easier for a component to goes unnoticed. All of this was to show that whatever policy might be chosen it should be PER PROJECT/PACKAGE not per maintainer. Do you know what happens when someone as I described is currently overloaded and one dares to start the inactive maintainer procedure for him? I can tell you - for one unmaintained package, we lose a number of others that he/she maintained in a decent state. There was such a case recently for an on and off contributor who did *a lot* in the years, so when we say we want to learn from mistakes let's not do it by making bigger ones. Alexander Kurtakov Red Hat Eclipse team > > 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 > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
