On 18 April 2015 at 08:03, Ben Finney <ben+deb...@benfinney.id.au> wrote: > Paul Tagliamonte <paul...@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-...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ3HoZ0yS=gteouknvpsr9c_tsekk2rufyvvcgmqq74a6e_...@mail.gmail.com