Oh, and a P.S. that your signature made me think about:
I'd be more than happy to contribute to the newsletter, just as soon as I do something newsworthy!
Jim (JR)
For people who don't know, a build server talks to some slaves, and
grabs/builds/tests/packages code. The current server is talking to one slave,
which is an Ubuntu VM which is building Tim's 'next' branch on Gitorious.
The objective of such systems is that there should be *zero* human steps to
create a release - not just out of laziness, but for repeatability. I.e don't
write a checklist or 'howto' of creating a release, write a shell script that
does the steps. (Or several). And check those scripts into a source control
system, too.
'Soon' I will be setting up a WinXP slave, with a MinGW build. Hopefully this
will even extend to a NSIS installer script, if Fred has one lying around. At
which point we should have nightly installers available for Windows, and a
happier Fred. (A VisualStudio build is also possible, but requires more
interaction with someone else, who has an externally-addressable/tunnel-able
box with VS installed).
(any slave could be a VM, of course - they use CPU while building, but unlike
other projects, our commit rate isn't that high - the slaves will be idle most
of the time)
(A Mac slave is also possible, but requires some more work, I will worry about
it assuming people want to pursue this whole concept)
Build jobs can run arbitrary shell scripts - they can tag things in CVS or Git,
they can create tarballs, upload files to SFTP/FTP servers, the works. So, if
Durk/Curt/Fred could codify, somewhere, the steps (in terms of 'things doable
in a shell/.bat script') to create an FG pre-release and final-release, I am
happy to do the work to get the process automated.
At which point, doing a release means clicking a button on a webpage (on
Hudson), and letting the slaves grind away for an hour or so. Magic!
(Another thing the server can do, is email/IRC people when the build breaks on
Linux / FreeBSD / Mac / Win due to a commit - obviously very handy for the
devs. Yet another thing it can do is run test suites - unfortunately we don't
have many such tests)
(If anyone wants to get into providing nightly .debs or .rpms, that could also
be done, but requires people who know those systems, and again can provide a
suitable externally address slave to run the builds)
James
FredB wrote:There is already an inno-setup script in Packages/ that builds fgsetup.exe,
with data, but for snapshot builds, I only make zip files of exe and dll,
including fgrun. You can see by yourself by downloading from
ftp://ftp.ihg.uni-duisburg.de/Flightgear/Win32 . There is a wiki page that
describe how to stay current under Windows.
Regards,
-Fred
Hooray wrote in Sun Apr 21, 2013 9:12 am:As far as I know, the build server is run by a contributor from the US, you should probably get in touch via eMail to "donate" software for other environments.
However, as far as I understand, the VM image is merely used to CREATE a new package/installer, but not to literally test it:
http://www.mail-archive.com/flightgear- ... 27592.html
(Inner Quote)
For people who don't know, a build server talks to some slaves, and
grabs/builds/tests/packages code. The current server is talking to one slave,
which is an Ubuntu VM which is building Tim's 'next' branch on Gitorious.
<snip>
'Soon' I will be setting up a WinXP slave, with a MinGW build. Hopefully this
will even extend to a NSIS installer script, if Fred has one lying around. At
which point we should have nightly installers available for Windows, and a
happier Fred. (A VisualStudio build is also possible, but requires more
interaction with someone else, who has an externally-addressable/tunnel-able
box with VS installed).[/b]
(back to outer-level quote again)
Regarding your apology: it's an unfortunate truth that the project is shouldered by very few people, obviously "new"community members tend to look for those contributors who have a certain track record, and responsiveness - which certainly applies to people like Stuart and Zakalawe who are both going out of their way to interface between the developer/end user community, and whose degree of responsiveness is by far above what you can usually expect from other core developers, i.e. an unfortunate imbalance here - in that the more you do, the more fronts you gotta handle in the end . So there's that... And you'll probably come to notice that first hand, once you stick around - so that people will get you involved regarding documentation/installer issues
Talking to zakalawe via some PM's, there is obviously a LOT I have to learn. And I thought LaTeX was hard! (laughing!)
Likewise, who is this "contributor from the US", and how do I contact him?
since it will never catch an installation that violates Microsoft's new requirements.
This is why I want to put a later copy of Windows into your hands. With this, you can build on a more current system, catch potential installer build "gotchas", and still have a build that will successfully test on an XP system.
do you folks have a software signing certificate?
I'll probably have to go talk to the guys over at Commodo and see what I can do. They know me, and maybe we can do business.
I don't think I will be able to pound out code right away - there is a lot of research and a rather steep learning curve I will have to climb first.
jharris1993 wrote in Mon Jan 09, 2017 7:46 pm:[...] it's just that it makes no sense for me to document a moving target. Once there's something worth documenting, I'll break out the word-processor and do it.
Hooray wrote in Mon May 06, 2013 4:43 pm:It would be also good to know if there's anything we can do to avoid the "force 32/64 bit" issue, that's been raised by a number of users:
http://flightgear.org/forums/viewtopic. ... 23#p182923
http://flightgear.org/forums/viewtopic. ... t=#p182759
http://flightgear.org/forums/viewtopic. ... t=#p182724
Note: You will find articles on the Internet advising you to turn System Restore off for one reason or another. They allege it will speed up your system, (false), or that you will recover tons of disk space, (only partially true), or that it's undesirable for this or that reason, (absolute B.S.). They actually have the gall to suggest that you should destroy your first line of defense against system destruction to gain some nebulous - and often minimal - improvement to your system. Which, In My Humble Opinion, is absolute insanity!
. . . . .
It is my humble opinion that - if you need to dump something - dump all that worthless advice instead of System Restore.
Users browsing this forum: No registered users and 2 guests