RSS feed updated before https://nextcloud.com/blog/

[Moini]

The RSS feed is obviously promptly updated, while the blog site does not hold the article yet.

Sometimes, downloads and changelog are not available yet while the RSS feed already has the news.

[stefan-niedermann]

As i already said in the forum:

No, there isn't one. Actually there aren't blog articles for each and every minor release - the latest blog article about minor versions was about 20.0.5. I think this one was made to announce the end of life for NC 18. I do not understand what you need a blog article for, when you already got the information via the RSS feed? Writing and coordinating release announcements is not that easy - there are so many channels like all the social media stuff, blog, forum, RSS, ... I totally understand that noone wants to write a blog entry about such minor stuff :man_shrugging:

[jospoortvliet]

Heya,

Sorry, this is all disconnected:

• the RSS feed gets updated I think once an hour, and picks a blog up when we publish it
• nextcloud.com/news gets updated once per day at 13:00 - and thus a blog will only show then. I do often manually update, but not always (like yesterday - I had a day off)
• the changelog is entirely manual and requires someone (usually me) to generate the changelog with a script, add it to the file, commit and push, then pull on the website - I did that yesterday morning, before asking someone else to handle the blog and social media. But some sysadmins at Nextcloud can likely do this, too. And sometimes, I do the changelog after we publish the blog and/or social media. I sometimes (esp with major releases) forget it for a day or two - not great, I know, but there's so much work around a release the changelog just isn't the highest priority...
• Super minor releases or tiny bugfix releases like 20.0.4 and 20.0.7 (I think) I won't do a blog about - I just update the changelog and put it on the website
• putting stuff on the download server is done by the devs and yes, that can be a day or more before we do the marketing side sometimes. It often happens that on Thursday, the release manager lets me know the release is done and on the download server, and we only get to do the changelog and website updates and blog etc a day later.

So, I understand it is not satisfying, but yes, everything is disconnected. Could we make it so that marketing has to prepare everything and then hits one big button that refreshes the website, puts the file on the download server, publishes the blog and all that at the same time? Sure, but honestly - I have 1000 other things I would improve first before I'd spend developer time on something like that. It usually all happens within ~8-24 hours which I think is not a huge deal. I hope this answers any and all questions ;-

Also, if you really want to help fix it - we are looking for a web designer - somebody who can both do good design and html/css/bit of javascript. to (re)build and improve our website. Such a person would perhaps be able to remove some of the bottlenecks we have and make this process smoother. Being in Berlin is a plus ;-)

[Moini]

Mmmh. I find the changelog is actually the most important item, much more important than any articles or feeds. People will learn about the point release in their interface, and hopefully, on the download page. But they will not update unless they know why. Well, at least they shouldn't ;-)

To me, it's a major nuisance to be notified of an update (whichever way) and to not be able to quickly see if this update contains something really important (like a security fix) or whether it's not a problem if I don't do it right away.

So I would suggest a different priority order:

• put the changelog together before the release, and make it a file in the repository. That way, release and changes info are inseparable.
• writers can then use the changelog to write their texts and don't need to go hunt for the info themselves (I don't know whether that's a problem in nextcloud, but I know it is a problem in other projects)
• couple blog posts and rss feed, so they'll be there at the same time

By the way, as I see it... this is the bug tracker. This is a valid bug. You personally can't invest time into fixing it. But then, why do you close this? Others could pick it up. By closing anything you're not going to invest your own time in, you'll exclude new contributors wanting to help. Just asking anyone to contribute something while also closing their report, thus signaling to them that what they want is not important enough to even deserve space in the bug tracker... mmh, maybe won't be very successful.

I've seen this way of handling bug reports across multiple nextcloud subprojects now, and I can't say I'm seeing the project as a contributor-friendly project.

[jospoortvliet]

I think I might have mis-communicated. You are entirely right that changelogs are important, so they are nearly always done before we publish a blog post, release newsletter and social media. You might get a notification of a release and it will certainly be on the download server before the changelog is generated, because it is a manual process that simply only starts after the release is tagged and published. That just means you have to be patient for up to 24 hours, sorry. We are just 4 people in marketing and have a lot of work - by the time we are 10 people we can change this process...

For major releases - we don't generate a changelog at all, we just create a little note with a link to the release blog which acts as our changelog. If you want the major releases to have a full changelog, feel free to make the script on https://github.com/nextcloud/github_helper for generating changelogs able to work with major releases.

About the closing the ticket thing. So, sure, this is a valid 'bug', but it is due to the release process, and a volunteer can't go and change things - i could not even do it myself, I might, but it would need a sysadmin at Nextcloud to do it, plus changes to the release process done by the release manager. And they can honestly barely keep our infrastructure running (help.nextcloud.com down again yesterday) so I can ask them but this won't happen until they have no other more urgent thing to do - not anytime soon.

Thinking about it, perhaps thare's a way to make it go faster: if somebody wrote a script that, whenever a release appears on our download server, runs the changelog generator and does a pull request to get it on our website. That saves my manual work, and speeds it up..

Well, if you're up for that - let me re-open the ticket then.

[didierm]

@jospoortvliet Just a FYI, not to be taken as criticism : We ceased to install/test beta's & release candidates due to the lack of (concise) changelogs.

NC is - to my knowledge and limited experience - the only project which is so secretive about its new (= to be tested) features : "What’s new? As usual, we keep that a bit secret to not spoil the surprise" simply doesn't cut it. The logic on how to test secret features simply escapes me.

As others are doubtlessly following the same reasoning, we are forced to skip the .0 releases (which do have a public changelog), in order for the new features to receive public exposure and subsequent more targeted testing.

In other words (and only IMO), the lack of changelogs for the betas/RC's is counterproductive.

[jospoortvliet]

I'll see if I can generate a full changelog for the beta's. But it'll be fsck long... Not sure how useful it is.

[didierm]

I don't think there is a need to replicate the milestone data : https://github.com/nextcloud/server/milestone/129?closed=1 : too much detail. More important is : what features are new, and hence warrant more thorough testing ?

[jospoortvliet]

Well the milestone stuff doesn't show things from all apps part of the release; and it has a LOT of stuff in there that's just useless (bump dependencies is 2/3rd of all PR's). So the changelog removes that.

But if I make a list of features, I've basically done my release announcement, so that's not really something I think will be helpful if I want some press attention later on. I mean, it takes only 1 press person to find it and write about it... Or later mail me grumpily that I'm sending them month-old information.

[jospoortvliet]

Besides, the most important testing is upgrade testing and the basic, existing features - the new stuff is tested by the developers and by everyone who reviews and checks, and even by us who do screenshots and videos. And even if a bug is in there, it is something new that doesn't work - it won't break anyone's workflow. Bugs in existing stuff, caused by new things - those are much harder to catch for the developers. So that's what needs testing. Regressions are the main problem for users, I'd say.