Welcome!
Important information
-- Spectre and Meltdown vulnerabilities
-- Change in MX sources

News
-- MX Linux on social media: here
-- Mepis support still here

Current releases
-- MX-17.1 Final release info here
-- antiX-17 release info here

New users
-- Please read this first, and don't forget to add system and hardware information to posts!
-- Here are the Forum Rules

MX-18

Message
Author
clicktician
Forum Regular
Forum Regular
Posts: 188
Joined: Sat May 02, 2015 4:35 pm

Re: MX-18

#11 Post by clicktician » Fri Oct 19, 2018 11:21 am

I have noticed that the MX team tends to distribute new features, such as Live USB creator, plymouth support, Flatpak support, Gimp 2.10, updated boot tools and appearance tools, to name a few... whenever they are ready and without triggering a release.
There are very compelling reasons for doing this -- most notably, it spares the dev team a huge amount of overhead, and users get to enjoy new features without having to upgrade. Personally, I love that.

This has proved to be a very successful practice model for MX.

But: <Hahaha, you knew there would be a "but">, from a business POV, there are advantages to managing the MX product a little differently. Three important sacrifices happen when you blend maintenance and feature upgrades (and to the same extent "rolling releases" share these same issues):
1) You miss marketing opportunities and the milestones that showcase the hard work and innovation of your volunteers. MX developers/contributors have a lot to be proud of, and deserve frequent recognition. Releases strengthen your curriculum vitae (resumes).
2) Product critics don't see that you're meeting any roadmap fundamentals, so new features since the last release resonate as maintenance rather than progress. So, reviews often focus on new artwork and cosmetics at release time.
3) Most importantly, you lose the "trigger" for contributions. People are very accustomed to paying at upgrade time. So, the timing of a coincident donation campaign seems natural after new releases.

I'm not suggesting you change anything. I'm simply offering up some past key learnings from my own experience.
Son, someday all this will belong to your ex wife.

User avatar
richb
Administrator
Posts: 17218
Joined: Wed Jul 12, 2006 2:17 pm

Re: MX-18

#12 Post by richb » Fri Oct 19, 2018 12:06 pm

MX is not a business.
Forum Rules
Guide - How to Ask for Help

Rich
SSD Production: MX 17.1
AMD A8 7600 FM2+ CPU R7 Graphics, 16 GIG Mem. Three Samsung EVO SSD's 250 GB, 350 GB HD

User avatar
Adrian
Forum Veteran
Forum Veteran
Posts: 8987
Joined: Wed Jul 12, 2006 1:42 am

Re: MX-18

#13 Post by Adrian » Fri Oct 19, 2018 12:06 pm

There's another benefit of releasing new features when they are ready: we get bug reports and we can fix those immediately instead of waiting for a new release making MX a continuously improving product.

Also, as somebody who writes code I want it available to users as soon as possible, what's the point of coding a new feature if you have to wait half a year to deploy it. I don't think I would ever hold back code and features just for marketing purposes.

User avatar
asqwerth
Forum Veteran
Forum Veteran
Posts: 3441
Joined: Sun May 27, 2007 5:37 am

Re: MX-18

#14 Post by asqwerth » Fri Oct 19, 2018 1:03 pm

as somebody who writes code I want it available to users as soon as possible, what's the point of coding a new feature if you have to wait half a year to deploy it. I don't think I would ever hold back code and features just for marketing purposes.
And that difference in viewpoint comes from the fact that MX is made by fellow members of a community that pre-dates MX, not a team of devs creating a product from the top down and hoping to market it. The devs just stepped forward from the Mepis/antiX community because Mepis had been discontinued.

I admit I had early on - as a newcomer to the team - suggested that certain new features (not all of them) could be released with more fanfare with the next MX release, but the team explained why they did not think it was appropriate for MX.

I'm fine either way, as I was just bringing up something for consideration by the team. :p
Desktop: Intel i5-4460, 16GB RAM, Intel integrated graphics
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400

User avatar
Adrian
Forum Veteran
Forum Veteran
Posts: 8987
Joined: Wed Jul 12, 2006 1:42 am

Re: MX-18

