During yesterday QA Meeting on Beta2 release, some few related topics have been discussed.
Here below will follow my attempt to make a summary.
There is an excerpt containing the relevant parts, while you can read the full log here:
Full log
– There have been one consideration and one suggestion for enhancement. See
18:42:49 re i586 to be treated as a separate release and
19:01:35 re Plasma-only and LXQt-only ISO.
– LO-base (see 18:34:29)
We have a useless menu entry for lo-base which besides doing nothing makes people think of a bug.
Suggestion is to get rid of it, meanwhile to ensure that its install will properly require openjdk and any needed component.
– Testing ISOs (see 19:19:47)
Request is not to produce multiple ISOs labeled ALPHA, BETA, RC etc. in their filenames.
Suggestion is to label development/intermediate ISOs produced just for cookers’ testing_foo purpose as “devrel”.
ALPHA, BETA, RC etc. label should be assigned ONLY to ISOs needing to get testing. Releaser/developer who needs such testing should drop an email in QA and cooker mailing list preferably specifying which particular component primarily we have to test.
– Saving time and resources (see 20:01:02)
Request is to avoid QA testing on already expected moving target, for example when we know for sure that a major update is coming on the very next days.
– The latest and greatest (see 20:17:20)
Wondering about whether it is really necessary to always update to the latest and greatest in 3.0 branch, especially at time when we are very close to release a milestone ISO. The above might not apply if evidence proved that update_foo will without any doubt fix a given serious issue and no regressions granted.
It is very frustrating for everyone to get to the point where things appeared stable for release and a major update practically nullify all QA work (without mentioning the presumable expected regressions always standing right behind the corner).
– Stages of development (see 19:56:30)
Wiki page Software release life cycle - Wiki [en] OpenMandriva provides some general guidelines.
18:34:29 I have noticed that LibreOffice Base is not working but I don't know if that's intentional and perhaps requires Java to be installed. 19:23:45 libreoffice-base can't work without openjdk installed, it relies heavily on (Java only) HSQLDB 19:25:41 But the question is whether or not we need it. 19:26:06 of course lo-base should have a dependency on openjdk to make sure people don't install it without getting all needed components 19:26:34 but I doubt libreoffice-base is important enough to be on the install image... 19:26:39 Well the point is there's a menui entry and it does nothing so people think it's broken. 19:19:47 I hope and pray that now cookers know that they should not produce multiple isos with the name ALPHA, BETA, RC and FINAL. We should only be testing one iso this time around. 19:31:04 what I am trying to avoid is people trying to test everything that appears on the iso product page. If it's got a valid RC number then it should be tested. 19:32:41 there will be confusion among external people who see we released an rc1 and then an rc47... Not sure if we can find a system that doesn't confuse anyone 19:34:57 we just need to maintain a clear distinction internally between what should be tested and what should not. 19:56:30 The point to all of this though is to try and determine at what state the repo should be in for an RC to be generated. 20:00:21 https://wiki.openmandriva.org/en/Software_release_life_cycle ? 20:01:02 It is absolutely pointless for QA to test proposed release if on the very next day it is announced there is a major update. 20:04:07 maybe we could save up changes, bug fixes, package updates and what not and only do a new .iso every week or every 3 days or something? 20:05:42 I really like the idea of saving things and doing an .iso every week, no more often. 20:09:38 How can one test updates to the current system (2014.2) the developing one (3.0) and the far future one (cooker) at the same time? Especially on real hardware. 20:10:29 that would be one reason for weekly or every twice-weekly .iso's 20:12:54 Also periodic release of .iso's gives someone (release manager?) time to announce and say what we're primarily testing and why and so on. 20:17:20 One of the problems that I see is the desire to always update to the latest and greatest. This is fine if you are dealing with individual applications but when you start dealing with the desktop suites of progrrams it becaomes a big problem. 20:18:59 btw to save time and resources, we should know which ISO is a real milestone or it's a just-for-testing-XYZ in-devs' mind :) 20:19:59 There have been several points along the way of this release where things appeared stable enough to allow an iso to be built buit no sooner had we reached this stage that it was decided to update a majour portion of the KDE suite and then this blossomed into the whole suite and suddenly we are back on the merry-go-round of breakage and fixing an more testing. 20:28:09 anyway itchka's most recent point seems that we have spent to much time trying to refine a moving target. Refinement is easier on a stable target. 20:28:51 And Beta and RC stage of development should be more towards refinement rather than major changes. 20:52:23 Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs. 20:53:17 This implies that packages versions should be pretty much set and we should be focused on fixing bugs and only upgrading packages if they fix relevant bugs doesn't it? 20:57:25 This distribution seems to have a block in that we can't possibly stop adding new stuff, we need to stop at a certain point, fix known bugs and release 21:04:07 We've got a Beta2, now we need to bugfix and RC and if necessary bugfix and release and be done with this one. 18:42:49 We can't wait for i586 I think we should treat that almost as a separate release so it doesn't hold up the 64bit stuff. 19:01:35 btw I think that in a near future we could talk about a Plasma-only ISO and a LXQt-only one. but this is quite another topic.
.
