Non-responsive maintainer: pocock

2020-02-24 Thread Dakota Williams via devel

Does anyone know how to contact maintainer pocock?

https://bugzilla.redhat.com/show_bug.cgi?id=1806708
https://bugzilla.redhat.com/show_bug.cgi?id=1790674

Thanks,
Dakota
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-19 Thread Daniel Pocock


On 15/03/2020 13:32, Neal Gompa wrote:
> On Fri, Mar 6, 2020 at 2:06 PM Dakota Williams
>  wrote:
>>
>> On 3/6/20 1:21 PM, Daniel Pocock wrote:
>>>
>>>
>>> On 05/03/2020 21:26, Julian Sikorski wrote:
>>>
 I would like to take this opportunity to remind about the PR that I have
 prepared - let us not duplicate the work:
 https://src.fedoraproject.org/rpms/asio/pull-request/1
 I have rebuilt all asio's dependencies and only encountered issues with
 abiword and OpenSceneGraph - both were complaining about error not being
 a member of asio::placeholders. Same issues were found by gentoo, I have
 linked the relevant bug reports in the PR. Is this something you would
 be able to advise about? I am happy to share full build logs if needed.
>>>
>>> I haven't personally looked at asio 1.14.0 yet so I don't have the
>>> solution off the top of my head.  These are the type of issues I
>>> normally deal with in upstream development.
>>>
>>>  From a strategic perspective, I feel it is most efficient to try and
>>> coordinate with the upstreams and other distributions so that everybody
>>> is supporting the same asio in each of the major distributions.
>>>
>>> In any C++ library, there are small API changes from time to time
>>> leading to the type of problem you describe.
>>>
>>> If upstreams are using travis-ci, we are testing against version 1.12.2
>>> from Debian/Ubuntu and may not be aware of issues in asio 1.14.0.  Even
>>> if you patch for the issue, it may be completely untested upstream.
>>> That is why it is so vital to resolve the Debian/Ubuntu lag.
>>>
>>> Is there a convenient way for upstreams to make CI builds on the latest
>>> Fedora rawhide in parallel with our travis-ci Ubuntu builds?
>>>
 Please also note that I have checked both fale and uwog's recent
 activity with fedora-active-user and neither seem to have been active
 lately.
>>>
>>> Thanks for this feedback.  Dakota, do you want to be promoted to admin
>>> on asio?
>>>
>>> Is either of you happy to be co-maintainer of resiprocate with me?  I
>>> opened an issue to unretire it.  I do upstream releases and I run the
>>> latest version for fedrtc.org (using CentOS/EPEL) so it is important for
>>> me that it supports Fedora and any Fedora issues are given the attention
>>> they deserve during the release process.
>>
>>
>> Sure, admin is ok with me. Co-maintainer of resiprocate would also be
>> something I'd be willing to take on.
> 
> It's been a couple of weeks now, and I don't see "raineforest" listed
> as admin for asio[1]. Can you please add him as requested?

I had added Dakota as developer (commit?) and when I looked tonight, I
notice he had vanished.  I've added him now as admin.  Is there any way
to see how he vanished?  Does he need to explicitly click something to
accept the permissions?


> Also, resiprocate[2] was retired three months ago after being orphaned
> for 6 weeks for failing to build for Fedora 31[3]. It will need to go
> through a whole new review process *after* asio is updated.

Is it possible to make Covid-19 exception for this and just put it back
again?  Lots of people want to use the WebRTC conferencing features.
Yesterday I updated[4] JSCommunicator and today I tweaked[5] resiprocate
for asio 1.14.0 so it is ready to go in Fedora, EPEL and fedrtc.org.  I
have a backlog of upstream issues in all these projects and would prefer
not to lose time in another review process.

> 
> [1]: https://src.fedoraproject.org/rpms/asio
> [2]: https://src.fedoraproject.org/rpms/resiprocate
> [3]: https://pagure.io/releng/issue/8917#comment-610267
> 

[4]: https://groups.google.com/forum/#!forum/jssip
[5]: https://github.com/resiprocate/resiprocate/commits/master
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-19 Thread Neal Gompa
On Thu, Mar 19, 2020 at 6:42 PM Daniel Pocock  wrote:
>
>
>
> On 15/03/2020 13:32, Neal Gompa wrote:
> > On Fri, Mar 6, 2020 at 2:06 PM Dakota Williams
> >  wrote:
> >>
> >> On 3/6/20 1:21 PM, Daniel Pocock wrote:
> >>>
> >>>
> >>> On 05/03/2020 21:26, Julian Sikorski wrote:
> >>>
>  I would like to take this opportunity to remind about the PR that I have
>  prepared - let us not duplicate the work:
>  https://src.fedoraproject.org/rpms/asio/pull-request/1
>  I have rebuilt all asio's dependencies and only encountered issues with
>  abiword and OpenSceneGraph - both were complaining about error not being
>  a member of asio::placeholders. Same issues were found by gentoo, I have
>  linked the relevant bug reports in the PR. Is this something you would
>  be able to advise about? I am happy to share full build logs if needed.
> >>>
> >>> I haven't personally looked at asio 1.14.0 yet so I don't have the
> >>> solution off the top of my head.  These are the type of issues I
> >>> normally deal with in upstream development.
> >>>
> >>>  From a strategic perspective, I feel it is most efficient to try and
> >>> coordinate with the upstreams and other distributions so that everybody
> >>> is supporting the same asio in each of the major distributions.
> >>>
> >>> In any C++ library, there are small API changes from time to time
> >>> leading to the type of problem you describe.
> >>>
> >>> If upstreams are using travis-ci, we are testing against version 1.12.2
> >>> from Debian/Ubuntu and may not be aware of issues in asio 1.14.0.  Even
> >>> if you patch for the issue, it may be completely untested upstream.
> >>> That is why it is so vital to resolve the Debian/Ubuntu lag.
> >>>
> >>> Is there a convenient way for upstreams to make CI builds on the latest
> >>> Fedora rawhide in parallel with our travis-ci Ubuntu builds?
> >>>
>  Please also note that I have checked both fale and uwog's recent
>  activity with fedora-active-user and neither seem to have been active
>  lately.
> >>>
> >>> Thanks for this feedback.  Dakota, do you want to be promoted to admin
> >>> on asio?
> >>>
> >>> Is either of you happy to be co-maintainer of resiprocate with me?  I
> >>> opened an issue to unretire it.  I do upstream releases and I run the
> >>> latest version for fedrtc.org (using CentOS/EPEL) so it is important for
> >>> me that it supports Fedora and any Fedora issues are given the attention
> >>> they deserve during the release process.
> >>
> >>
> >> Sure, admin is ok with me. Co-maintainer of resiprocate would also be
> >> something I'd be willing to take on.
> >
> > It's been a couple of weeks now, and I don't see "raineforest" listed
> > as admin for asio[1]. Can you please add him as requested?
>
> I had added Dakota as developer (commit?) and when I looked tonight, I
> notice he had vanished.  I've added him now as admin.  Is there any way
> to see how he vanished?  Does he need to explicitly click something to
> accept the permissions?
>
>

It seems to have stuck this time. Thanks for that.

> > Also, resiprocate[2] was retired three months ago after being orphaned
> > for 6 weeks for failing to build for Fedora 31[3]. It will need to go
> > through a whole new review process *after* asio is updated.
>
> Is it possible to make Covid-19 exception for this and just put it back
> again?  Lots of people want to use the WebRTC conferencing features.
> Yesterday I updated[4] JSCommunicator and today I tweaked[5] resiprocate
> for asio 1.14.0 so it is ready to go in Fedora, EPEL and fedrtc.org.  I
> have a backlog of upstream issues in all these projects and would prefer
> not to lose time in another review process.
>

If this had been only just retired, maybe. But it's been months.
Unfortunately, a re-review is required. Fortunately, I think a review
of it should be pretty easy to do, and I'm sure we can get it back in
quickly.



-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-22 Thread Daniel Pocock


On 20/03/2020 00:08, Neal Gompa wrote:
> On Thu, Mar 19, 2020 at 6:42 PM Daniel Pocock  wrote:

>> I had added Dakota as developer (commit?) and when I looked tonight, I
>> notice he had vanished.  I've added him now as admin.  Is there any way
>> to see how he vanished?  Does he need to explicitly click something to
>> accept the permissions?
>>
>>
> 
> It seems to have stuck this time. Thanks for that.
> 


As I've updated reSIProcate to use asio 1.14.0, I've also made a new
asio 1.14.0 build in koji.  It looks like bodhi automatically took it to
rawhide:

https://koji.fedoraproject.org/koji/taskinfo?taskID=42704357

https://bodhi.fedoraproject.org/updates/FEDORA-2020-1a78b8bb5d

reSIProcate appears to compile and work with asio 1.12.2 and 1.14.0.  I
haven't checked any other users of asio.

>>> Also, resiprocate[2] was retired three months ago after being orphaned
>>> for 6 weeks for failing to build for Fedora 31[3]. It will need to go
>>> through a whole new review process *after* asio is updated.
>>
>> Is it possible to make Covid-19 exception for this and just put it back
>> again?  Lots of people want to use the WebRTC conferencing features.
>> Yesterday I updated[4] JSCommunicator and today I tweaked[5] resiprocate
>> for asio 1.14.0 so it is ready to go in Fedora, EPEL and fedrtc.org.  I
>> have a backlog of upstream issues in all these projects and would prefer
>> not to lose time in another review process.
>>
> 
> If this had been only just retired, maybe. But it's been months.
> Unfortunately, a re-review is required. Fortunately, I think a review
> of it should be pretty easy to do, and I'm sure we can get it back in
> quickly.

As mentioned in the RTC thread, here is the review request:

https://bugzilla.redhat.com/show_bug.cgi?id=1815936

If either of you can assist in the review or also ongoing support for
the package it would be helpful.

Regards,

Daniel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-23 Thread Jared K. Smith
On Sun, Mar 22, 2020 at 8:10 PM Daniel Pocock  wrote:

> As mentioned in the RTC thread, here is the review request:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1815936
>

I've started the review, but I'm running into some issues in compiling the
software, as shown in the bug referenced above.

-Jared
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-02-24 Thread Artur Iwicki
On FSF Europe's mailing lists, DP's using the "daniel at pocock dot pro" 
address. I guess you could try messaging him using that address.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-02-26 Thread Dakota Williams via devel

On 2/24/20 5:57 PM, Daniel Pocock wrote:



On 24/02/2020 20:47, Dakota Williams wrote:

Does anyone know how to contact maintainer pocock?

https://bugzilla.redhat.com/show_bug.cgi?id=1806708
https://bugzilla.redhat.com/show_bug.cgi?id=1790674



Like most developers, I have a backlog of things to deal with and I try
to coordinate fixes for packaging issues into the right part of the
release cycle



Would you like help? I'd be willing to be a co-maintainer to make the 
branch.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-02-27 Thread Dakota Williams via devel

On 2/26/20 6:59 PM, Daniel Pocock wrote:



On 26/02/2020 22:56, Dakota Williams wrote:

On 2/24/20 5:57 PM, Daniel Pocock wrote:



On 24/02/2020 20:47, Dakota Williams wrote:

Does anyone know how to contact maintainer pocock?

https://bugzilla.redhat.com/show_bug.cgi?id=1806708
https://bugzilla.redhat.com/show_bug.cgi?id=1790674



Like most developers, I have a backlog of things to deal with and I try
to coordinate fixes for packaging issues into the right part of the
release cycle



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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-02-28 Thread Ankur Sinha
On Thu, Feb 27, 2020 17:07:21 -0500, Dakota Williams via devel wrote:
> On 2/26/20 6:59 PM, Daniel Pocock wrote:
> 
> > > 
> > > 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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-02-28 Thread Radka Janekova
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
*radka.ja...@redhat.com *
IRC: radka | Freenode: Rhea



On Fri, Feb 28, 2020 at 10:02 AM Ankur Sinha  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:
> > 
> > > >
> > > > 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-02-28 Thread Julian Sikorski
Hi Daniel,

I would like to add to Ankur's point: while I understand that many of us are 
doing Fedora work voluntarily and the expectations should be set accordingly, I 
believe we should be open to accept help when we realise that we cannot 
realistically commit enough time to the project. In case of asio, I have 
contacted you back in 2018 [1][2]. The pull request I have filed [3] has been 
opened since.
The situation with asio right now is that Fedora with its asio-1.10.8 is not 
only behind arch and gentoo (both at 1.14.0), but also behind debian buster (at 
1.12.2). Resiprocate, which is what was holding back asio update, has been 
retired due to FTBFS, then unorphaned at your request, and then retired again 
after being orphaned for 6+ weeks [4]. There has not been a successful build of 
resiprocate since 2016 [5].
Again, I perfectly understand that you have a backlog and that updating asio is 
not on top on your priority list. Being sceptical about co-maintainership 
offers seems counter-productive though, as there are things which need fixing 
and other people willing to step in.

Best regards,
Julian

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1551800#c2
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1638081#c2
[3] https://src.fedoraproject.org/rpms/asio/pull-request/1
[4] https://src.fedoraproject.org/rpms/resiprocate/commits/master
[5] https://koji.fedoraproject.org/koji/packageinfo?packageID=15875
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-02 Thread Neal Gompa
On Fri, Feb 28, 2020 at 1:23 PM Julian Sikorski  wrote:
>
> Hi Daniel,
>
> I would like to add to Ankur's point: while I understand that many of us are 
> doing Fedora work voluntarily and the expectations should be set accordingly, 
> I believe we should be open to accept help when we realise that we cannot 
> realistically commit enough time to the project. In case of asio, I have 
> contacted you back in 2018 [1][2]. The pull request I have filed [3] has been 
> opened since.
> The situation with asio right now is that Fedora with its asio-1.10.8 is not 
> only behind arch and gentoo (both at 1.14.0), but also behind debian buster 
> (at 1.12.2). Resiprocate, which is what was holding back asio update, has 
> been retired due to FTBFS, then unorphaned at your request, and then retired 
> again after being orphaned for 6+ weeks [4]. There has not been a successful 
> build of resiprocate since 2016 [5].
> Again, I perfectly understand that you have a backlog and that updating asio 
> is not on top on your priority list. Being sceptical about co-maintainership 
> offers seems counter-productive though, as there are things which need fixing 
> and other people willing to step in.
>

Hello Daniel,

I would like to suggest that given our community and its modus
operandi, I think it would be unfair to automatically be suspicious of
the work fellow packagers are trying to do to help you. But, if it
helps, I'd be willing to assist with the asio package. Hopefully, my
track record speaks for itself, in terms of maintaining packages in
Fedora and contributing to various aspects of the Project. I also
sponsored Dakota (the OP who asked you about asio), and I have been
mentoring him on how to interact with the larger Fedora community and
I was the one who encouraged him to reach out to you on asio for EPEL
8.

If you feel you are no longer able to give it the attention it needs,
I would respectfully request you transfer the ownership to Dakota, who
is interested in maintaining the package. If you have some concern
with him maintaining it, feel free to transfer the package to me
instead. Failing that, please just orphan the package so someone can
take care of it in your stead.

Thanks in advance, and thank you for being a member of the Fedora community.

Best regards,
Neal


-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-03 Thread Neal Gompa
On Tue, Mar 3, 2020 at 4:10 AM Daniel Pocock  wrote:
>
>
>
> On 28/02/2020 10:00, Ankur Sinha 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:
> >> 
> 
>  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,
>
> Why, then, have my replies to this thread never appeared in the mailing
> list then, only to the people on CC?
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JGCY5GM42SR2BEXGNUP6C335IFEV66KD/
>

I do not know why. I have filed an issue with infrastructure to find
out: https://pagure.io/fedora-infrastructure/issue/8713

> My own statement wasn't directed at any particular maintainer and
> doesn't imply that I am ungrateful for any offers of help.  I am very
> grateful for those people, including Dakota, who reached out in a
> positive way.
>
> Trust is not a constant thing, it can change over time.  The wider
> atmosphere and the disappearance of messages from mailing lists
> contributes to lower confidence.
>
> Unfortunately, I now see several emails every week (not necessarily from
> the Fedora mailing lists) that cause suspicion and concern.  I then feel
> a need to look at every other interaction more carefully.
>
> When I mentioned the death of my father in a blog recently, my blog was
> removed from Planet Fedora.  Now it seems my emails go to a moderator
> who doesn't have the time to keep up with all those censorship duties.
> I find this behaviour incredibly insulting and degrading, I suspect
> anybody in my position would feel the same way.
>

I'm sorry about that. I don't know what happened there either.

> > 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.
>
> My email was not a request for Dakota or anybody else to prove
> trustworthiness, it was only a reflection of my own perception of things
> going on in the wider free software community.
>
> But based on what you say, I'm happy to give access to Dakota and I'd
> also like to know if anybody else can help with the reSIProcate
> packages.  There is a new release in the pipeline and if somebody wants
> to get involved, now is the time.  We already made all the upstream
> fixes required for it to work with the latest dependencies on Fedora.
>

Thanks for granting Dakota maintainer privileges for asio! :)

I may be able to spare some cycles to help with reSIProcate (after I
get out of my mountain of FTBFS issues...). I'm sure other folks here
could help as well. :)


-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-03 Thread Daniel Pocock


On 03/03/2020 17:35, Neal Gompa wrote:
> On Tue, Mar 3, 2020 at 4:10 AM Daniel Pocock  wrote:
>>
>>
>>
>> On 28/02/2020 10:00, Ankur Sinha 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:
 
>>
>> 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,
>>
>> Why, then, have my replies to this thread never appeared in the mailing
>> list then, only to the people on CC?
>>
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JGCY5GM42SR2BEXGNUP6C335IFEV66KD/
>>
> 
> I do not know why. I have filed an issue with infrastructure to find
> out: https://pagure.io/fedora-infrastructure/issue/8713


Thanks for doing that

Here are some observations:

- the original email was sent to my pocock.com.au address and so my mail
client replied to all mails using that address, I didn't notice until
now.  That address is not subscribed.

- my other address, pocock.pro, is subscribed

- the list didn't give me any bounces or alerts that messages were held.
 At least some lists give warnings when a mail is sent from an address
that is not subscribed

- the last message sent from the pocock.pro address was on 19 August, it
was delivered to the list but only with a delay of 9 minutes

- the message prior to that was delayed by 20 hours inside Fedora:

Received: from mailman01.phx2.fedoraproject.org (localhost [IPv6:::1])
by mailman01.phx2.fedoraproject.org (Postfix) with ESMTP id 
CCE3858968E1E;
Fri,  2 Aug 2019 14:43:36 + (UTC)
Received: by mailman01.phx2.fedoraproject.org (Postfix, from userid 991)
id DCFA658968E12; Thu,  1 Aug 2019 18:25:21 + (UTC)

Combined with the blog censorship and other things going on in various
places, this type of observation is not very motivating but I do
understand things sometimes go wrong for technical reasons.


>> My own statement wasn't directed at any particular maintainer and
>> doesn't imply that I am ungrateful for any offers of help.  I am very
>> grateful for those people, including Dakota, who reached out in a
>> positive way.
>>
>> Trust is not a constant thing, it can change over time.  The wider
>> atmosphere and the disappearance of messages from mailing lists
>> contributes to lower confidence.
>>
>> Unfortunately, I now see several emails every week (not necessarily from
>> the Fedora mailing lists) that cause suspicion and concern.  I then feel
>> a need to look at every other interaction more carefully.
>>
>> When I mentioned the death of my father in a blog recently, my blog was
>> removed from Planet Fedora.  Now it seems my emails go to a moderator
>> who doesn't have the time to keep up with all those censorship duties.
>> I find this behaviour incredibly insulting and degrading, I suspect
>> anybody in my position would feel the same way.
>>
> 
> I'm sorry about that. I don't know what happened there either.
> 
>>> 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.
>>
>> My email was not a request for Dakota or anybody else to prove
>> trustworthiness, it was only a reflection of my own perception of things
>> going on in the wider free software community.
>>
>> B

Re: Non-responsive maintainer: pocock

