Bug 4927

... or mark it as "never gonna be supported" clearly for the warning to avoid the confusion that may be implied for people trying to get it supported.

We currently have a system of marking known releases as tested and providing a warning for those that have not tested. This is known as "SANITY_TESTED_DISTROS".

There is a clear WARNING when you attempt to build with a distro that we have not tested and added to that list. 

We are not going to try an keep a list non-tested distros as that is always a moving target in and of itself. Your right we are not going to support an Arch type of distro that's always rolling forward as it's impossible to support if the day after we release a known working version with a give snapshot of the distro the compiler uprevs and breaks everything again.

Please, let us discuss an issue before closing.

If this bad decision every happens to be real, it has to be clearly documented, no matter what.

It is *very* unlikely that common distribution would change every single day, but even they did, the documentation should clearly state up front that "rolling release" distributions will not be ever supported.

I kinda feel it overly sucky, but that needs to be there anyway if that is the decision.

It sounds to me like we can turn this into a documentation bug.

Agree, but perhaps it is better to wait a few days for the outcome of the mailing list discussion. It has only been started today.

I have added a note explaining that YP is only supported on the distros in the list in the reference manual and we do not support rolling distros.  I used some approved wording that we have in the QS manual here as well to assist those that might want to try using a distro not offically supported.

See http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#detailed-supported-distros

Scott

"The Yocto Project is not supported on "rolling releases" whose frequent changes could break functionality."

This would not be clear to me whether it is just a current state of art, or a mission statement. Can you make it clearer please that it is never going to happen?

It's an interesting question about documenting policy vs current state of the art. I have been a strong proponent for trying to be prescriptive in exactly what we do and do not validate. ("Support" can be misinterpreted that we have anything other than community support. It's not a software product after all.)

What I'm trying to avoid is someone new to the project going down a blind alley with wrong assumptions and wasting a lot of time with an option that we have not validated and we could not hope to resource. For example, Arch Linux appears to be one of those options which is very difficult for us to validate with bounded resources. So I would like the documentation to reflect this, so if someone cared to read the docs first they wouldn't waste a lot of time trying to get Arch to work. Of course, not everyone cares to read the docs first, so it's sometimes a moot point.

Now relative to policy, I don't know. Someone could always roll in with a bunch of money and decide to validate Arch. Perhaps this is what the OSVs do like Wind River and Mentor and the like.

Update the documentation if the policy changes?

What you are claiming does not make sense to me because with that in mind, you should not document anything because software development process is iterative.

I could be more specific on the note:

"Note
Yocto Project releases are tested against the stable Linux distributions in the following list. Attempting to use the Yocto Project on any Linux distribution not on the following list puts you into untested territory. Refer to OE and Your Distro and Required Software for information for other distributions used with the OpenEmbedded project, which might be a starting point for exploration. If you go down this path, you should expect problems. When you do, please go to Yocto Project Bugzilla and submit a bug. We are interested in hearing about your experience."

What this note now says is that if you use any distribution other than one of these versions listed all bets are off.  But, you can try and if you do let us know how it goes.  Taking out the bit about the "rolling releases" from the note pretty much makes the list definitive.

Scott

This note suggests that the Yocto project cares about Archlinux, Gentoo, Slackware, etc, and file bugreports, and they will fix it for you until it gets supported.

So, it is not okay for me.

Updated the wording in the notes in both the ref-manual and the quick start.

http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#detailed-supported-distros - ref-manual

http://www.yoctoproject.org/docs/1.5/yocto-project-qs/yocto-project-qs.html#the-linux-distro

I am marking this bug RESOLVED

Are you serious to close a bugreport without solving it? Do you wanna me to open up a new with the same content? In that case, you can close this one, although I see no point in forking a bugreport for no real gain.

I have just read through the documentation again, but really, I do not see the improvement for the request of this report.

"rolling-release" (the main point) did not even get a word in the update. Not to mention, the main fact to claim it is never going to be supported, i.e. we know do not request it, do not discuss it, it is a closed minded decision.

So you re-opened a bug *before* you actually read the latest documentation?  Please actually review the changes before re-opening in the future.

We list the supported distributions.  We state where to look for advice on how to make it work on other distributions.  If you can't make it work, we ask for bug reports.  These bug reports are encouraged as the state of rolling/development distributions now is the state of the stable distributions of the future, so each bug report will be evaluated on its own merits and not ignored.

The documentation doesn't need to mention rolling-release distributions, just like it doesn't need to mention development branches of distributions, archived releases of Debian from 1998, NetBSD, or Windows.  They are unsupported.

Again, supported in this case means "we regularly test the Yocto Project on them, and any breakage means we'll fix YP".  Generally, this means we're running the distributions on various machines across the autobuilder pool.  It does *not* mean the Yocto Project won't work.  I'm running an unsupported distribution, as are many other core developers.  It breaks occasionally as the distro changes, and we fix it - where "it" can either be the distro (GNU make 3.82) or YP (new compiler has stricter warnings).

Yes, of course I did read. Please only close this bug if you actually have any relevant documentation to this request. Thank you for your understanding.

I do not honestly know what the latest documentation improved.

Again, this documentation "improvement" does not avoid the situation of someone coming here, and asking about Arch, Gentoo, etc, within a week.