#15 Post by Adrian » Fri Oct 19, 2018 1:29 pm

It makes sense to hold up for technical reasons (like Debian builds Buster now as Testing and will release when they are ready) but for adding some feature in apps that don't bother other things I don't think we'll wait for the next release.

clicktician
Forum Regular
Forum Regular
Posts: 188
Joined: Sat May 02, 2015 4:35 pm

Re: MX-18

#16 Post by clicktician » Fri Oct 19, 2018 1:40 pm

Adrian wrote:
Fri Oct 19, 2018 12:06 pm
Also, as somebody who writes code I want it available to users as soon as possible, what's the point of coding a new feature if you have to wait half a year to deploy it.
As it should be. In scaled Agile dev (SAFe), and its DevOps companion CICD pipeline, feature development is "everything" and they are simply activated when they're tested. Many modern shops have no such thing as a release. Even for documentation. It works really well. And external releases are fast becoming artificial constructs to help users and customers understand what's going on (and what they're buying - lol). Even kernel dev seems headed this way.

I'm just pointing out that as you move further this direction, there may be issues that pop up.
But , as Jerry mentioned, they may not apply to MX at all.
Son, someday all this will belong to your ex wife.

User avatar
Redacted
Forum Regular
Forum Regular
Posts: 137
Joined: Sat Apr 29, 2017 6:53 am

Re: MX-18

#17 Post by Redacted » Fri Oct 19, 2018 2:13 pm

Adrian wrote:
Fri Oct 19, 2018 12:06 pm
There's another benefit of releasing new features when they are ready: we get bug reports and we can fix those immediately instead of waiting for a new release making MX a continuously improving product.
Yeah, on the forum of a major distro there are tons of bug complaints after a new release.
And the response is normally "what do you expect from a new release?"
Never thought of this. I like our paradigm.
MX 17.1

User avatar
Hierax_ca
Forum Regular
Forum Regular
Posts: 132
Joined: Sun Nov 08, 2015 6:46 pm

Re: MX-18

#18 Post by Hierax_ca » Fri Oct 19, 2018 3:17 pm

I like how MX has done it: the year being in the name/number; I look at MX as being the best of that year -- i.e., at end of 2017 MX-17 comes out with the best Linux 2017 has to offer!

MX-18 at the end of 2018 matches the history of releases. MX-15 and 16 were both Debian 8 Jessie and end-of-year releases; So, having MX 17 and 18 be likewise would match nicely, and when Debian10/Buster version comes out make that MX-19.
MX-14.4/16.1 (32-bit) Thinkpad 600x*;
MX-17.1 (32-bit): Thinkpad A31p, T43p, T60p;
MX-17.1 (64-bit): Thinkpad x60t*, x61t*, x61s, T61p, T601pF, x200, x200t*, x301*, T500, W500, W700(ds), W701, x220, x220t*, W520.

User avatar
Stevo
Forum Veteran
Forum Veteran
Posts: 16540
Joined: Fri Dec 15, 2006 8:07 pm

Re: MX-18

#19 Post by Stevo » Fri Oct 19, 2018 4:16 pm

It would be nice to have a new release that would support 2018 hardware out of the box (Ryzen and Intel Coffee Lake), with an updated kernel, Mesa stack, and firmware.

User avatar
log
Forum Novice
Forum  Novice
Posts: 4
Joined: Fri Oct 19, 2018 4:27 pm

Re: MX-18

#20 Post by log » Fri Oct 19, 2018 4:57 pm

Stevo wrote:
Fri Oct 19, 2018 4:16 pm
It would be nice to have a new release that would support 2018 hardware out of the box (Ryzen and Intel Coffee Lake), with an updated kernel, Mesa stack, and firmware.
The october monthly upgrade version seems to work fine on my 1950x. The debian backports 4.18.x kernel seems to work fine in the two days I've had it, with the exception being that during boot, it'll sit around for a few minutes "waiting for devs to fully populate" (I first thought it was freezing. Nope, it's just slow), whereas the 4.15 kernel just plows straight to the login screen.

What hardware are you having issues with?

Post Reply

Return to “General”