Shallow bugs immediately after upgrade to latest release?

(ljpp) #1

Now I can’t really complain as this is free software and mostly awesome, but with recent stable releases there has been quite a few shallow bugs that we find immediately after the upgrade. It’s a little frustrating really.

There are a couple of things I would see beneficial for this awesome project:

  • More bug reports from community users. Thats what the volatile branches are for. I see far too few reports in the Bugs category in comparison to the install base of Discourse. I mean, how can the quoting be broken on a stable release? Nobody saw this during the branch?
  • More project focus to robustness. Discourse already quite fully featured and a solid platform. Personally I would rather see less mingling with basic feature UX, and more attention to the little details, quality assurance, perfecting the mobile experience, performance improvements and overall robustness of the platform. Sure, that’s the boring work, but of the the last 5% often takes most of the time and resources. You are now at 95%.

Just my 5 cents as a rather experienced software project leader.

Discourse 2.1 released!
(Jeff Atwood) #2

This seems like a bit of a knee jerk response to your particular situation. Which bugs are you referring to specifically?

Yeah reading through your recent post history, as I expected, these are really narrow issues. One is an iOS 12 bug related to changes in iOS 12 versus iOS 11, not us — and the other is about quoting of custom emoji.

So I don’t think a dramatic pronouncement is supported by the facts in this case.

(rizka) #3

Here’s a third issue discovered by us and discovering all these took two days.

The point was that if we run into them so fast, then how come nobody did before us? It’s not possible. We have a thriving community here, but we need to always report bugs as we run into them. Else they will stay there to bother us all.

(Jeff Atwood) #4

That’s a CSS issue. Hardly earth shattering. And we don’t control the release date of iOS 12, do we?

I understand your pet issues are important to you, but calling for an entire restructuring of our development process based on your pet issues? I don’t think so.

(Stephen) #5

This is why tests-passed exists, and why companies such as Apple provide early access to their software- for you to test things and feed back to all involved parties.

Arguably the team may have interest in testing specific configurations used by paid customers, for everyone else they need to look for that capacity on their side of the fence.

Any successful software project includes testing, both of individual components, and in their integrated states. How much testing did you do prior to the release of 2.1? If you did test how did you miss the quoting bug?

What are your release processes? If these things really matter to you do you take the latest builds through development and staging environments before updating your live server?

If not again you need to look at how you’re handing upgrades, because if these things really matter to you this is how you mitigate against them. Trying to hit the project with a stick for your own shortcomings is frankly ridiculous.

If the impact was widespread just think about how many people you could have helped out by conducting this testing beforehand, if not then it’s the price you pay by assuming someone else will do this for you.

(Richard - #6

There are always more bugs, and somehow these always surface immediately after an upgrade :wink:

One of the great improvements with respect to the stable releases in the past year or so was that a new major stable version (2.0.0, 2.1.0) was always followed up within a week with a .1 release (2.0.1, 2.1.1) that mainly consists of backported fixes. So given the fact that there are always bugs, I think the team is dealing pretty well with them wrt the stable branch.

(Jeff Atwood) #7

I do regret the iOS 12 issue, but the timing of the iOS 12 release made that inevitable, it wasn’t a bug in iOS 11, and we don’t exactly control Apple’s iOS release schedule… so what can you do?

And we’ll likely backport that fix … I believe @pmusaraj is working on it?

(Penar Musaraj) #8

Yes, I am working on the ios 12 issue.

(rizka) #9

We really don’t have time to run a test server and use it for the sole purpose of testing. Never going to happen. We have never run into any critical problems so it wouldn’t be worthwhile. Our site’s success comes from content in the end so we put our effort to moderation. Our site’s success also always comes first, but when it’s possible to improve Discourse with the same effort, I love it. With my skillset all I can do is report bugs and provide high-quality translations. If I could, I would fix simplest of bugs myself. But even so, I contribute way more than what most do of course.

Our strategy of minimizing issues is running the stable branch and not even upgrading at release but waiting for some weeks after so that others can run into any issues before us. Leetching, hmm. We have never used that word to describe our strategy. We rather like to speak of conservative approach. We don’t want to expose our non-tech userbase to random issues only to help Discourse.

Majority here likes new features so much that they do run tests-passed in production. When you do, it’s not too big of a task to report any issue you run into. We always do and we are among the most active reporting sides. All I was saying that with our strategy we shouln’t be. By not reporting people are hurting their communities, other communities and this entire wonderful project. Over and out.

(ljpp) #10

The following paragraph is not regarding the Discourse project, but SW development in general:

Ah, the typical SW vendor attitude - the customer is responsible for the testing. It is a proven fact that the cost of fixing a bug is lower the earlier it is found in the delivery and development process.

Sure, more testing by us would tackle this as well. We’d need a QA environment and lots of man hours. Doable, but we are a hobbyist project and our people have real jobs, mouths to feed and so on. Unfortunately unrealistic, but we contribute what we can.

What we do at the point of a major version upgrade is a smoke test that focuses around our UI customization and testing for show stopper grade breakages.

Our message is that the number of reported bugs vs. installed Discourse instances is low. People benefiting from this great piece of OSS software should step up their game in terms of bug reporting. We can only wish the core project to focus more on robustness and perfecting the quality, but their development is driven by paid customer requests, which is totally fair.

@codinghorror Us Finns are never dramatic (like Italians), but almost always very direct.

(Sam Saffron) #11

I think you need to follow a different process here. Update to tests-passed a few weeks prior to our major release and the get back on the stable train once stable is out. We are happy to commit to a tentative release date for stable say 3-4 weeks ahead of time.

The reality is that we have zero paying customers who are on the stable train, we are very highly motivated to fix stuff on tests-passed and minimally motivated to backport minor CSS fixes to to stable.

(Jeff Atwood) #12

Honestly, the things you brought up were mostly specific to your site, and very narrow. Almost cosmetic complaints.

If you want the right to complain more seriously, then I’ll also be direct with you: pay us money.

But then again, as @sam pointed out if you did pay us money you’d have all these fixes already because our customers are always on recent betas. Just sayin’ :wink:

(ljpp) #13

I did not complain to the core project at all.


That is certainly something to think about. The challenge is that we want to avoid breakage and downtime during the hockey season like plague, so it depends how the Discourse releases align with the game calendar. For this goal the stable branch has served us very well. There has been virtually no regressions during the stable version life cycle.