TL;DR Dirk has answered with some reasons, already, but various responses from me:
Don Simons wrote: > I'm firmly and completely on the fence on this one. On one hand, on > general principles I suppose it would be nice and maybe even useful > to someone to have a formal PMX source code repository. On the > other, there are various issues: > (1) My own limited experience with github has been less than > thrilling Out of curiosity, what problems have you had - and would you be able to tell if they issues with Git or with GitHub? > (2) There hasn't been much action at all on PMX development for the > last 5 years or so. A source repository has other benefits, but I'll come to that in a bit... > (3) Part of the reason for (2) is that my own very robust FORTRAN > development system (Visual FORTRAN) will not run under Windows 7 > 64-bit, and I refuse to invest the $500 or so to upgrade it. For > the very limited features I've added since then, I've had to merge > all subroutines into a single file and use gfortran, which lacks a > useful debugging capability. Here both branches and clear history would allow that to be reverted if someone else came along, for example, who was willing to develop in a virtual machine - a branch allows you to park the original work as a "failed route" which someone else could pick up at a later date. > Another side of that coin is that PMX has reached a pretty stable > level of development. That's in many ways in an argument *for* having the repository - it puts the entire history out there for anyone else who wants to take it on. A few (well, a lot) of zip files in an Apache-generated directory says "abandoned", not "stable". > (4) Judging from the activity on the mailing list, not many folks at > all are using PMX. A minor GitHub "whistle" (as in bells-and-whistles) is that people can "star" (favourite) repositories and you also see if anyone forks it on GitHub to work on it, so you get a bit more activity. Mailing lists aren't great pulses for stable projects! > I could possibly be convinced to pursue this, but I'm not at the > moment. If someone else wants to take the reins, be my guest. Let's see :o) Bob Tennent wrote: > The source packages are at WIMA and the current packages are also at > CTAN and texlive. The build systems for musixtex, m-tx and pmx are > on my work computer, which is well backed-up, with back-up tapes > stored off-site. The distributed backup benefits weren't a major one I was considering, although the way you're doing it at the moment means that (publically) only releases are backed up - any interim work you do is lost if you "disappear" (morbid, but sad history for this project, of course...) > The authors of m-tx and pmx have already decided. I've been > thinking about whether there would be any benefit to moving musixtex > and the build systems for m-tx and pmx to github. > > David: What would be the "myriad benefits"? Git was designed for > distributed development, which seems unlikely at this stage. Dirk has already covered some of this, but here are various thoughts and observations based on things that have happened on this list, including some in the last few days. http://icking-music-archive.org/software/ is, for want of a more delicate word, a mess (please don't you or Christian take that insultingly - I'm trying to illustrate how GitHub or similar would be better for no extra day-to-day work, not score points). It lacks instantly visible documentation, there aren't even file dates displayed by default - for example, while trying to look in the pmx folder to see what version Don meant by "five years ago", I had to download every PMX zip to look in them. At the very least, GitHub's ability to display the contents of a README.md file in each directory would mean that repositories laid out on there would have a vastly superior browser than Apache directory view. GitHub's organisation model allows all the various separate repositories to be grouped in one place. The distributed model of Git means that that can be done regardless of whether the original authors "want it" - it's a matter of management whether, for example, www.github.com/tex-musix/M-Tx is the main repository and www.github.com/dlaurie/M-Tx is simply Dirk's working copy, or www.github.com/dlaurie/M-Tx is the main repository and www.github.com/tex-musix/M-Tx is simply a mirror (it's even possible to automate tex-music/M-Tx pulling any updates Dirk makes). I've already mentioned that GitHub's view of a repository would mean that, say, http://icking-music-archive.org/software/pmx would be mapped to the Git repository and the individual zip files for versions download! ed using GitHub's release system (GitHub allows for a given repository, say, www.github.com/tex-music/musixtex the equivalent www.github.io/tex-music/musixtex to be a website backed by the a branch called gh-pages. github.io sites are permitted to contain binary release files. Again, the benefit of the GitHub pages model is that *anyone* can submit a pull request to it - so if someone happens to find a clearer way of laying out some website information, or corrects a typo, instead of tediously having to write an email to a maintainer to describe the change, you make the change in a local copy, push it to GitHub and make a pull request - and then all the maintainer has to do is accept the alteration. Other benefits: ** Issue tracking / pull requests. My recent post, for example, where I have added poor support for a new kind of barline would be better maintained as a "pull request" - so my changes would be visible to anyone else who might want that feature and could pick up the work and continue it if they wished (that's a Git benefit). GitHub also provides a great user interface for viewing the patch so you can see the lines. So if someone else happened to come along in the future wanting half barlines, they might also spot that MusiXTeX doesn't (yet) have it, see that there's an open issue and either comment on it or, even better, clone the work and finish it! This would probably have also helped Dirk with the issue with etex, too - rather than posting a patch/fix on an emailing list, it's incredibly easy to open a GitHub pull request with the change - it would either have been merged at once, or at the very least left open as an "Issue" with M-Tx to remind someone either to fix it completely or to merge it at a later date. Instead, because it's just in an email, we have to search archives to find it - and we're all human, so remembering something from 4 years ago is not necessarily going to happen! Again, committing a change to a source repository is so much faster than cutting a full release, that it also means that the work and change gets done at once, rather than having to be added to a ToDo list (or not). Note that I'm not suggesting doing away with the mailing list - it's common in other projects that you make a pull request and then announce it on the associated mailing list to draw comment. It's also quite common that discussions which start on the mailing list end with "please open an issue in our tracker [on GitHub]". ** Precise change history Looking in 1.18, there are 4 distinct changes, but all I can look at to see what they mean is to compare it to 1.17, and for that I have to download both zips and then use a comparison tool (the word tedious doesn't cover it...). Using Git, you would have made these as (at least) 4 separate commits) - each commit has an author (providing a certain amount of useful credit or accountability) and a committer - indicating who "approved" or merged the change into musixtex. Additionally, both Git's visualisation tool (the gitk command) and GitHub's comparison tool allow you to see precisely what lines of code have been altered and the grouping into commits means that you can see which changes belonged to which feature. This is vastly more precise than a change log or version comments peppered throughout the code. It also allows you to track when several features grouped in the same release change the same macro or line of code. One of Git's *amazing* features is bisecting - so you discover that a PMX/MTX/TeX file which worked before no longer compiles. Git automates the process of marking at which point in MusiXTeX's development it last worked and then helps you with a binary search of all the changes made since then to home in on what broke it - and then, if you've maintained "single feature" commits, you can hopefully see from the patch quickly why something broke. At the moment, you can rollback to previous versions - with a proper development history you can find the actual change that broke things. That would have been great when I was helping Don a few months ago with some jazz-related macros - there was a difference between my slightly out-of-date MusiXTeX installation and his current one; git bisect, the visualisation tool and/or git blame (which shows when each line of a file was last changed) would have been considerably faster than downloading four zip files of releases in order to see how an internal macro had been updated. Similarly, git diff (a normal command you run before commit code changes, because it shows you which lines of code you have altered) would probably have alerted you to the typos you found in 1.18 today... it would also allow you very rapidly to push a commit to a new branch, providing a better workaround to rolling back to 1.17 while you cut a full release (not that this is the kind of project where things need to be fixed insanely fast, obviously!). ** Distributed development As Dirk already pointed out, MusiXTeX's development in pretty much all of its tools is already distributed. I have to say, as someone who travels a lot and so is often working with either no or a flaky internet connection, the principal benefit of Git to me is that it also works offline - you're always working in your local copy and then, once back online, I just have to issue `git push origin', and everything gets uploaded to the public repository. ** Exposure I'm not some tedious Silicon Valley evangelist for the latest and greatest open source tools, but visibility is useful - Git and GitHub make the barrier to submitting changes and discussing issues absolutely trivial. There is always a real chance that new people will discover and contribute to MusiXTeX's and its related tools simply by better access to its development - I'm not a particularly active open source developer (my main job is singing...), but if you look at my GitHub repositories at www.github.com/dra27 you'll see that 13 of them are forks of other people's work, mostly where I was contributing trivially small changes (often to do with correcting builds of things on Windows) - GitHub allows the process of getting the code and communicating the changes back to be trivial, which provides a lot of encouragement for actually working on the change! I spent years having to prepare patch files manually and email developers - being able to do that trivially for most proje! cts makes it very painful when forced to work on one which hasn't made the leap. ** Continuous Integration Given the complexities of cross-compiling the various binaries, another advanced option that's relatively easy with GitHub is continuous integration - you configure a (free) system (the common ones are Travis for Linux and Appveyor for Windows) which tests every change suggested - it means that if, say, someone contributes a macro to MusiXTeX, you can run tests to ensure that known test files still TeX properly or, say, a change to PMX still compiles for *all* platforms. I'm very happy to put some time into setting things up, but it's obviously not worth doing unless primary maintainers are willing to switch too! The main thing would be working out where the content of each and every file in http://icking-music-archive.org/software/ would want to go and whether there are any private intermediate files which would want to be merged. Hope that illuminates, and apologies for its considerable length!! David > -----Original Message----- > From: TeX-Music [mailto:[email protected]] On Behalf Of Dirk > Laurie > Sent: 26 November 2015 05:12 > To: Werner Icking Music Archive > Subject: Re: [Tex-music] Source code repositories > > 2015-11-25 6:00 GMT+02:00 Bob Tennent <[email protected]>: > > > David: What would be the "myriad benefits"? > > Git was designed for distributed development, > > I have found Git useful even when I am the only developer. > > (a) It forces me to think in terms of goals. > (b) It provides multi-stage backup. > (c) I write better documentation. > > Even if what you are backing up is not programming at all, say you are an > author writing a novel, a Git repository on another machine of your LAN is > a good way to back up. > All very well to do nightly rsyncs, but all you achieve when you have made > a mess-up that takes two days to discover is to have automatic second copy > of the mess. > > > which seems unlikely at this stage. > > I'd say that when two authors only take responsibility for keeping > respectively Fortran and Pascal code up to date, and someone else turns it > into C and provides user-friendly drivers, we are well into distributed > development already. In the early days of M-Tx the README was full of > stuff about workarounds and DOS/Windows/Linux specifics. I'm very grateful > that I don't need to bother about that any more. > ------------------------------- > [email protected] mailing list > If you want to unsubscribe or look at the archives, go to > http://tug.org/mailman/listinfo/tex-music ------------------------------- [email protected] mailing list If you want to unsubscribe or look at the archives, go to http://tug.org/mailman/listinfo/tex-music