2020-03-03 Thread Kevin Fenzi
On Tue, Mar 03, 2020 at 05:52:10PM +0100, Daniel Pocock wrote:
> 
> Thanks for doing that
> 
> Here are some observations:
> 
> - the original email was sent to my pocock.com.au address and so my mail
> client replied to all mails using that address, I didn't notice until
> now.  That address is not subscribed.
> 
> - my other address, pocock.pro, is subscribed
> 
> - the list didn't give me any bounces or alerts that messages were held.
>  At least some lists give warnings when a mail is sent from an address
> that is not subscribed

Odd. I see the list replying back with a bounce: 

Mar  3 09:10:32 mailman01.phx2.fedoraproject.org postfix/smtp[5786]: 
5C39C5D35D048: to=, relay=bast
ion.phx2.fedoraproject.org[10.5.126.12]:25, delay=0.15, 
delays=0.01/0/0.03/0.11, dsn=2.0.0, status=sent (250 2.0.0 Ok: qu
eued as 655CF601EA0C)
Mar  3 09:10:32 mailman01.phx2.fedoraproject.org postfix/qmgr[7288]: 
5C39C5D35D048: removed
Mar  3 09:10:34 bastion01.phx2.fedoraproject.org postfix/smtp[13250]: 
655CF601EA0C: to=, relay=mail
.trendhosting.net[195.8.117.5]:25, delay=2.4, delays=0.1/0/1.3/0.95, dsn=2.0.0, 
status=sent (250 2.0.0 Ok: queued as 0E2A
0150D5)

> 
> - the last message sent from the pocock.pro address was on 19 August, it
> was delivered to the list but only with a delay of 9 minutes
> 
> - the message prior to that was delayed by 20 hours inside Fedora:
> 
> Received: from mailman01.phx2.fedoraproject.org (localhost [IPv6:::1])
>   by mailman01.phx2.fedoraproject.org (Postfix) with ESMTP id 
> CCE3858968E1E;
>   Fri,  2 Aug 2019 14:43:36 + (UTC)
> Received: by mailman01.phx2.fedoraproject.org (Postfix, from userid 991)
>   id DCFA658968E12; Thu,  1 Aug 2019 18:25:21 + (UTC)

From my notes, that was a time when gmail was blocking several folks who
were asking for 'all fedmsgs as emails please'. ie, I see in irc at the
time I said: 
Aug 02 08:50:38  cool... 183,000 emails in bastion01's mail queue. 
wh. 

So, it took a while for them to process, your email wasn't blocked by
any moderator. 

> Combined with the blog censorship and other things going on in various
> places, this type of observation is not very motivating but I do
> understand things sometimes go wrong for technical reasons.

Do note that censorship means a gov entity blocking your right to free
speach. The Fedora Project is not a government. We reserve the right to
tell people they shouldn't use our platform for their speach. In
particular when it's not related to our mission.

That said, if you have questions about that, feel free to file a council
ticket/mail the council for clarification. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-03 Thread Radka Janekova
On Fri, Feb 28, 2020 at 1:39 PM Daniel Pocock  wrote:

>
> On 28/02/2020 11:21, Radka Janekova wrote:
> > 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.
>
>
> A lot of people are using CC or BCC, as described in the Fellowship
> blog[1], due to censorship problems and culture wars.  For example, some
> messages in this thread don't appear at all in the list archives[2].  Why?
>

Honestly I do not care what so ever. Nobody should bother people with their
emails - especially since most of us take a lot of care to not miss very
important work emails among the hundreds, if not even thousands of emails
that we receive every day (I personally received 250 emails only today, and
it's just the beginning of the NA timezone. By the time I wake up tomorrow
it sure will be 400 or more.) Within this amount of emails even with
complex filters in place, a responsible engineer will read through the
subject lines of every email at least in the relevant mailing lists. Email
like this one, with some sneaky bcc being added every 4th email so that the
thread keeps reappearing even after it's dismissed, gets ignored by that
complex system of filters, because the filter doesn't actually see why did
I receive this email. As such it lands in my HIGH PRIORITY inbox. This
freaks me out. Please stop.

If you have issues with sending emails to anything, contact administrators.
This is not a solution. If anything you will get your own email flagged as
spam by large number of people, which will lead exactly to what you're
trying to prevent/circumvent, just worse.


> If you see something like that, please share the full headers so we can
> all see how the message reached you, otherwise it is ambiguous.
>
> Regards,
>
> Daniel
>
>
> 1. https://fsfellowship.eu/freedom-and-censorship-on-mailing-lists/
> 2.
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JGCY5GM42SR2BEXGNUP6C335IFEV66KD/
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-03 Thread Dakota Williams via devel

On 3/3/20 4:10 AM, Daniel Pocock wrote:



On 28/02/2020 10:00, Ankur Sinha 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:



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,


Why, then, have my replies to this thread never appeared in the mailing
list then, only to the people on CC?

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JGCY5GM42SR2BEXGNUP6C335IFEV66KD/

My own statement wasn't directed at any particular maintainer and
doesn't imply that I am ungrateful for any offers of help.  I am very
grateful for those people, including Dakota, who reached out in a
positive way.

Trust is not a constant thing, it can change over time.  The wider
atmosphere and the disappearance of messages from mailing lists
contributes to lower confidence.

Unfortunately, I now see several emails every week (not necessarily from
the Fedora mailing lists) that cause suspicion and concern.  I then feel
a need to look at every other interaction more carefully.

When I mentioned the death of my father in a blog recently, my blog was
removed from Planet Fedora.  Now it seems my emails go to a moderator
who doesn't have the time to keep up with all those censorship duties.
I find this behaviour incredibly insulting and degrading, I suspect
anybody in my position would feel the same way.


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.


My email was not a request for Dakota or anybody else to prove
trustworthiness, it was only a reflection of my own perception of things
going on in the wider free software community.

But based on what you say, I'm happy to give access to Dakota and I'd
also like to know if anybody else can help with the reSIProcate
packages.  There is a new release in the pipeline and if somebody wants
to get involved, now is the time.  We already made all the upstream
fixes required for it to work with the latest dependencies on Fedora.


Great, my FAS id is "raineforest". Where would you like me to start?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-03 Thread Daniel Pocock


On 03/03/2020 18:50, Kevin Fenzi wrote:
> On Tue, Mar 03, 2020 at 05:52:10PM +0100, Daniel Pocock wrote:
>>
>> Thanks for doing that
>>
>> Here are some observations:
>>
>> - the original email was sent to my pocock.com.au address and so my mail
>> client replied to all mails using that address, I didn't notice until
>> now.  That address is not subscribed.
>>
>> - my other address, pocock.pro, is subscribed
>>
>> - the list didn't give me any bounces or alerts that messages were held.
>>  At least some lists give warnings when a mail is sent from an address
>> that is not subscribed
> 
> Odd. I see the list replying back with a bounce: 
> 
> Mar  3 09:10:32 mailman01.phx2.fedoraproject.org postfix/smtp[5786]: 
> 5C39C5D35D048: to=, relay=bast
> ion.phx2.fedoraproject.org[10.5.126.12]:25, delay=0.15, 
> delays=0.01/0/0.03/0.11, dsn=2.0.0, status=sent (250 2.0.0 Ok: qu
> eued as 655CF601EA0C)
> Mar  3 09:10:32 mailman01.phx2.fedoraproject.org postfix/qmgr[7288]: 
> 5C39C5D35D048: removed
> Mar  3 09:10:34 bastion01.phx2.fedoraproject.org postfix/smtp[13250]: 
> 655CF601EA0C: to=, relay=mail
> .trendhosting.net[195.8.117.5]:25, delay=2.4, delays=0.1/0/1.3/0.95, 
> dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 0E2A
> 0150D5)
> 

Thanks for clarifying that - I found those bounces, but here is what I
notice:

- they are not being threaded, so I didn't see them in the folder until
I looked for them

- their subject line isn't changed to look like a bounce, so they didn't
catch my eye

On a more quiet list these probably would have been noticed earlier but
I think that for a busy list, they need to be more visible, e.g. by
putting them in the thread AND putting some prefix on the subject.  Here
is what I see:

From:  devel-ow...@lists.fedoraproject.org
Subject:   Re: Non-responsive maintainer: pocock

>>
>> - the last message sent from the pocock.pro address was on 19 August, it
>> was delivered to the list but only with a delay of 9 minutes
>>
>> - the message prior to that was delayed by 20 hours inside Fedora:
>>
>> Received: from mailman01.phx2.fedoraproject.org (localhost [IPv6:::1])
>>  by mailman01.phx2.fedoraproject.org (Postfix) with ESMTP id 
>> CCE3858968E1E;
>>  Fri,  2 Aug 2019 14:43:36 + (UTC)
>> Received: by mailman01.phx2.fedoraproject.org (Postfix, from userid 991)
>>  id DCFA658968E12; Thu,  1 Aug 2019 18:25:21 + (UTC)
> 
> From my notes, that was a time when gmail was blocking several folks who
> were asking for 'all fedmsgs as emails please'. ie, I see in irc at the
> time I said: 
> Aug 02 08:50:38  cool... 183,000 emails in bastion01's mail queue. 
> wh. 
> 
> So, it took a while for them to process, your email wasn't blocked by
> any moderator. 
> 
>> Combined with the blog censorship and other things going on in various
>> places, this type of observation is not very motivating but I do
>> understand things sometimes go wrong for technical reasons.
> 
> Do note that censorship means a gov entity blocking your right to free
> speach. The Fedora Project is not a government. We reserve the right to

This particular point has been argued about elsewhere.  While I don't
agree with your perspective, I don't feel the distinction is relevant
anyway because...

> tell people they shouldn't use our platform for their speach. In
> particular when it's not related to our mission.
> 
> That said, if you have questions about that, feel free to file a council
> ticket/mail the council for clarification. 
> 

... the bigger problem is simply confusion and confidence.  Whether
Fedora is a Government or not, and Fedora is certainly more influential
than some micro-nations[1], disappearing messages and disappearing blogs
can create confusion.  I finished my email with the disclaimer that
things can go wrong for technical reasons but some people aren't so open
minded.  Problems have been spilling over between communities in the
last couple of years and I've been shown emails demonstrating that the
leaders of two independent organizations decided to share information
about who to moderate/censor.  The experience I had with Planet Fedora
also contributed to a greater sense of suspicion, in other words, more
confusion, less effort made to hunt for the bounces.  That is time
wasted for both of us.

As a developer, I started writing a script (it is not public yet) to
scan Received headers and let me know when other developers or my own
messages experience trouble.  Think of it like the canary in the coal
mine.  The canary has already been BBQed[2] several times over in FSF.

Think about the feeling you get when you write a detail

Re: Non-responsive maintainer: pocock

2020-03-05 Thread Daniel Pocock


On 03/03/2020 23:23, Dakota Williams wrote:
> On 3/3/20 4:10 AM, Daniel Pocock wrote:

>>
>> But based on what you say, I'm happy to give access to Dakota and I'd
>> also like to know if anybody else can help with the reSIProcate
>> packages.  There is a new release in the pipeline and if somebody wants
>> to get involved, now is the time.  We already made all the upstream
>> fixes required for it to work with the latest dependencies on Fedora.
> 
> Great, my FAS id is "raineforest". Where would you like me to start?

I added you with commit access.

If you would like admin access can you please try to reach one of the
other two admins (uwog and fale) to confirm?  If the rest of the
community is OK with this way of granting access then I have no
objections.  Welcome to asio.  It means something else in Australia.

Here you can see the version of asio we are testing with reSIProcate,
the Windows devs use the 1.12.2 snapshot in the contrib tree:
https://github.com/resiprocate/resiprocate/tree/master/contrib

and travis-ci builds use whatever version is fetched by this script:
https://github.com/resiprocate/resiprocate/blob/master/.travis.yml

Debian and Ubuntu only have 1.12.2
https://packages.qa.debian.org/a/asio.html

and that is what upstream travis-ci and my own upstream builds are based on.

Markus Wanner (the other Debian maintainer) is also in Switzerland, I'm
either in Switzerland or Ireland.  If you are nearby I'm happy to meet you.

Debian politics are preventing an upload of 1.14.0 to Debian otherwise I
would have done it already.  Due to the way the API changes from time to
time it will be inconvenient for upstream devs like myself if there are
different versions in Fedora and Debian.

In fact, I had started preparing the upstream release on 20 September 2018:
https://github.com/resiprocate/resiprocate/commits/master?after=349d76b99fa7e99e4c4e7e5052e53115a64dcb45+174

and just minutes later somebody else in Debian decided to attack me.  In
my entire career I've never received such ungrateful and spiteful
communications after making a commit.

Regards,

