Loading
#openttdcoop - Paste
Archives
Trending
Docs
Login
ABAP
ActionScript
ActionScript 3
Ada
AIMMS3
ALGOL 68
Apache configuration
AppleScript
Apt sources
ARM ASSEMBLER
ASM
ASP
asymptote
Autoconf
Autohotkey
AutoIt
AviSynth
awk
BASCOM AVR
Bash
Basic4GL
BibTeX
BlitzBasic
bnf
Boo
Brainfuck
C
C#
C (LoadRunner)
C (Mac)
C (WinAPI)
C++
C++ (Qt)
C++ (WinAPI)
CAD DCL
CAD Lisp
CFDG
ChaiScript
Chapel
CIL
Clojure
CMake
COBOL
CoffeeScript
ColdFusion
CSS
Cuesheet
D
Dart
DCL
DCPU-16 Assembly
DCS
Delphi
Diff
DIV
DOS
dot
E
ECMAScript
Eiffel
eMail (mbox)
EPC
Erlang
Euphoria
EZT
F#
Falcon
FO (abas-ERP)
Formula One
Fortran
FreeBasic
FreeSWITCH
GADV 4CS
GAMBAS
GDB
genero
Genie
glSlang
GML
GNU/Octave
GNU Gettext
GNU make
Gnuplot
Go
Groovy
GwBasic
Haskell
Haxe
HicEst
HQ9+
HTML
HTML5
Icon
INI
Inno
INTERCAL
Io
ISPF Panel
J
Java
Java(TM) 2 Platform Standard Edition 5.0
Javascript
JCL
jQuery
KiXtart
KLone C
KLone C++
LaTeX
LDIF
Liberty BASIC
Lisp
LLVM Intermediate Representation
Locomotive Basic
Logtalk
LOLcode
Lotus Notes @Formulas
LotusScript
LScript
LSL2
Lua
MagikSF
MapBasic
Matlab M
Microchip Assembler
Microsoft Registry
mIRC Scripting
MMIX
Modula-2
Modula-3
MOS 6502 (6510) ACME Cross Assembler format
MOS 6502 (6510) Kick Assembler format
MOS 6502 (6510) TASM/64TASS 1.46 Assembler format
Motorola 68000 - HiSoft Devpac ST 2 Assembler format
Motorola 68000 Assembler
MXML
MySQL
Nagios
NetRexx
newlisp
nginx
Nimrod
NML NewGRF Meta Language
NSIS
Oberon-2
Objeck Programming Language
Objective-C
OCaml
OCaml (brief)
ooRexx
OpenBSD Packet Filter
OpenOffice.org Basic
Oracle 8 SQL
Oracle 11 SQL
Oxygene
OZ
ParaSail
PARI/GP
Pascal
PCRE
per
Perl
Perl 6
PHP
PHP (brief)
PIC16
Pike
Pixel Bender 1.0
PL/I
PL/SQL
PostgreSQL
PostScript
POVRAY
PowerBuilder
PowerShell
ProFTPd configuration
Progress
Prolog
PROPERTIES
ProvideX
Puppet
PureBasic
Python
Python for S60
q/kdb+
QBasic/QuickBASIC
QML
R / S+
Racket
Rails
RBScript
REBOL
rexx
robots.txt
RPM Specification File
Ruby
Rust
SAS
Scala
Scheme
SciLab
SCL
sdlBasic
Smalltalk
Smarty
SPARK
SPARQL
SQL
Squirrel Script
Squirrel Script with OpenTTD AI/GS
StandardML
StoneScript
SystemVerilog
T-SQL
TCL
Tera Term Macro
Text
thinBasic
TypoScript
Unicon (Unified Extended Dialect of Icon)
Uno Idl
Unreal Script
UPC
Urbi
Vala
vb.net
VBScript
Vedit macro language
Verilog
VHDL
Vim Script
Visual Basic
Visual Fox Pro
Visual Prolog
Whitespace
Whois (RPSL format)
Winbatch
X++
XBasic
XML
Xorg configuration
YAML
ZiLOG Z80 Assembler
ZXBasic
News page: Last weekend OpenTTD migrated his source (SubVersion) and bugs (FlySpray) to GitHub (https://github.com/OpenTTD/OpenTTD). This change was long overdue, and we finally did it. What changed for you? (biggest changes) - Issues now on https://github.com/OpenTTD/OpenTTD/issues - Source now on https://github.com/OpenTTD/OpenTTD - Patches you have can be posted on https://github.com/OpenTTD/OpenTTD/pulls - Big cleanup of issues and patches - Rework of how we create binaries; soon (tm) we can easier produce binaries for forks, including Patch Packs. More details can be found in the forum post (link). Forum post with the title: "OpenTTD Source migration and other things that are changing" Last weekend OpenTTD migrated his source (SubVersion) and bugs (FlySpray) to GitHub (https://github.com/OpenTTD/OpenTTD). A change was long overdue, and after months of slow-chatting ideas back and forward, last month we finally reached a discussion: we are migrating to GitHub. This migration took a few weeks of preparation; and we are still in the aftermath of putting the dots on the i. But the result is very pleasing, and we hope you will like it to. So what has changed? We ditched Subversion, and now use git. git has been widespread used for years now, so although we understand it will take a bit of time getting used to, there are plenty of manuals around to get you started. I strongly advise you to read the Guides of GitHub. It is really good for the basics. (https://guides.github.com). The benefits for git over subversion are ample; to name a few: local repositories, your own branches, decentralized, local history, .. Next we ditched FlySpray, and are now using GitHub Issue tracker. FlySpray was on the list for replacement for years. It hasn't been maintained upstream (well, recently there are some commits; but nothing that changes the issues we are having). A replacement was hard to find; but GitHub Issue Tracker is sufficient for what we want. But more importantly, GitHub has Pull Requests. This replaces "patches" on FlySpray. The way OpenTTD was handling patches was very old .. and badly needed replacement. The inability to leave in-line comments and to see what changed was really hurting reviews, up to the point where they didn't happen. The other big change here is that Pull Requests are now validated by the Continues Integration before they are merged; meaning master (or what used to be trunk) is a lot more stable, and reviewers of Pull Requests have less things to worry about (they can see it compiles on a various of compilers/platforms, instead of finding that out themselves). In other words: the workflow for patches is now drastically improved; and we can see that over the last few days. The migration to GitHub has also another reasoning: it is much more open and reachable for other people. GitHub is very well known for a lot of developers; this means that we reach more developers that "just make a PR to fix this tiny thing". And because reviewing is easier, it is also much more likely to be accepted. Win-win-win-win. The last few weeks we have been working on scripts and scenarios how to get here. We imported all FlySpray issues, closed or not, to GitHub. Next, the last week, we have been cleaning up all the issues on GitHub. We looked at what could be closed, what needs attention, etc. We are down to 235 issues at the time of writing, and we plan to prune it down even further. We also use a new policy in regards to closing issues; keeping issues around with "a good idea" or "not really a bug but we should maybe fix it" turns out to have the reversed effect: nobody looks at it anymore. Although we really appreciate feedback and ideas, we will close enhancement requests that we don't expect to fulfill in the next year. Also bugs that are not really bugs but feature requests, are much more likely to be closed with the message: "we are going to pass on this one; thank you though". Many of those ideas etc do have a place on the forums; and if enough people like it, someone will stand up and make it :) We just don't want the Issue Tracker to become a huge sinkhole of endless ideas nobody is going to do anything with. During this cleanup we found 35 tickets that went under the radar and still need triage. We invite anyone to help us with that. We are down to 65 enhancements, 46 tickets we consider "good first issues", 136 (most likely) real bugs, and still have to process 69 patches that were imported from FlySpray. The latter is a bit difficult, as we would much rather prefer that the original author make the Pull Request than we. But slowly we will work on the list, and make a Pull Request ourselves. This will take some time. We also have been working on making a better more robust Compile Farm. The old one wasn't really maintained, and most targets don't support C++11, let alone C++14 or C++17. This is hurting development. So what we did over the last few months, is dockerize the Compile Farm, and put the source up (on GitHub of course): https://github.com/OpenTTD/OpenTTD-CF/. This is still being worked on, and one of the priorities of the next few weeks. These dockers allow you to locally build the exact same binaries as we do for releases, but also to validate your code under other compilers and platforms. These validation dockers are now attached to Pull Requests (via a Jenkinsfile), and every Pull Request is validated by them. And this comes back to the earlier point: developers see issues faster, meaning they need less time doing "housekeeping", meaning they have more time doing to good stuff: accepting Pull Requests ;) The other thing we are working towards, is making it possible for anyone to easily get release binaries for their fork. This is mostly for Patchpacks, but also for big new features which needs good user-testing (NRT, for example). We are attempting to allow with some simple administrative actions the Compile Farm to create those binaries, and make them publicly available. This of course means that "official" OpenTTD gets into competition with Patchpacks; and we approve of this. We are fully aware it can lead to a Patchpack being more popular than "official" OpenTTD; and we will be upfront about that. This does need some drastic code changes; for example savegames are currently not compatible between Patchpacks and "official" OpenTTD, and merging from one to the other can lead to nightmares in savegame compatibility. There are already solutions in Patchpacks available, and we will actively work towards getting them in the "official" OpenTTD. In closing, OpenTTD for years has been doing everything "on its own". For the longest time this was needed, as nobody could supply what we were looking for. But the world has caught up; GitHub is supplying us with everything we were looking for. It is a change, a huge change, but we truly believe it will lead to a better place; both for OpenTTD and all its fans, but also for all the developers out there. If you are interesting in helping out finishing this migration, please step forward (get to IRC, and start talking). Mainly if you like Docker, if you are interested in cross-compiling, know how to use MSBuild from PowerShell, like writing documentation (like CONTRIBUTING.md or README.md), enjoy cleaning up issues, know how to triage issues, etc. tldr; put up or shut up. things are changing. get moving. Or to leave it in the words of andythenorth: We have moved the OpenTTD repo to Github. It was probably overdue. Things will be better. We tried not to kill any kittens in the process.
Mark as private
for 30 minutes
for 6 hours
for 1 day
for 1 week
for 1 month
for 1 year
forever