I'd like to see what are everyone's thoughts on decommissioning anaconda-patches list. Now that we've moved to GitHub, it's pretty much obsolete, and I think decommissioning it could be beneficial:
(a) (Way) less email overall.
(b) The GitHub email script that we have was originally created with the intent of preserving the posted patches + discussions forever in history, but the patches are not actually included in any emails. Additionally, unless someone makes an in-line comment in the patch, there usually is no context provided in responses. So, the emails don't contain a lot of value.
(c) It's a good way to force all the stragglers (e.g. myself) to migrate their workflow to GitHub and have everyone working the same way.
(d) As a benefit of (c), less confusion for new contributors, concerning how to post a patch, etc.
I know we can disassociate the webhook email forwarder from GitHub pretty easily. Concerning the list itself though, if there's a way to effectively "close it for business" but leave its contents forever available for perusal, I think that might be ideal.
Anyway, thoughts?
Samantha
(c) It's a good way to force all the stragglers (e.g. myself) to migrate their workflow to GitHub and have everyone working the same way.
I am a straggler too, and I'm fine with getting rid of the patches list.
I know we can disassociate the webhook email forwarder from GitHub pretty easily. Concerning the list itself though, if there's a way to effectively "close it for business" but leave its contents forever available for perusal, I think that might be ideal.
I don't see any way to do this, which is pretty disappointing. Perhaps I just need to dig harder.
- Chris
На 23.05.2016 в 18:17, Chris Lumens написа:
I don't see any way to do this, which is pretty disappointing. Perhaps I just need to dig harder.
Maybe one of these links will help:
https://answers.launchpad.net/ubuntu/+source/mailman/+question/157154
https://mail.python.org/pipermail/mailman-users/2010-September/070284.html
http://serverfault.com/questions/562158/how-to-properly-disable-a-mailman-ma...
-- Alex
On Mon, May 23, 2016 at 10:08:50AM -0400, Samantha N. Bueno wrote:
Anyway, thoughts?
Fine by me as well. As for turning off the list, if there isn't a way to do that we can just leave it as is and politely remind any posters that review has moved to github.
----- Original Message -----
From: "Samantha N. Bueno" sbueno+anaconda@redhat.com To: anaconda-devel-list@redhat.com Sent: Monday, May 23, 2016 4:08:50 PM Subject: anaconda-patches mailing list
I'd like to see what are everyone's thoughts on decommissioning anaconda-patches list. Now that we've moved to GitHub, it's pretty much obsolete, and I think decommissioning it could be beneficial:
(a) (Way) less email overall.
(b) The GitHub email script that we have was originally created with the intent of preserving the posted patches + discussions forever in history, but the patches are not actually included in any emails.
That's weird - I can see the patch content of pull requests & it seems to also be in the archive. for example: https://lists.fedorahosted.org/archives/list/anaconda-patches@lists.fedoraho...
Additionally, unless someone makes an in-line comment in the patch, there usually is no context provided in responses. So, the emails don't contain a lot of value.
Yeah, it really is kinda on-directional anyway due to the need to reply on GitHub.
(c) It's a good way to force all the stragglers (e.g. myself) to migrate their workflow to GitHub and have everyone working the same way.
(d) As a benefit of (c), less confusion for new contributors, concerning how to post a patch, etc.
Certainly! Only possible issue from the community/contributor perspective could be that there are some people who don't use or don't want to use GitHub, for various reasons. On the other hand I don't think we really got any such contributions recently & we could use the devel list for that if needed.
I know we can disassociate the webhook email forwarder from GitHub pretty easily. Concerning the list itself though, if there's a way to effectively "close it for business" but leave its contents forever available for perusal, I think that might be ideal.
It is running on the Fedora infrastructure, so I guess the contacting the Infra people might be a way to go: https://fedoraproject.org/wiki/Infrastructure
Anyway, thoughts?
Yeah, why not. :) Just some remarks above.
Samantha
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Tue, May 24, 2016 at 05:39:56 -0400, Martin Kolman mkolman@redhat.com wrote:
Certainly! Only possible issue from the community/contributor perspective could be that there are some people who don't use or don't want to use GitHub, for various reasons.
Hopefully the project will someday move to Pagure.
On Tue, May 24, 2016 at 11:34:53 -0400, Chris Lumens clumens@redhat.com wrote:
Certainly! Only possible issue from the community/contributor perspective could be that there are some people who don't use or don't want to use GitHub, for various reasons.
Hopefully the project will someday move to Pagure.
I can't see that happening.
If the reasons are limitations of Pagure, filing issues for needed features would help in making Pagure better for everyone.
I wouldn't expect the network effects of github to be that important to outweigh running on a service run by non-free software. Nor would I expect a migration to be too much effort to do eventually. (Though there are costs and it would be prudent not to rush a change until Pagure's future is more well known.) There certainly could be technical blockers, but hopefully those could be eventually addressed.
On Tue, May 24, 2016 at 11:56 AM, Bruno Wolff III bruno@wolff.to wrote:
On Tue, May 24, 2016 at 11:34:53 -0400, Chris Lumens clumens@redhat.com wrote:
Certainly! Only possible issue from the community/contributor perspective could be
that there are some people who don't use or don't want to use GitHub,
for various reasons.
Hopefully the project will someday move to Pagure.
I can't see that happening.
If the reasons are limitations of Pagure, filing issues for needed features would help in making Pagure better for everyone.
I wouldn't expect the network effects of github to be that important to outweigh running on a service run by non-free software. Nor would I expect a migration to be too much effort to do eventually. (Though there are costs and it would be prudent not to rush a change until Pagure's future is more well known.) There certainly could be technical blockers, but hopefully those could be eventually addressed.
Changing the development workflow is not something we've ever taken lightly. There have been two major shifts in the last 10+ years. First was the move from cvs to git. The second was to move off Fedora infrastructure to github, and that decision wasn't just rushed through.
github has made it significantly easier for us to accept contributions from other individuals and companies. Like it or not, github has succeeded in making contributing to projects easy. If Pagure is just duplicating this functionality, fine, but that's not a good enough reason for us to change the development workflow. A large part of us wanting to move off Fedora infrastructure was the barrier to entry for gaining outside contributors. It was simply too high.
I'm not saying yes or no regarding moving things off github, but just that there are significant benefits to github that are very beneficial to the project right now.
On Tue, May 24, 2016 at 13:29:16 -0400, David Cantrell dcantrell@redhat.com wrote:
Changing the development workflow is not something we've ever taken lightly. There have been two major shifts in the last 10+ years. First was the move from cvs to git. The second was to move off Fedora infrastructure to github, and that decision wasn't just rushed through.
I wouldn't expect anything soon. Pagure has promise, but it is too soon to say where things are going to go, and without that assurance moving is risky.
github has made it significantly easier for us to accept contributions from other individuals and companies. Like it or not, github has succeeded in making contributing to projects easy. If Pagure is just duplicating this functionality, fine, but that's not a good enough reason for us to change the development workflow. A large part of us wanting to move off Fedora infrastructure was the barrier to entry for gaining outside contributors. It was simply too high.
I didn't expect anaconda to benefit that much from github's network effects. But given that it is, that would make Pagure hard to consider soon. The hosting service (as opposed to code) requires FAS accounts which would be a barrier to entry for the many people that have github accounts but not FAS accounts. (And I wouldn't expect Github to ever help out by becoming an identity provider that Pagure could rely on in addition to FAS.)
I'm not saying yes or no regarding moving things off github, but just that there are significant benefits to github that are very beneficial to the project right now.
It does seem that way. But if you do see technology issues that could be improved in Pagure it would be nice to hear about them. (That you may notice when using it for some Fedora upstreams that are there.)
Thanks for elaborating on the benefits the anaconda project gets from github.
On Tue, May 24, 2016 at 2:16 PM, Bruno Wolff III bruno@wolff.to wrote:
On Tue, May 24, 2016 at 13:29:16 -0400, David Cantrell dcantrell@redhat.com wrote:
Changing the development workflow is not something we've ever taken lightly. There have been two major shifts in the last 10+ years. First was the move from cvs to git. The second was to move off Fedora infrastructure to github, and that decision wasn't just rushed through.
I wouldn't expect anything soon. Pagure has promise, but it is too soon to say where things are going to go, and without that assurance moving is risky.
Very true. We were considering gitorious at one point, but I'm glad we didn't.
github has made it significantly easier for us to accept contributions from
other individuals and companies. Like it or not, github has succeeded in making contributing to projects easy. If Pagure is just duplicating this functionality, fine, but that's not a good enough reason for us to change the development workflow. A large part of us wanting to move off Fedora infrastructure was the barrier to entry for gaining outside contributors. It was simply too high.
I didn't expect anaconda to benefit that much from github's network effects. But given that it is, that would make Pagure hard to consider soon. The hosting service (as opposed to code) requires FAS accounts which would be a barrier to entry for the many people that have github accounts but not FAS accounts. (And I wouldn't expect Github to ever help out by becoming an identity provider that Pagure could rely on in addition to FAS.)
It's been a surprise to a lot of us, actually. But everything from contributions from Fedora users (both FAS account holders and non-FAS users) to companies like Facebook contributing to anaconda, the visibility and accessibility is better than we've had through other means.
I'm not saying yes or no regarding moving things off github, but just that
there are significant benefits to github that are very beneficial to the project right now.
It does seem that way. But if you do see technology issues that could be improved in Pagure it would be nice to hear about them. (That you may notice when using it for some Fedora upstreams that are there.)
Sure. I need to look at Pagure again. It's been a few months. It would be nice for Pagure to gain some success stories for hosting projects. It took github and others a while to build that up.
Thanks for elaborating on the benefits the anaconda project gets from github.
No problem.
Thanks,
"BW" == Bruno Wolff bruno@wolff.to writes:
BW> I didn't expect anaconda to benefit that much from github's network BW> effects. But given that it is, that would make Pagure hard to BW> consider soon. The hosting service (as opposed to code) requires FAS BW> accounts which would be a barrier to entry for the many people that BW> have github accounts but not FAS accounts.
There has been talk of changing this. I know it was being worked on (by puiterwijk) but I don't know the status. Allowing multiple auth providers brings up a few issues (you have to namespace users) but I think there was a plan for dealing with that.
Anyway, if there's something that you need and pagure doesn't offer, I would suggest you make the pagure developers aware of that.
BW> (And I wouldn't expect Github to ever help out by becoming an BW> identity provider that Pagure could rely on in addition to FAS.)
Github supports oauth2; that should be enough, I think.
- J<
On Tue, May 24, 2016 at 13:57:27 -0500, Jason L Tibbitts III tibbs@math.uh.edu wrote:
Anyway, if there's something that you need and pagure doesn't offer, I would suggest you make the pagure developers aware of that.
I have been creating feature request issues. I have also been trying to help a bit with some existing issues, but have only been making progress slowly so far.
Github supports oauth2; that should be enough, I think.
As a provider or consumer? It would be really nice if they were a provider, but I wouldn't expect that as it would partly reduce their lock in from network effect. Though they do other things that help everyone.
"BW" == Bruno Wolff bruno@wolff.to writes:
BW> As a provider or consumer?
As far as I can tell, Github is an oauth provider. https://developer.github.com/v3/oauth/
My understanding of oauth is limited, though.
- J<
On Tue, 2016-05-24 at 14:15 -0500, Jason L Tibbitts III wrote:
"BW" == Bruno Wolff bruno@wolff.to writes:
BW> As a provider or consumer?
As far as I can tell, Github is an oauth provider. https://developer.github.com/v3/oauth/
I've seen websites where you can sign-in with a GitHub account so they probably really are a provider.
My understanding of oauth is limited, though.
- J<
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Wed, May 25, 2016 at 10:37:11 +0200, Martin Kolman mkolman@redhat.com wrote:
On Tue, 2016-05-24 at 14:15 -0500, Jason L Tibbitts III wrote:
> "BW" == Bruno Wolff bruno@wolff.to writes:
BW> As a provider or consumer?
As far as I can tell, Github is an oauth provider. https://developer.github.com/v3/oauth/
I've seen websites where you can sign-in with a GitHub account so they probably really are a provider.
When I followed the above link I found information that github encourages apps that let people do interesting things with their repo access. You need to have an app key to use their authentication. So if you wanted to use github's authentication to grow a competing service, they could shut you down. Pagure would only compete on some levels and they may not be worried about it. But it is still a risk.
On 05/25/2016 07:59 AM, Bruno Wolff III wrote:
When I followed the above link I found information that github encourages apps that let people do interesting things with their repo access. You need to have an app key to use their authentication. So if you wanted to use github's authentication to grow a competing service, they could shut you down. Pagure would only compete on some levels and they may not be worried about it. But it is still a risk.
fwiw gitlab.com uses github accts as one of its log in methods. direct competitor :)
~m
On Tue, 2016-05-24 at 13:57 -0500, Jason L Tibbitts III wrote:
"BW" == Bruno Wolff bruno@wolff.to writes:
BW> I didn't expect anaconda to benefit that much from github's network BW> effects. But given that it is, that would make Pagure hard to BW> consider soon. The hosting service (as opposed to code) requires FAS BW> accounts which would be a barrier to entry for the many people that BW> have github accounts but not FAS accounts.
There has been talk of changing this. I know it was being worked on (by puiterwijk) but I don't know the status. Allowing multiple auth providers brings up a few issues (you have to namespace users) but I think there was a plan for dealing with that.
Anyway, if there's something that you need and pagure doesn't offer, I would suggest you make the pagure developers aware of that.
While this is a bit off-topic, but still related to Pagure:
I've heard there have been plans to use Pagure to host the Fedora dist git repos, with the aim of enabling pull requests for packages.
IIRC the idea was to make packaging improvements and fixes easier. You would not need to pester individual maintainers via email/IRC anymore - just fire away a pull requests like with normal pull-request workflow. It could also possibly help ameliorate the "someone-touched-my-package" friction that sometimes shows up when proven packages modify other peoples packages.
As I find this to be a very interesting idea I just wanted to ask how this is coming along when there are Pagure People in the thread. :)
BW> (And I wouldn't expect Github to ever help out by becoming an BW> identity provider that Pagure could rely on in addition to FAS.)
Github supports oauth2; that should be enough, I think.
- J<
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
anaconda-devel@lists.stg.fedoraproject.org