Re: Non-responsive maintainer: pocock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please excuse me going completely offtopic here - for some reason I'm getting this thread addressed directly to me. If someone's adding me as bcc please don't, I have nothing to do with this.

Thanks,
Radka
  

Radka Janeková (she/her)
.NET Core QE Lead, Red Hat
IRC: radka | Freenode: Rhea



On Fri, Feb 28, 2020 at 10:02 AM Ankur Sinha <sanjay.ankur@xxxxxxxxx> wrote:
On Thu, Feb 27, 2020 17:07:21 -0500, Dakota Williams via devel wrote:
> On 2/26/20 6:59 PM, Daniel Pocock wrote:
> <snip>
> > >
> > > Would you like help? I'd be willing to be a co-maintainer to make the
> > > branch.
> >
> > Yes, I would welcome help with these packages
> >
> > But there is also an increasing problem of making decisions about trust
> >
> > In the case of developers who I haven't met or worked with, I don't
> > really know how to proceed
> >
> > I've seen several extraordinary examples of developers doing things that
> > undermine my confidence in them over the last couple of years.  The
> > fighting within GNU and FSF right now is the latest iteration of that.
> >
> > Now, whenever I receive a request from somebody I don't know, there is
> > an extra effort for me to decide how to proceed.
> >
> > Maybe I can simply resign from maintaining the asio package and then opt
> > out of the process of choosing a new maintainer.
> >
> > Please don't take this personally: it is a reflection of the overall
> > state of free software communities today.
> >
> I don't know about the situation with the GNU project and the FSF, but if
> there's something you'd like me to do to prove trust, I could do it.

I'd like to add that by default we trust each other, in the spirit of
being excellent to each other. In this particular case,
co-maintainership shares responsibility but does not hand it over
completely (the handing-over bit can be done at a later stage, if
necessary). Every change/commit/message is public, so there are plenty
of opportunities to catch any errors.

Given that we do not often meet our Fedora colleagues in person, it is
not viable to expect members of the community to prove trustworthiness
through personal relationships. We assume the best in each other, and if
things do get hairy, we have open community channels, processes, and
overseeing bodies through which changes can be emended.

--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux