Preparing for the next Deviation release

It's been about a year since I've done a significant amount of coding on Deviation, and I've been out of the loop entirely for the past several months. So I'd like to get a feel for where the nightly builds stand. Those of you who have been actively working on the code: what do you think should be done before we release, or are things in good enough shape as they are?

either install OpenOffice/LibreOffice or use a portable version. Grab the fodt file from:
bitbucket.org/deviationtx/deviation-manual/

make your changes (to both 8 and 10 files), and check it in.

Alternatively, just tell me what you want to do, and I'll make the changes.

yes my plan is as follows:
1) create a new 'releasecandidate' branch from trunk
2) build a 4.1-RC1 from this branch
3) pull fixes from trunk (cherry-pick if needed) into the branch
4) release once documentation is updated and sufficient testing has occurred

With the group methodology, I'd like to keep the RC process separate from trunk because I don't know how long it'll take between RC and release, and it is good practice with multiple committers. Depending on how it works out, we'll adjust the process. There won't be any permission restrictions, but any fixes need to go both to trunk and to the RC branch.

I'll wait to hear from Indigo before making the rc branch.

As for documentation, there aren't enough users working on it that I think it is worth changing the methods now. Just checkout from the trunk, make your changes and check them back in. If we run into merge conflicts it is possible to diff the files and do merges, though I generally just do it by hand as otherwise formatting gets messed up.

We should put together a full list of changes, as that is needed for release anyway, and also will help drive documentation changes.

I got the default icons from here:
www.iconarchive.com/show/transport-for-v...t/airplane-icon.html
(you'll see the heli one there too as well as the b&w ones I think)
I don't see anything that would work for a multi-rotor though.

They key is to make sure any icon is licensed as free for non-commerical use.

The auto-build infrastructure could easily build multiple branches. Uploading them to the website would take a little work to fully automate (since we probably need to manage category creation/removal).
Today the builds are nightly. that may make test builds less useful as you need to wait upto 24hrs before anyone can test them, and you get no feedback about a build-failure. I could possibly add build on commit support, or even better build-on-demand, but then I get into more complicated infrastructure.

What is your anticipated work-model? Is it just making it easier for developers to publish changes for testing?

for the RC case, my plan was just to run a 2nd auto-build cron off the release_candidate branch, but we could do something more sophisticated if there is value add.

I added the ability to auto-build and install test builds to the build daemon.
you will be able to find them here once they exist:
www.deviationtx.com/downloads-new/category/32-test-builds

I haven't decided how I want to track which builds to autobuild.
Using branch-name is one option, but it isn't ideal as branches are immutable in hg so turning the autobuild on/off may not work well.

Having txt file would be easy, but it would bump the trunk version needlessly when adding/removing branches to build

Using hg bookmarks would probably work well, but I'm not very familiar with them, and they don't seem to play well with branches.

For now, I have a textfile on my build-machine with a list of branches to auto-build (currently empty).

I need to address build failures somehow. I'm thinking of auto-creating a bug for each failed build (based on the commit-id) and adding all group members as monitors. There was a commit today that broke the Devo12 build, and I wouldn't even have noticed except that I was working on the build daemon just afterwards. We all make mistakes, so it isn't a big deal, but with multiple users committing to the code now, I don't want to be the gatekeeper to getting builds published.

I like that solution.
Members of the bitbucket group should now have a 'Upload Build' menu item after you select 'Downloads' (look in the left-hand link bar)
you should be able to upload builds from there that will show up in 'Test Builds'
Let me know if you see any issues when using this.

what do you mean by '2 zips'? Do you mean the filesystem + the dfu? or do yu mean one for devo10 and one for devo8.

The autobuild runs using:
make INCLUDE_FS=1 zips winzips

I used to use 'make release INCLUDE_FS=1' but with the new build system, I don't really see the point of the release target anymore, and am not sure it is updated.

which creates one zip per platform containing both filesystem and dfu. But usually for testing you shouldn't need a new filesystem which is why this isn't default.