On 20 October 2017 at 14:48, Dirk Hohndel <[email protected]> wrote: > >> On Oct 20, 2017, at 7:07 AM, Lubomir I. Ivanov <[email protected]> wrote: >>> >>> I'll pause doing (small) features now. I already have one or two smalls >>> things ready but they have to wait for post 4.7. >> >> yes, feature locking sounds very reasonable at this stage - i.e. BETA. > > Just FYI, I am NOT planning on doing a beta. We have been asking random > people to "try the daily test builds" when they have problems - and in general > I never felt that the beta really got us that much more dedicated testing. > > I'm planning to simply release 4.7 this weekend. > >>> Unfortunately I constantly stumble across small bugs at the moment. Will >>> still try to fix a few more. >>> >> >> that's where the "release-small, release-often" model works great: >> https://en.wikipedia.org/wiki/Release_early,_release_often >> >> i haven't read this in a book or something, i just saw it in action in >> a big public closed source project...it works great. >> aaand i think i've proposed this at least 3 times the past 6 years. :-) > > We have done so for a while and then fell off the wagon again. The problem > is that we keep focusing on different things and get distracted. And that's > mainly > a problem of too few developers in certain roles. And the biggest choke point, > quite frankly, am I. > Having multiple people deal with merges on GitHub seems to have really help, > thanks for initiating that, Lubomir. We now need to get a second developer who > really looks after each platform. And who has at least some time to do so. > > Android we seem to have a few people who build their own APKs and who fix > if things get broken. > > iOS I think I'm back to being the only one - Robert tried for a while. > > Ubuntu, Fedora, and openSUSE each have a few people who build locally, > but only openSUSE has another repo owner who simply fixes things in the > build as they crop up > > AppImage is just me (and that's my own fault for not making it possible for > others to contribute and help - I need to fix that). > > Windows has Lubomir as the only one building natively, and Stefan appears > to be using my scripts for MXE > > Mac is mostly myself, occasionally Robert. > > If every platform had a co-owner who worked on keeping that platform building > and working, then more frequent releases would be much easier to do.
i can start doing the MXE, eventually. have never tried it! > >> what i propose: >> >> 1) add "daily" links next to the the official download link on the website >> i'm pretty sure we already point a lot of people to the daily links. > > I stopped calling them 'daily' because that implies that they happen, you > know, > roughly every day and they definitely do not. And there's a huge risk in that > because > we do break those test builds. And sometimes pretty badly. > i would say that a "unstable" build crashing is part of the risks users take when they download a build marked as test/unstable. they help us developer the app by testing this build. do you mean huge *legal* risks? can we use a DISCLAIMER? >> 2) the community is the QA team (like we already do that) >> e.g. Rick saw a crash yesterday, he immediately reported it, but it >> wasn't the latest build and we already have a fix for that. >> the software crashing is not that dangerous. > > Not sure what your point is here - what do you propose? > >> 3) we only announce MINOR bumps to social media. >> we announce PATCH bumps *only* at the website and do PATCH bump more often >> too. >> put the change log on the website - the dev. team can help to update that. > > Again, not sure what you propose here. Consider the test builds > "official"? No, I don't like that. We need to streamline the sub-minor > builds like we did for a while. Create 4.7.1 and on at least once a month. to clarify: with 2 + 3 my point is that we can expose unstable PATCH bumps or even sub-PATCH bumps to the public and users act as the QA team via a link with a warning. > >> i will add Dirk and Linus to CC, to see if they want to trigger this >> change one day. > > I appreciate the input, and I'd love to hear what others think. me too. > But exposing every user to the test builds seems wrong to me. > usually a small link on the download site is enough, with the following context: 1) here are our test/unstable/daily builds 2) here is the changelog for them 3) use at your own risk (disclaimer) - unstable, may crash, data may be lost 4) help us - feedback appreciated 2c lubomir -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
