Question about "what to do if mantainer is absent"

"Jóhann B. Guðmundsson" johannbg at
Tue May 14 18:32:14 UTC 2013

On 05/14/2013 05:45 PM, Kevin Fenzi wrote:
> On Tue, 14 May 2013 17:13:54 +0000
> "Jóhann B. Guðmundsson" <johannbg at> wrote:
>> On 05/14/2013 01:51 PM, Simone Caronni wrote:
>>> I have a question about the unresponsive mantainer policy [1].
>> The unresponsive maintainers policy is to be honest crap and to much
>> in favor of the maintainer.
>> Fesco allegedly was looking into it but you know...
> Yeah, I sure do know... Fesco folks are busy and doing lots of things
> in the areas they contribute to, so if people really want to move things
> forward, perhaps they should work on some ideas themselves?

Oh Fesco is only busy but the rest of the community is not omg let me 
not waste your holy time sir...

>> What really is needed here is to drop the user ownership module
>> altogether and allow every contribute access to every component or
>> use group ownership model on components instead followed by an email
>> address component at fedoraproject which is the components email address
>> and is stored in a imap folder.
> There's a number of problems with 'free for all' model. Mostly around
> communication.
> pkgdb2 is being worked on that does some good toward teams/groups of
> maintainers for a package (there's no 'owner' anymore, just a 'initial
> bugzilla contact'). I'll let the folks working on that speak to that
> tho.
> I have no idea what you mean by imap folder here.

Components get's their own email address <component>-maint@ 
<mailto:systemd-maint at> followed by 
components being always assigned to that email address.

Each "mail" the component receives is stored in the components "imap 
folder" which contributors maintaining the component subscribed ( and 
anyone else for that matter ( like users that usually CC themselves on 
components ) that is interested in that mail ) can subscribe to.

>> Contributes could easily be added or allowed to add themselves to
>> components group and subscribed to the components imap folder in the
>> process which yields far more and faster access to start participate
>> and contributing then the current implemented model does.
> Do you mean 'initialcc' on bugs? or ?
>> Atleast you would not have to run around half the internet chasing
>> the maintainer just to try to see if he's active or not and if you
>> can fix or generally start working on the component he's allegedly
>> supposed to be maintaining
> Why not?

Why not what?

Do you get paid for or do you have endless time to spend hunting people 

>> If efficiency was Fedora's strong suit FPC would have been dismantled
>> by now...
> This is unlikely to happen, so repeating your plea isn't likely to help
> any.

My plea what plea I asked Fesco to give this a serious thought about 
this and they did not.

 From my point of view it is as unlikely to happen as you with your 
playbook idea or Tom with his "improving the fedora user experience with 
design driven methodology" which is just totally backwards from my pov.

If Fesco can explain to me the benefits of having FPC and the overhead 
it follows vs proposed changes to the packaging guidelines to the 
packaging list followed by an ack/nack/patch approach has I'm all ears I 
have only experience the downside of having it first hand and when I see 
a inefficient process in the project I try to improve and dropping FPC 
and adopting the previous mentioned model seems assured win win to me.

Heck the community did not have the faintest idea which tickets they 
even worked ( or did any work at all )  on until I literally request 
they adopted the fesco model so we atleast could get a faint idea what 
was going to be discussed on those meeting...

Let's just continue to cross finger hope that those that have been 
chosen <-- yeah that's right not elected but chosen bother to show up to 
do their due diligence and reach a quorum.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list