Re: debian github organization ?
On 18 April 2015 at 08:03, Ben Finney <ben+debian@benfinney.id.au> wrote:
> Paul Tagliamonte <paultag@debian.org> writes:
>
>> So, yes, it's nonfree. Yes, it's controlled by DDs. No, I don't think
>> this should be the Vcs-Git: target. No, I don't think we should
>> endorse GitHub. Yes, we need free tools. Yes, we should contribute to
>> the F/OSS community where upstreams are.
>
> That last part seems to deny the D in DVCS. Why are we under such
> pressure to use one particular centralised service?
It doesn't deny it at all. Writing code is inherently distributed -
folk do it on their local machines. Other artifacts of software
development, like this mailing list and the Debian BTS, are inherently
centralised: they are discussions between actors, not local output.
> Upstream is using a decentralised VCS, it seems a little condescending
> to assume they are incapable of using it.
As has already been said, noone is making that assumption. For all
intents and purposes every upstream has made a decision about code
review and patch acceptance processes[*] and patches that don't follow
those processes incur a higher cost and increased likely hood of being
ignored. Those processes end up something like this:
- your patch should apply to branch X in repo Y before you send it.
- put your patches in place Z for us to find them [e.g gerrit at url
U, PR's at url U, mailing list x-y-z@example.com]...
- we'll discuss the patch using tool T
Absolutely none of those three things are distributed in nature. They
can be worked with with distributed tooling, but that is beside the
point - to work with upstream U, requires *working with upstream U*,
whatever their tooling is, wherever they are to be found. That is in
fact exactly what upstream means. Of course, some upstreams don't
document the process super-well, and some are more restrictive than
others (e.g. hg won't accept patches in their bug database - patches
have to go to the list). But there is a process, and its tuned for the
bottleneck that that project has.
To pick a specific example, if you want to get a patch into OpenStack
you *must*:
- sign up for the OpenStack gerrit system
- sign a CLA
- put your patch into git and push it into gerrit
Anything else simply won't be accepted.
*: A very very small number say 'any patch anywhere, we'll handle the
rest', or something similar.
--
Robert Collins <rbtcollins@hp.com>
Distinguished Technologist
HP Converged Cloud
Reply to: