sjek wrote:are you meaning the gettrought of reported and solved issues in changelog?
No, I mean our RC packages being tested before being released. Case in point from 0.40.0:
The Windows packages were build without any testing. We encountered a delay because there was no confirmation if they even work. Even now, I don't know if the 32-bit build even runs.
The Linux tar.gz binaries needed extra instructions for libraries that needed to be installed with them. This wasn't caught until far too late in the release process, and only my own tardiness on the release afforded us to get a note written in the release log in time.
And these are far from the first issues we have had with testing RCs. Again, I am not trying to blame the release packagers. The fault, if anyones', is completely mine. But that's why I am here banging on pots and pans to get our release process changed.
The Windows packages were build without any testing. We encountered a delay because there was no confirmation if they even work. Even now, I don't know if the 32-bit build even runs.
there was plenty on 64 and sorry for vague 32bit testing. they have been running good. this time there was 3 test version without rc tags. in confused a bit.
otherwise one way would be to make suggestion that report even that it works without any error or go crazy and ask reddit to test making clear to everybody that it's only just testing phase. with so many different distros and building taking possibly hours it would be needed to make reddit or longer time rescruitment anyway or new forum group : )
sjek wrote:otherwise one way would be to make suggestion that report even that it works without any error or go crazy and ask reddit to test making clear to everybody that it's only just testing phase. with so many different distros and building taking possibly hours it would be needed to make reddit or longer time rescruitment anyway or new forum group : )
And that's why my Option 2 suggestion includes a testing group. Putting some dedicated hands on that task would make a huge different. But I don't think it would be a good idea to publicaly test our "alpha" pre-releases. That's just excessive and unnecessary. One tester for each platform would be enough.
sjek wrote:are you meaning the gettrought of reported and solved issues in changelog?
No, I mean our RC packages being tested before being released. Case in point from 0.40.0:
The Windows packages were build without any testing. We encountered a delay because there was no confirmation if they even work. Even now, I don't know if the 32-bit build even runs.
The Linux tar.gz binaries needed extra instructions for libraries that needed to be installed with them. This wasn't caught until far too late in the release process, and only my own tardiness on the release afforded us to get a note written in the release log in time.
And don't forget auto-upgrading to 0.40 through PPA completely paralyzing the entire package manager if you had 0.39 installed at the moment of upgrading
If we want to do this, a first step would be to set up a "Team" forum which can only be seen (and accessed) by team (or "proven") members. There, we could coordinate the releases, discuss and tag the process on each release, review the videos, mock raevol because of errors in the change log, and so on.
Such a forum would also be the place for other internal discussions, e.g. about the course of the project. As much as I like the openness of our forums, some things need to be spoken of in private (and by that I don't mean via pm). Relevant results of these discussions can then be made public in order to get feedback and maybe continue the discussion in the "open" forums.
As Atahualpa said, why can't we use phpbb's groups for "release" related people. This small forum area would only be seen by release people, so that we can do the work in private including posting videos and changelogs or handling any 'details' about the releases in general. No one would be wiser.
Note: We already have a 'dark penguins' group and thread area... for years now. It's like a secret society.
The Windows packages were build without any testing. We encountered a delay because there was no confirmation if they even work. Even now, I don't know if the 32-bit build even runs.
there was plenty on 64 and sorry for vague 32bit testing. they have been running good. this time there was 3 test version without rc tags. in confused a bit.
otherwise one way would be to make suggestion that report even that it works without any error or go crazy and ask reddit to test making clear to everybody that it's only just testing phase. with so many different distros and building taking possibly hours it would be needed to make reddit or longer time rescruitment anyway or new forum group : )
Will personally volunteer for 64bit windows testing of any kind. What encompasses beta testing and it's goals?
Atahualpa wrote:If we want to do this, a first step would be to set up a "Team" forum which can only be seen (and accessed) by team (or "proven") members. There, we could coordinate the releases, discuss and tag the process on each release, review the videos, mock raevol because of errors in the change log, and so on.
Such a forum would also be the place for other internal discussions, e.g. about the course of the project. As much as I like the openness of our forums, some things need to be spoken of in private (and by that I don't mean via pm). Relevant results of these discussions can then be made public in order to get feedback and maybe continue the discussion in the "open" forums.
Agreed, team forums needed. For more focused team efforts and minimizing any PR dmg. We can always tease out new developments as a PR. To keep them wanting more.
One thing that might help with the release video hijacking is if we scheduled a final date for the version to be out: say that .41 comes out on January 7th, and if it's done earlier the appropriate builds can be made available but the video doesn't make people think "oh, hey, .41's out" and get confused.
SquireNed wrote:One thing that might help with the release video hijacking is if we scheduled a final date for the version to be out: say that .41 comes out on January 7th, and if it's done earlier the appropriate builds can be made available but the video doesn't make people think "oh, hey, .41's out" and get confused.
I don't know how feasible a final date for a release would be. And even if there was a final date, people will still mix up things. I'd rather like to have a closed review for the videos, without posting the links in the public forums.
