Author Topic: Nightly builds page redesign (static HTML)  (Read 63310 times)

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 10183
  • 5D Mark Free
Re: Nightly builds page redesign (static HTML)
« Reply #75 on: March 28, 2017, 01:26:31 PM »
Added links to more ports in progress (actually "stalled" might be a better word for some of them) on the download page.

http://builds.magiclantern.fm/#ports-in-progress

Also added links to existing ROM dumpers:

http://builds.magiclantern.fm/#rom-dumpers


Andreasb242

  • New to the forum
  • *
  • Posts: 5
Re: Nightly builds page redesign (static HTML)
« Reply #76 on: July 25, 2017, 04:09:16 PM »
On the Top of the Page is written:

Quote
Main Builds
These builds have been around for some time, and they are unlikely to cause major issues.
In most cases, regressions are fixed quickly - if you report them.

I like this text, and think they are OK.

But the builds here display once a day the Warning message "This is a development snapshot for testing purposes." etc. (menuhelp.c, draw_beta_warning)

In my opinion, this is a inconsistency. I would remove this message from ML.
Or an alternative would be to display the history, if ML is updated (once, not every day), like some Android Apps does, and then the Text: "Please report all bugs at www.magiclantern.fm"

(Or change the nightly build, and defined CONFIG_RELEASE_BUILD?).

I know, it's a little bit offtopic, but I think the message should match the new Download page, even if the page is not that new anymore...

Andreas

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 10183
  • 5D Mark Free
Re: Nightly builds page redesign (static HTML)
« Reply #77 on: September 19, 2017, 10:37:57 PM »
Right, it's a good idea to update the message (maybe use a different one for experimental builds). However, before considering the builds as release, I'd like to:

1) fix the user guide problem;

2) make sure the builds are tested before posting; that was done manually years ago, when the feature set was small and I was working on 1 or 2 camera models; however, this approach no longer works (with hundreds of menu options - if not one thousand - and several modules, workflows, bleeding edge features and so on).

Made some progress for #2 - most of the nightly builds are now tested, to a limited extent, in QEMU.