Re: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5665] maps/tags/1.10/
Nicolas Weeger wrote: I think one major issue is how long it takes to make a release. For instance, I know there are some things to do for Windows server/client (and I will write that down somewhere!), but I don't know how long it takes. I know this release is taking a bit more time, but that is also because I'm documenting it. the arch and map stuff is pretty easy - it is basically make a copy to the branch, tar it up, and upload it. Even the server and client is pretty easy _if_ everything works correctly. The directions are basically update the configure.in, run autoconf, do make dist. The issue is when things don't work right - someone adds a file but forgets to update the makefile. Then you go through, fix that, repeat the steps, etc, and hopes it works. Also, for the client server, I do some extra checking, like can I run the client, log into the server, and have it work? Just a basic 'this isn't completely brain dead' type of thing. that takes some extra time, but after being hit one time with something being delivered that was braindead, it seems like a good idea. The time may also depend on your upload speed. Uploading 40 MB of map files takes a little bit of time on an ADSL connection. But in short summary, I'd say that normally it takes the good part of an evening to do a release (2-4 hours). If releases are done more often, I'd expect this to go down some - likelihood of release process getting broken is less when there have only been 20 changes and not 200, etc. IMO, what we should do is: * automatize to the maximum the release process. This can include writing sh scripts for Linux, scripts for Windows, and so on. [as a side note, I'm thinking of doing a small C program for Windows to replace the Perl script for maps, and make the build process more easy, ie change version numbers and such. C because Perl isn't needed, apart for arch collecting which i can do on my linux box) * time how much time a release takes * decide after we automate to the maximum :) See other post about automation. Certainly more automation can be done, and that shaves some time off. I suppose the main advantage of automation is it could be something that you do a 'make release 1.11', go to bed, and next morning, log on to find everything worked and the files are uploaded to sourceforge. At least for me, it may be a little while before I trust everything that much. And I'm sure it could be automated more - I think it basically came down to: A) Do a write a script to automate it more, which will take X amount of time to write and make sure it works B) Just do it by hand, where it takes Y more time than fully automated Where Y*NUM_RELEASES X, but unclear what value NUM_RELEASES are. it's also a matter of time concentration. If Y is 10 minutes, not a big deal - just means I go to bed a few minutes later, and shaving 10 minutes off probably means I go to bed 10 minutes earlier. if X is 90 minutes, that is enough time to actually do something relevant - look into fixing some bugs, writing new features, whatever else. I would aim for something like a release every 2 months. It may appear short, but if release process is automated well we don't take much time to release. It would enable us to have many tests and such. More frequent releases do also have the advantage that there is likely less breakage. Note that we should probably do trunk releases too, so people get to test it. The trunk releases get messy, because from what I recall, what we have right now in trunk may not be compatible with final release of 2.0 (in terms of maps, locations, etc). So it gets sort of tricky to put this out there, but don't rely on it too heavily, because things could change in incompatible ways. But that sort of discourages people from using it. Its sort of a different discussion, but the compatible breaking changes should probably be done as soon as possible, so that the rest of more tweaking, fixing bugs, etc. But time doesn't always work that way. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5665] maps/tags/1.10/
Kevin R. Bulgrien wrote: Log Message: --- 1.10 branch Hello. I (and I'm sure others) would have appreciated some notification of incoming 1.10 release, as I'm trying to fix some things related to Windows version of server. Could I ask for ~2 weeks notice before releases, so we can freeze stuff and fix critical/blocking bugs? Nicolas The old adage about CVS not being a replacement for developer communication likely applies well in this situation, IMO. 2 weeks not needed here as _any_ notice would be appreciated. I had two regressions to fix in maps. I could have had them fixed in a few hours, but had just discovered them through playtesting and was needing to experiment a bit to learn how to fix them. (I have fixed them now, but it is too late.) With 24 or 48 hours notice, these regressions might have been fixed for the release as I could have upped priority for hammering out a correction. I acknowledge it is my problem for not having tested well enough before committing. At the time I did test on my server, but did not have in mind the nuances of testing for hidden attribute changes that come in from the arch when switching out floor pieces. I know now, so hopefully it won't happen again. As said before in other thread, sorry about no advanced notice. If I knew I was going to make the release last weekend, I would have given advanced noticed. It just turned out that I found myself with the time to do the release when I sat down at the computer at the weekend. So I basically had these options: 1) Start the release process since I know I had time then. 2) Give notice about an upcoming release, and hope that I'd actually have the time to do it before when I said so. My estimated probability of this was low (and if the deadline is missed, it almost seems like the process is restarted, since at some point, the immediancy of a release coming out goes away. 3) Do neither - wait 2-3 months when I estimate I may have time, and schedule a release then (which would be when the release is done if I missed schedule on #2) IMO, none of those is ideal - the ideal is ability to announce I'll do a release in 2 weeks, and then actually do the release then. But as of right now, that seemed low. And since there were no docs, its not like I could point someone else to do the release in that timely fashion. Hopefully, since I'm writing docs, that may be more doable. Looking back, the only thing I might really change is perhaps saying something on irc like I'm going to do a release starting right now - if you have anything ready to commit, let me know now and commit it, to catch any of those ready to commit fixes (but that in itself can sometimes be dangerous). If I had a time machine, I'd send a note to myself 2 weeks ago to send mail to the list saying I'm going to do a release in 2 weeks. But I have to go on what I knew at the time, not what I knew later. Otherwise, I still think my decision to do a release now is better than waiting another 2 months for a release. Even though the code has some bugs, I'd say it is better than what is out there right now as 1.9.1, and at some level, getting code out there for others to use has some advantages. This is one of the arguments for frequent releases - sure, each build will have some bugs, and could be made better if delayed, but by getting the builds out there, you get people to discover some of those new bugs so that they can get fixed in the next release. If infrequent releases are done, quality may in fact not be better because people are stuck using an old buggy build for a longer time period. Now to turn this more constructive, I think the real question is: How often should we be doing releases? Every month? Every 3 months? Somewhere in between? I think anything more frequent then every month (save for critical builds/to fix something DOA) doesn't make much sense, as I don't think the 1.x branch is changing fast enough. I also think that less than every 3 months is too long a gap - just looking at the client, there were lots of things changed since the last release, such that if there were 3 releases in that time period, each would still have enough changes to be compelling. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5665] maps/tags/1.10/
Le dimanche 04 mars 2007 08:55, Crossfire CVS repository messages. a écrit : Revision: 5665 http://svn.sourceforge.net/crossfire/?rev=5665view=rev Author: mwedel Date: 2007-03-03 23:55:08 -0800 (Sat, 03 Mar 2007) Log Message: --- 1.10 branch Hello. I (and I'm sure others) would have appreciated some notification of incoming 1.10 release, as I'm trying to fix some things related to Windows version of server. Could I ask for ~2 weeks notice before releases, so we can freeze stuff and fix critical/blocking bugs? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'aléatoire !] ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