Perhaps, you enjoy turning the contributors down for good, but as for the contributor's side, I can definitely claim it is not a pleasure...

There is no way for us to list all of the distros we don't support, nor can we add reasons for every distro. The clarification that Scott added to the reference manual clarifies the project's position - the listed hosts are supported, all bets are off for other hosts. I'm sorry if this doesn't meet your needs, but it is all we can offer.

The original request for this bug has been met. I recommend that this bug be closed.

I would also add again that if anyone wants to expend the resources needed to make the Yocto Project support other host distros, whether or not they are rolling releases, please contact the project's leaders through proper channels.

You do realize the fact you have not solved any of the original request? What you are explaining is supporting your engineers, and disregarding the end user.

Can you point me to the point in Scott's "improvement" which guarantees no one will come and waste the time in one week to ask about rolling release distributions?

"Every distro" is also pretty incorrect in your reply in my opinion because "rolling release" does not mean a specific, nor every distribution.

I do not think it matters, but as an end user of the project, I do not feel happy about that no technical steps have been made to solve the original issue.

I will withdraw all my previous comment if I can be shown with the point which avoids the original confusion.

Until that, I will call it a bureaucratic management "force solve", I am afraid. This is not solved on the technical level, not even for explicit queries to point out what solves the original issue.

Original request:
Make Archlinux a supported or document the unwillingness of rolling-release

Current documentation:
Yocto Project releases are tested against the stable Linux distributions in the following list. Attempting to use the Yocto Project on any Linux distribution not on the following list puts you into untested territory.

Arch is not on the list, so it is untested. (Nor is any other rolling-release distro, but the restriction isn't limited to rolling releases.) 

The rest of the note makes it clear that the user "should expect problems" with any release not on the list. I'm not sure it could be any clearer than that. If you think it could, we'd be happy to consider any language you might suggest. 

I am sorry you don't feel happy. This really isn't a matter of being unwilling, it's a matter of available resources. We don't have the resources to support Arch as a host, and thus have made a decision not to do so. I'm sorry if that affects your workflow. We do our best to provide as many features as we can, but supporting Arch isn't one of them. We have documented the issue, so I'm not sure what else there is to do here. 

If Arch is a requirement for your workflow, one suggestion is to contact a consultant, or one of the operating systems vendors who offer commercial support for the Yocto Project. They should be able to tell you whether they can do what you need.

Your post and "presentation" make me highly wonder if you understood what I would be saying.

Let us clear up the misunderstanding you seem to present: this report is not about documenting Arch unsupported. I am not unhappy because Archlinux is unsupported. Well, that is the first thing, but the second thing making me a sad panda is the fact that you do not document the unwillingness properly.

I had proposals, but apparently it has not even been considered. Let me write it out again with a slightly different words. I think it is very important to understand the request before trying to close that.

Your presentation shows Arch is not supported, good, it has never claimed Arch would be supported? So what did you solve then? In my opinion, nothing.

The unwillingness means, it has never going to be supported according to the current decision. If it is put straight to the users, they will come to ask Arch being supported because it is clearly a rejected decision then.

Proposal:

"Rolling release distributions are and will not be supported due to their nature of constant change, and we would not like to define any fix setup for them either". -> Now, THAT * would * solve the issue because then I understand these guys decided something strange, and I either step away right in the  beginning, or I will not bring the topic of arch anymore.

* It is never going to be supported...

* they will not come to ask ...

... and other fast typing typos.

Ok, good suggestion. I think I can certainly recommend the first part of your suggestion. 

The second part "and we would not like to define any fix setup for them either" states both current desires and future intentions, though, and they are not quite correct in this case. It isn't a question what we would like. We have no future plans one way or another for fixed setups, though if someone dumped a truckload of money/people/resources on us to provide them I'm sure we would do it. 

But I think I understand your desire to read in the docs that we have no current plans to do so, is that right?

How about this change to what you suggested, to be added to the revised text Scott posted earlier:

"In particular, the Yocto Project can not support rolling-release distributions due to their nature of constant change. We welcome patches and bug reports, but keep in mind that our priority is on the supported platforms listed below."

Hi, 

Here is a suggested update for the note.  Please consider it for review:

Note
Yocto Project releases are tested against the stable Linux distributions in the following list. The Yocto Project should work on other distributions but validation is not performed against them. 

In particular, the Yocto Project does not support rolling-release distributions due to their constantly changing nature. We welcome patches and bug reports, but keep in mind that our priority is on the supported platforms listed below.

Refer to OE and Your Distro and Required Software for information for information about dependencies and requirements. If you encounter problems, please go to Yocto Project Bugzilla and submit a bug. We are interested in hearing about your experience.

Thanks,
Scott

s/does not support/does not plan to support/?

My request was to document the unwillingness which word means "no plans" for me.

Also, I would explicitly mention "doe not plan to support ..., not even with a fixed setup" since that would be a natural suggestion from rolling release distro people.

I have made a small modification to the wording in this note to indicate that there are no current plans to support rolling releases. The wording I used falls just short of saying we would never do that.  I am hesitant to cement that judgement into eternity - "never say never".

See http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#detailed-supported-distros

Scott

Marking as RESOLVED.

Thanks.