Daniel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-05 Thread Julian Sikorski
W dniu 05.03.2020 o 21:01, Daniel Pocock pisze:
> 
> 
> On 03/03/2020 23:23, Dakota Williams wrote:
>> On 3/3/20 4:10 AM, Daniel Pocock wrote:
> 
>>>
>>> But based on what you say, I'm happy to give access to Dakota and I'd
>>> also like to know if anybody else can help with the reSIProcate
>>> packages.  There is a new release in the pipeline and if somebody wants
>>> to get involved, now is the time.  We already made all the upstream
>>> fixes required for it to work with the latest dependencies on Fedora.
>>
>> Great, my FAS id is "raineforest". Where would you like me to start?
> 
> I added you with commit access.
> 
> If you would like admin access can you please try to reach one of the
> other two admins (uwog and fale) to confirm?  If the rest of the
> community is OK with this way of granting access then I have no
> objections.  Welcome to asio.  It means something else in Australia.
> 
> Here you can see the version of asio we are testing with reSIProcate,
> the Windows devs use the 1.12.2 snapshot in the contrib tree:
> https://github.com/resiprocate/resiprocate/tree/master/contrib
> 
> and travis-ci builds use whatever version is fetched by this script:
> https://github.com/resiprocate/resiprocate/blob/master/.travis.yml
> 
> Debian and Ubuntu only have 1.12.2
> https://packages.qa.debian.org/a/asio.html
> 
> and that is what upstream travis-ci and my own upstream builds are based on.
> 
> Markus Wanner (the other Debian maintainer) is also in Switzerland, I'm
> either in Switzerland or Ireland.  If you are nearby I'm happy to meet you.
> 
> Debian politics are preventing an upload of 1.14.0 to Debian otherwise I
> would have done it already.  Due to the way the API changes from time to
> time it will be inconvenient for upstream devs like myself if there are
> different versions in Fedora and Debian.
> 
> In fact, I had started preparing the upstream release on 20 September 2018:
> https://github.com/resiprocate/resiprocate/commits/master?after=349d76b99fa7e99e4c4e7e5052e53115a64dcb45+174
> 
> and just minutes later somebody else in Debian decided to attack me.  In
> my entire career I've never received such ungrateful and spiteful
> communications after making a commit.
> 
> Regards,
> 
> Daniel
> 
Thank you for granting access to Dakota!

I would like to take this opportunity to remind about the PR that I have
prepared - let us not duplicate the work:
https://src.fedoraproject.org/rpms/asio/pull-request/1
I have rebuilt all asio's dependencies and only encountered issues with
abiword and OpenSceneGraph - both were complaining about error not being
a member of asio::placeholders. Same issues were found by gentoo, I have
linked the relevant bug reports in the PR. Is this something you would
be able to advise about? I am happy to share full build logs if needed.

Please also note that I have checked both fale and uwog's recent
activity with fedora-active-user and neither seem to have been active
lately.

Best regards,
Julian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-06 Thread Daniel Pocock


On 05/03/2020 21:26, Julian Sikorski wrote:

> I would like to take this opportunity to remind about the PR that I have
> prepared - let us not duplicate the work:
> https://src.fedoraproject.org/rpms/asio/pull-request/1
> I have rebuilt all asio's dependencies and only encountered issues with
> abiword and OpenSceneGraph - both were complaining about error not being
> a member of asio::placeholders. Same issues were found by gentoo, I have
> linked the relevant bug reports in the PR. Is this something you would
> be able to advise about? I am happy to share full build logs if needed.

I haven't personally looked at asio 1.14.0 yet so I don't have the
solution off the top of my head.  These are the type of issues I
normally deal with in upstream development.

From a strategic perspective, I feel it is most efficient to try and
coordinate with the upstreams and other distributions so that everybody
is supporting the same asio in each of the major distributions.

In any C++ library, there are small API changes from time to time
leading to the type of problem you describe.

If upstreams are using travis-ci, we are testing against version 1.12.2
from Debian/Ubuntu and may not be aware of issues in asio 1.14.0.  Even
if you patch for the issue, it may be completely untested upstream.
That is why it is so vital to resolve the Debian/Ubuntu lag.

Is there a convenient way for upstreams to make CI builds on the latest
Fedora rawhide in parallel with our travis-ci Ubuntu builds?

> Please also note that I have checked both fale and uwog's recent
> activity with fedora-active-user and neither seem to have been active
> lately.

Thanks for this feedback.  Dakota, do you want to be promoted to admin
on asio?

Is either of you happy to be co-maintainer of resiprocate with me?  I
opened an issue to unretire it.  I do upstream releases and I run the
latest version for fedrtc.org (using CentOS/EPEL) so it is important for
me that it supports Fedora and any Fedora issues are given the attention
they deserve during the release process.

Regards,

Daniel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-06 Thread Dakota Williams via devel

On 3/6/20 1:21 PM, Daniel Pocock wrote:



On 05/03/2020 21:26, Julian Sikorski wrote:


I would like to take this opportunity to remind about the PR that I have
prepared - let us not duplicate the work:
https://src.fedoraproject.org/rpms/asio/pull-request/1
I have rebuilt all asio's dependencies and only encountered issues with
abiword and OpenSceneGraph - both were complaining about error not being
a member of asio::placeholders. Same issues were found by gentoo, I have
linked the relevant bug reports in the PR. Is this something you would
be able to advise about? I am happy to share full build logs if needed.


I haven't personally looked at asio 1.14.0 yet so I don't have the
solution off the top of my head.  These are the type of issues I
normally deal with in upstream development.

 From a strategic perspective, I feel it is most efficient to try and
coordinate with the upstreams and other distributions so that everybody
is supporting the same asio in each of the major distributions.

In any C++ library, there are small API changes from time to time
leading to the type of problem you describe.

If upstreams are using travis-ci, we are testing against version 1.12.2
from Debian/Ubuntu and may not be aware of issues in asio 1.14.0.  Even
if you patch for the issue, it may be completely untested upstream.
That is why it is so vital to resolve the Debian/Ubuntu lag.

Is there a convenient way for upstreams to make CI builds on the latest
Fedora rawhide in parallel with our travis-ci Ubuntu builds?


Please also note that I have checked both fale and uwog's recent
activity with fedora-active-user and neither seem to have been active
lately.


Thanks for this feedback.  Dakota, do you want to be promoted to admin
on asio?

Is either of you happy to be co-maintainer of resiprocate with me?  I
opened an issue to unretire it.  I do upstream releases and I run the
latest version for fedrtc.org (using CentOS/EPEL) so it is important for
me that it supports Fedora and any Fedora issues are given the attention
they deserve during the release process.



Sure, admin is ok with me. Co-maintainer of resiprocate would also be 
something I'd be willing to take on.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-07 Thread Julian Sikorski

W dniu 06.03.2020 o 19:21, Daniel Pocock pisze:



On 05/03/2020 21:26, Julian Sikorski wrote:


I would like to take this opportunity to remind about the PR that I have
prepared - let us not duplicate the work:
https://src.fedoraproject.org/rpms/asio/pull-request/1
I have rebuilt all asio's dependencies and only encountered issues with
abiword and OpenSceneGraph - both were complaining about error not being
a member of asio::placeholders. Same issues were found by gentoo, I have
linked the relevant bug reports in the PR. Is this something you would
be able to advise about? I am happy to share full build logs if needed.


I haven't personally looked at asio 1.14.0 yet so I don't have the
solution off the top of my head.  These are the type of issues I
normally deal with in upstream development.

 From a strategic perspective, I feel it is most efficient to try and
coordinate with the upstreams and other distributions so that everybody
is supporting the same asio in each of the major distributions.

