Question about "what to do if mantainer is absent"
kevin at scrye.com
Tue May 14 20:29:00 UTC 2013
On Tue, 14 May 2013 18:32:14 +0000
"Jóhann B. Guðmundsson" <johannbg at gmail.com> wrote:
> Oh Fesco is only busy but the rest of the community is not omg let me
> not waste your holy time sir...
I did not say you were not busy, just that it's pretty clear that fesco
> > I have no idea what you mean by imap folder here.
> Components get's their own email address <component>-maint@
> <mailto:systemd-maint at redhat.com>fedoraproject.org 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.
I don't think this would scale very well. We would need to run some
kind of massive imap server and over time packages like the kernel or
ones that get large patches would grow massively.
Why not let each person manage emails in whatever way they wish as
> >> 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 down?
To be more verbose, why does having a fedora imap server help you with
this problem? If you don't see any posts from a maintainer that still
doesn't mean that they aren't doing other things related to the package
and are still very much alive. I don't see your proposal as helping
this in any way.
> My plea what plea I asked Fesco to give this a serious thought about
> this and they did not.
Well, I can't speak for anyone but myself, but you will need to put
forth some kind of compelling argument. So far I have not been
IMHO, it's not on FESCo to convince you that we shouldn't change. It's
on you to present a compelling argument as to why we should change a
process that many think is working fine.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the devel