as someone else already said above: NC wants to keep itâs real news (ânewsâ in like âwhat is newâ) closed until the official release day.
and as I said above: ppl interested in that could go and check github (if they donât like to be tracked they could use tor or some vpn or whatever) beforehand for what they want to know.
apart from all of that: This âthreadâ is just an announcement about an betarelease. nothing more. Everything weâre commenting here has nothing to do with it.
The goal is construction, so please take this as the above in the spirit itâs given. Friendly debate and advocation, and not an attack on anyone.
This is rather the point. They donât want to keep this stuff totally secret, or they wouldnât even have code on GitHub prior to commercial release. They want to be able to manage the hype cycle, sure, but they need people to test these things.
So when betas are announced as ready for testing, but NC doesnât tell people what is new, folks like tflidd helpfully post the link to GitHub, and point people in the right direction. Thatâs part of the development process. The unofficial development process, but still very real. The rest of the thread has been a discussion on whether and how to improve this process, perhaps by making it official. Managing the hype cycle doesnât necessarily require silence on new features in the post where they are announced as ready for beta testing.
This discussion could and has occurred in other release announcement threads, youâre right. But since this is a process change and not a code change weâre talking about, is there a relevant GitHub repo where we should file an issue to request the change instead? Would starting a separate thread on the forum be more appropriate or impactful?
This is mostly an aside, but to provide a bit more context: The tracking issue isnât about whether we can see the code on GitHub, but whether we can participate in conversations (and file issues) there. [âŚ] Edit: Forget I mentioned GitHub or tracking. Participation has always been the point, which is why we even have these forums and calls for testing.
There is no âenoughâ you can do so that nobody will ever complain, but thatâs ok. A project with no complaints is a project that nobody uses.
the other second it just was getting to know about the new features in a new version.
So NOW that isnât enough anymore and everyone wants to take part in the discussion.
And again: itâs never enough. Like I pointed out above. And so this went round full circle: It is never enough.
Somebody always tries to have the last word on something that doesnât really need any more discussion.
If you wanna betatest you know what to do. If not itâs ok as well. Just donât try to find zero-arguments just for the sake of finding a contratry point of view.
The interesting part with the testing is, how do you get the right people start testing. Itâs not the most interesting thing to do. And having 10 more default debian/ubuntu environment that updates without problems, wonât help so much either. Or isnât it the update and environment itself and rather the UI, translations, âŚ
Imagine a list of 100 points to test, you have 10 people that test the first 10 points of that list. Iâd prefer to split them, that each focuses on 10 different points. However, if there are 3 people in the end that are testing such a beta, thatâs not worth the effortâŚ
All the bad bugs that were missed during the last updates, is that something that is already covered by some internal process, are there platforms less or not tested which often create problems? Is that something we know?
Maybe everyone who is willing to test should just test his personal business/use case, because that would help you to identify problems for your own environment, caused e.g by a regression, and therefore already provide a very good quality assurance, and as a bonus you would surely stumble upon one or the other changes such as new features and functionalities yourselfâŚ
Upgrading to beta 1 went with only one error. Now we already have beta 2 Tried that but got a message on extra files.
I understand that this is a common issue. I find lots of posts in the forum.
I think there is a place for a more detailed âHow toâ or a passage in the manual about how to solve this common problem. And at a level so a beginner on Linux can follow. As NC is used by a lot of amateurs like me I think more basic instructions would be appreciated and increase the usability.
After sudo -s I could cd to /var/www/ and identified the file and folder.
Should I just delete the file (rm?) and the folder (rm -r)? Or should I move them to another place?
For the moment I solved it by returning to my snapshot.
I now upgraded to the Beta2 but this failed with error
InvalidArgumentException: Column âoc_bookmarksâ.âurlâ is type String, but exceeding the 4.000 length limit.
And while complaining about unclear instructions. When I wanted to add the missing indices I tried the instruction given in NC itself to run âocc db:add-missing-indicesâ but although I was root and issued the command in the /var/www/nextcloud/ I got an error message Command âoccâ not found, but there are 21 similar ones. So I needed to run the command âsudo -u www-data php occ db:add-missing-indicesâ. I would propose that you give this instruction instead.
I am a fan of NC but I think a more client oriented information would help a lot. Many users are amateurs.
I must honestly say that I donât quite understand the idea behind this strategy either and I also doubt that this is the right strategy. But in the end, it is the decision of Nextcloud GmbH how they wanna handle thisâŚ
Personally, I donât care much, because I have simply adapted my strategy of how to deal with upgrades to the strategy of how Nextcloud GmbH is dealing with their announcements. This means that my personal âbetaâ testing takes place between the initial release and the first point release, which is perfectly fine to me, given Nextcloudâs fast release cycles.
Amateurs shouldnât deal with beta versions at all. And if they want to learn and participate, they should run a separate test instance. Matter of fact everybody should run a seperate test instance. Also there are many appliances like NCP, Nextcloud AIO, the Snap package etc out there. And there is a reason why most of the appliances are lagging a bit behind with upgrades of the dependencies and sometimes even with Nextcloud versions. If youâre an amateur and just want to use a product, you shouldnât use bleeding edge or even beta versions. Use either one of the appliances or if you want to install it manually use Debian stable or Ubuntu LTS and the PHP, MariaDB releases from the repositories of the distro. Also do not upgrade Nextcloud before the first point release.
Without knowing what features have been added, how are beta testers supposed to test the new features?
Donât reply with vacuous rhetorical statements, just explain why keeping features secret is fine when weâre asked to beta test the secret features.
But it doesnât give all the answers needed. Testing in your own environment is fine and dandy but it wonât tell you what bugs or changes have been fixed/made in the software that actually need testing.
if youâll find bugs in a beta you should flag them⌠regardless of what you found. and where. and why. You most prolly donât know which part of the code was changed or not.
You even donât know that if you donât find any bugs if that is good or if you have just searched bad. Could be that bazillion lines of code has been rewritten without you noticing it.
I still donât know why we need to discuss it here⌠there has been good suggestions already on how to proceed for really interesteed betatesters.
Iâm a beta tester. I beta test most versions of nextcloud. Iâd like to see more transparency so something like this doesnât happen again.
Iâd like to remind everyone the problem above happened with the built-in code server, so it wasnât just a problem with docker/external collabora servers.
If you read my post I mentioned that I use snapshot and it is on a test instance. If NC does not want amateurs to do the beta-testing why do they post about it on the forum? I do understand that their primary aim with that is to rule out any issues on existing setups. I know many are eager to test new functions but for that you can wait until the basic things are OK. I agree -stop complaining.
I think there is no clearcut limit between amateurs and pros. In my case I run a production server for a church and there are 50 users. But I am not an IT or Linux expert. It is actually on NC22.2.5. I will probably upgrade now to NC23 as it works well on my test instance.
It takes a special sort of arrogant stupidity to assert that betas are not for amateurs.
Firstly, the difference between amateurs and professionals is whether they get paid, not how knowledgeable they are. Some of the best stuff comes from amateurs, who can afford the time to do stuff that isnât economic for professionals.
Secondly, the whole point of beta testing is to assess how well the thing works. The userâs expertise (or lack of it) is an important part of that test. However well a feature works, if it is incomprehensible or even difficult for the user, thatâs relevant and needs testing.
This is even more true for RCs.
To conceal changes from testers is a truly stupid idea. We are not doing user acceptance testing. This is system testing.