In any C++ library, there are small API changes from time to time
leading to the type of problem you describe.
> If upstreams are using travis-ci, we are testing against version 1.12.2
from Debian/Ubuntu and may not be aware of issues in asio 1.14.0.  Even
if you patch for the issue, it may be completely untested upstream.
That is why it is so vital to resolve the Debian/Ubuntu lag.

I do not know what Debian's issues regarding update to 1.14.0 were, but 
from what you are saying it appears someone at Debian lost their cool.
In any case, Fedora is a more bleeding edge distro than Debian/Ubuntu 
(First one of the foundations), so I am not sure how realistic it is to 
be waiting for Debian/Ubuntu to include something before we can do it in 
Fedora.
I was able to fix abiword completely by adding -DASIO_ENABLE_BOOST to 
CXXFLAGS, OSG still fails further down the line due to get_io_service() 
having been removed. I have filed upstream issues for both projects, 
details in the PR.



Is there a convenient way for upstreams to make CI builds on the latest
Fedora rawhide in parallel with our travis-ci Ubuntu builds?

I am not aware of a ci service using Fedora, both appveyor and travis 
appear to be using ubuntu.



Please also note that I have checked both fale and uwog's recent
activity with fedora-active-user and neither seem to have been active
lately.


Thanks for this feedback.  Dakota, do you want to be promoted to admin
on asio?

Is either of you happy to be co-maintainer of resiprocate with me?  I
opened an issue to unretire it.  I do upstream releases and I run the
latest version for fedrtc.org (using CentOS/EPEL) so it is important for
me that it supports Fedora and any Fedora issues are given the attention
they deserve during the release process.

Regards,

Daniel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-07 Thread Neal Gompa
On Fri, Mar 6, 2020 at 1:21 PM Daniel Pocock  wrote:
>
>
> If upstreams are using travis-ci, we are testing against version 1.12.2
> from Debian/Ubuntu and may not be aware of issues in asio 1.14.0.  Even
> if you patch for the issue, it may be completely untested upstream.
> That is why it is so vital to resolve the Debian/Ubuntu lag.
>
> Is there a convenient way for upstreams to make CI builds on the latest
> Fedora rawhide in parallel with our travis-ci Ubuntu builds?
>

If you're okay with using containers in your CI, it's relatively
straightforward to do so.

Here's an example of doing Fedora and CentOS builds in Travis CI:
https://github.com/rpm-software-management/librpm.rs/blob/master/.travis.yml



--
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-07 Thread Julian Sikorski

W dniu 07.03.2020 o 13:53, Neal Gompa pisze:

On Fri, Mar 6, 2020 at 1:21 PM Daniel Pocock  wrote:



If upstreams are using travis-ci, we are testing against version 1.12.2
from Debian/Ubuntu and may not be aware of issues in asio 1.14.0.  Even
if you patch for the issue, it may be completely untested upstream.
That is why it is so vital to resolve the Debian/Ubuntu lag.

Is there a convenient way for upstreams to make CI builds on the latest
Fedora rawhide in parallel with our travis-ci Ubuntu builds?



If you're okay with using containers in your CI, it's relatively
straightforward to do so.

Here's an example of doing Fedora and CentOS builds in Travis CI:
https://github.com/rpm-software-management/librpm.rs/blob/master/.travis.yml

The problem with this approach is that every downstream dependency of 
asio would have to adopt the container approach. Not sure how 
practicable that is.

Ideally Travis would adopt Fedora in addition to macOS and Ubuntu.

Best regards,
Julian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-07 Thread Neal Gompa
On Sat, Mar 7, 2020 at 9:02 AM Julian Sikorski  wrote:
>
> W dniu 07.03.2020 o 13:53, Neal Gompa pisze:
> > On Fri, Mar 6, 2020 at 1:21 PM Daniel Pocock  wrote:
> >>
> >>
> >> If upstreams are using travis-ci, we are testing against version 1.12.2
> >> from Debian/Ubuntu and may not be aware of issues in asio 1.14.0.  Even
> >> if you patch for the issue, it may be completely untested upstream.
> >> That is why it is so vital to resolve the Debian/Ubuntu lag.
> >>
> >> Is there a convenient way for upstreams to make CI builds on the latest
> >> Fedora rawhide in parallel with our travis-ci Ubuntu builds?
> >>
> >
> > If you're okay with using containers in your CI, it's relatively
> > straightforward to do so.
> >
> > Here's an example of doing Fedora and CentOS builds in Travis CI:
> > https://github.com/rpm-software-management/librpm.rs/blob/master/.travis.yml
> >
> The problem with this approach is that every downstream dependency of
> asio would have to adopt the container approach. Not sure how
> practicable that is.
> Ideally Travis would adopt Fedora in addition to macOS and Ubuntu.
>

Well, anyone know anybody at Travis CI that we'd talk to about doing
that? Unfortunately, I don't...


-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-07 Thread Daniel Pocock


On 07/03/2020 10:32, Julian Sikorski wrote:
> W dniu 06.03.2020 o 19:21, Daniel Pocock pisze:
>>
>>
>> On 05/03/2020 21:26, Julian Sikorski wrote:
>>
>>> I would like to take this opportunity to remind about the PR that I have
>>> prepared - let us not duplicate the work:
>>> https://src.fedoraproject.org/rpms/asio/pull-request/1
>>> I have rebuilt all asio's dependencies and only encountered issues with
>>> abiword and OpenSceneGraph - both were complaining about error not being
>>> a member of asio::placeholders. Same issues were found by gentoo, I have
>>> linked the relevant bug reports in the PR. Is this something you would
>>> be able to advise about? I am happy to share full build logs if needed.
>>
>> I haven't personally looked at asio 1.14.0 yet so I don't have the
>> solution off the top of my head.  These are the type of issues I
>> normally deal with in upstream development.
>>
>>  From a strategic perspective, I feel it is most efficient to try and
>> coordinate with the upstreams and other distributions so that everybody
>> is supporting the same asio in each of the major distributions.
>>
>> In any C++ library, there are small API changes from time to time
>> leading to the type of problem you describe.
>> > If upstreams are using travis-ci, we are testing against version 1.12.2
>> from Debian/Ubuntu and may not be aware of issues in asio 1.14.0.  Even
>> if you patch for the issue, it may be completely untested upstream.
>> That is why it is so vital to resolve the Debian/Ubuntu lag.
>>
> I do not know what Debian's issues regarding update to 1.14.0 were, but
> from what you are saying it appears someone at Debian lost their cool.

Did you know the Debian Project Leader sent an abusive email shortly
after my father died?  Did you know that this wasn't the first time that
I saw abusive communications from somebody in Debian leadership at an
acute time of personal tragedy?

Just imagine if a Fedora volunteer's family member dies and a Red Hat
manager creeps up on them at the funeral and tasers the volunteer while
other Red Hat staff record the reaction on a smartphone video and post
it online.

How long would the repercussions continue after such an abuse?

Would it be right to keep hosting the video indefinitely on Fedora
platforms?

