| 1 |
Dnia 2015-02-15, o godz. 18:05:01 |
| 2 |
Andrew Savchenko <bircoph@g.o> napisał(a): |
| 3 |
|
| 4 |
> On Sun, 15 Feb 2015 14:50:27 +0100 Michał Górny wrote: |
| 5 |
> > Dnia 2015-02-15, o godz. 15:39:58 |
| 6 |
> > Andrew Savchenko <bircoph@g.o> napisał(a): |
| 7 |
> > > On Sun, 15 Feb 2015 10:55:41 +0100 Alexey Lapitsky wrote: |
| 8 |
> [...] |
| 9 |
> > > Is Gentoo willing to say "no" to the software freedom and its own |
| 10 |
> > > social obligations in order to make contributions easier in the |
| 11 |
> > > simplest way possible? |
| 12 |
> > |
| 13 |
> > Please explain me, how *exactly* does allowing contributions via |
| 14 |
> > proprietary platform hurt free software? |
| 15 |
> |
| 16 |
> If this platform will become a de-facto common way to made |
| 17 |
> contributions (and this may happen taking into account github's |
| 18 |
> popularity), then platform unavailability or policy changes may |
| 19 |
> hurt the whole development process. |
| 20 |
|
| 21 |
Sure. So what's the alternative? Not getting the contributions |
| 22 |
in the first place? |
| 23 |
|
| 24 |
If users are willing enough to contribute without GitHub, then GitHub |
| 25 |
availability doesn't really impact that. If it becomes unavailable, |
| 26 |
the contributions may require some more effort for them but they'll do |
| 27 |
it. |
| 28 |
|
| 29 |
Of course, some users will decide it's no longer worth the extra effort |
| 30 |
to contribute if GH becomes unavailable. But then, those people |
| 31 |
wouldn't contribute if we didn't ever use GitHub either. So either way, |
| 32 |
we lose. |
| 33 |
|
| 34 |
And yes, we are already getting contributions via GH we wouldn't get |
| 35 |
other way. Because it's low effort enough for people to submit trivial |
| 36 |
fixes. The alternative of opening bugs and attaching patches, |
| 37 |
and the package maintainers ignoring them is not really welcoming. |
| 38 |
|
| 39 |
That said, I'm willing to accept contributions via any media as long |
| 40 |
as it's remotely sane on my end. Feel free to open a mailing list to |
| 41 |
accept patches/pull requests. Or any other patch review framework |
| 42 |
as long as it's relatively sane and works. |
| 43 |
|
| 44 |
Just don't require contributors to do too much. Yes, git can do plain |
| 45 |
pull requests but you have to have somewhere to pull from first. Not |
| 46 |
every user has a private git hosting. Sure, they could ask you to pull |
| 47 |
from github... but what's the difference then? |
| 48 |
|
| 49 |
The risk of being unable to using something in the future should not |
| 50 |
prohibit people from using its benefits right now. |
| 51 |
|
| 52 |
> Please forgive me for repeating myself once more, but I was |
| 53 |
> directly asked "how", so... Github is not just a git server, this |
| 54 |
> is a platform with numerous instruments and auxiliary data. In case |
| 55 |
> of any negative change all these data (issues, code reviews and so |
| 56 |
> on) will be lost. And there is no clean way to migrate these data |
| 57 |
> to another facilities. Thus we will have a classic web-based |
| 58 |
> lock-in with all lock-in driven consequences. |
| 59 |
|
| 60 |
That's a problem with every solution. If you migrate to another one, |
| 61 |
you may have trouble moving the data. If the hard drive fails, you lose |
| 62 |
the data since last backup. And finally, if you get too much data, you |
| 63 |
lose it anyway because nobody cares to dig up what you're looking for. |
| 64 |
|
| 65 |
-- |
| 66 |
Best regards, |
| 67 |
Michał Górny |
Archives