If that volunteer feels their family's privacy is being violated as long
as it is perpetuated, would you have no empathy for them?

When I saw the UN's recent report[1] on Cybertorture, Debian was the
first thing on my mind.  Humiliating and shaming people, Debian's go-to
solutions, are high on their list of abuses.


> In any case, Fedora is a more bleeding edge distro than Debian/Ubuntu
> (First one of the foundations), so I am not sure how realistic it is to
> be waiting for Debian/Ubuntu to include something before we can do it in
> Fedora.

Debian unstable/sid is similarly bleeding edge to rawhide

Having the same dependencies in Debian sid and Fedora rawhide makes life
easier for everybody: library maintainers, upstreams and package
maintainers.

I've always tried to work that way, that is the very reason I
volunteered to maintain asio in both Debian and Fedora.  I also put the
necessary effort into supporting Debian backports and Fedora EPEL so
these things could be widely available.

> I was able to fix abiword completely by adding -DASIO_ENABLE_BOOST to
> CXXFLAGS, OSG still fails further down the line due to get_io_service()
> having been removed. I have filed upstream issues for both projects,
> details in the PR.

Thanks for your attention to detail with that

>> Is there a convenient way for upstreams to make CI builds on the latest
>> Fedora rawhide in parallel with our travis-ci Ubuntu builds?
>>
> I am not aware of a ci service using Fedora, both appveyor and travis
> appear to be using ubuntu.

I have some ideas about how to address this

There is a similar script to use Docker inside travis-ci, using Docker
for a pure Debian sid build, rather than the default Ubuntu environment:

https://travis.debian.net/

Could a Fedora equivalent exist?

Maybe OBS could also be relevant:
https://openbuildservice.org/

Regards,

Daniel


1.
https://www.theguardian.com/law/2020/feb/21/un-rapporteur-warns-of-rise-of-cybertorture-to-bypass-physical-ban
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-07 Thread Neal Gompa
On Sat, Mar 7, 2020 at 11:47 AM Daniel Pocock  wrote:
>
> On 07/03/2020 10:32, Julian Sikorski wrote:
>
> > In any case, Fedora is a more bleeding edge distro than Debian/Ubuntu
> > (First one of the foundations), so I am not sure how realistic it is to
> > be waiting for Debian/Ubuntu to include something before we can do it in
> > Fedora.
>
> Debian unstable/sid is similarly bleeding edge to rawhide
>
> Having the same dependencies in Debian sid and Fedora rawhide makes life
> easier for everybody: library maintainers, upstreams and package
> maintainers.
>
> I've always tried to work that way, that is the very reason I
> volunteered to maintain asio in both Debian and Fedora.  I also put the
> necessary effort into supporting Debian backports and Fedora EPEL so
> these things could be widely available.
>

Thank you for putting in the effort to making stuff broadly available
to the Fedora community. I think you might be doing a slight
disservice by holding things back in Fedora, but that is your
prerogative. In general, I would advise keeping your packages updated
in Fedora unless there's a really good technical reason not to.

> >> Is there a convenient way for upstreams to make CI builds on the latest
> >> Fedora rawhide in parallel with our travis-ci Ubuntu builds?
> >>
> > I am not aware of a ci service using Fedora, both appveyor and travis
> > appear to be using ubuntu.
>
> I have some ideas about how to address this
>
> There is a similar script to use Docker inside travis-ci, using Docker
> for a pure Debian sid build, rather than the default Ubuntu environment:
>
> https://travis.debian.net/
>
> Could a Fedora equivalent exist?
>

We do have the Zuul based CI that the Fedora CI folks are working on:
https://fedoraproject.org/wiki/Zuul-based-ci

I don't know if they have the ability to support projects from GitHub as well.

> Maybe OBS could also be relevant:
> https://openbuildservice.org/
>

Fedora COPR is designed to integrate well with software CI workflows,
and the Packit service is an instance of this: https://packit.dev/

Packit may be able to help for this specific thing you're looking for.


-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


Re: Non-responsive maintainer: pocock

2020-03-15 Thread Neal Gompa
On Fri, Mar 6, 2020 at 2:06 PM Dakota Williams
 wrote:
>
> On 3/6/20 1:21 PM, Daniel Pocock wrote:
> >
> >
> > On 05/03/2020 21:26, Julian Sikorski wrote:
> >
> >> I would like to take this opportunity to remind about the PR that I have
> >> prepared - let us not duplicate the work:
> >> https://src.fedoraproject.org/rpms/asio/pull-request/1
> >> I have rebuilt all asio's dependencies and only encountered issues with
> >> abiword and OpenSceneGraph - both were complaining about error not being
> >> a member of asio::placeholders. Same issues were found by gentoo, I have
> >> linked the relevant bug reports in the PR. Is this something you would
> >> be able to advise about? I am happy to share full build logs if needed.
> >
> > I haven't personally looked at asio 1.14.0 yet so I don't have the
> > solution off the top of my head.  These are the type of issues I
> > normally deal with in upstream development.
> >
> >  From a strategic perspective, I feel it is most efficient to try and
> > coordinate with the upstreams and other distributions so that everybody
> > is supporting the same asio in each of the major distributions.
> >
> > In any C++ library, there are small API changes from time to time
> > leading to the type of problem you describe.
> >
> > If upstreams are using travis-ci, we are testing against version 1.12.2
> > from Debian/Ubuntu and may not be aware of issues in asio 1.14.0.  Even
> > if you patch for the issue, it may be completely untested upstream.
> > That is why it is so vital to resolve the Debian/Ubuntu lag.
> >
> > Is there a convenient way for upstreams to make CI builds on the latest
> > Fedora rawhide in parallel with our travis-ci Ubuntu builds?
> >
> >> Please also note that I have checked both fale and uwog's recent
> >> activity with fedora-active-user and neither seem to have been active
> >> lately.
> >
> > Thanks for this feedback.  Dakota, do you want to be promoted to admin
> > on asio?
> >
> > Is either of you happy to be co-maintainer of resiprocate with me?  I
> > opened an issue to unretire it.  I do upstream releases and I run the
> > latest version for fedrtc.org (using CentOS/EPEL) so it is important for
> > me that it supports Fedora and any Fedora issues are given the attention
> > they deserve during the release process.
>
>
> Sure, admin is ok with me. Co-maintainer of resiprocate would also be
> something I'd be willing to take on.

It's been a couple of weeks now, and I don't see "raineforest" listed
as admin for asio[1]. Can you please add him as requested?

Also, resiprocate[2] was retired three months ago after being orphaned
for 6 weeks for failing to build for Fedora 31[3]. It will need to go
through a whole new review process *after* asio is updated.

[1]: https://src.fedoraproject.org/rpms/asio
[2]: https://src.fedoraproject.org/rpms/resiprocate
[3]: https://pagure.io/releng/issue/8917#comment-610267

--
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org