On Mon, Nov 17, 2014 at 2:33 PM, Claudio Freire wrote:

...

On Thu, Nov 13, 2014 at 2:02 PM, Roger Luedecke wrote:

...

Poll on Google plus with over 1200 respondents shows 89% of our users support an annual release cycle. https://plus.google.com/110312141834246266844/posts/g5FdGJ9iSqB

I think we should however restructure the way we do releases in order to minimize the bumpiness of release. I propose a pseudo-annual release cycle. The idea being that our current state of release is messy at best and could use some last minute repository fixing and bug swatting. I propose that we esentially make the way we release now 'open-beta' at the 11th month.

We then use the 12th month to get all repos online and fixed. Also would be a good chance to give us about a month to fix problems with our disc images, and remaster the 'open-beta' 11th month GM with patches and hardware support fixes.

With this scheme we should see much smoother official release days by essentially duping the users into considering the state we currently call release to be beta, and giving us a month to clean things up.

Question is, if having this marked beta will cause more testing than having it marked release candidate.

Because there's already a lengthy time during which the images are released as "release candidate" and there still isn't enough bug swatting happening during that time. Will a beta period improve things?

Also, in my lingo, beta < rc.

Perhaps it's just a matter of sticking with RC longer and advertising and calling for testing more prominently.

Sorry, let me clarify: more prominently as in more visible than the default download at software.opensuse.org, and even calling it "quite stable but may still have some kinks". Beta is the common parlance for "safe but needs work." In reality with

On Mon, 2014-11-17 at 14:35 -0300, Claudio Freire wrote: this new scheme we just have to market it, which is easy on my part with Google+. In all the press etc. we can state that beta is what would be our normal release, yaada yaada yaada. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Nov 17, 2014 at 1:36 PM, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2014-11-17 19:23, Roger Luedecke wrote:

...

Beta is the common parlance for "safe but needs work."

To me it means "can be unsafe, and needs *lots* of work". Not only with openSUSE in mind, but anything. Alpha means certainly unsafe and also half made.

Many people only installed factory till the RC phase - me included, with some exceptions. Maybe now I /might/ install TW at some point, for testing purposes only, and inside a virtual machine, as I don't have a real machine to dedicate to it.

That's how it is...

Carlos, I assume you know factory was declared a decent release at the start of the summer. Over the summer the reports were that 6,000 installs of factory were made. That's fantastic and way more usage than factory ever got before. I'm very curious how many Tumbleweed installs there are now. As to it being beta vs RC, I don't know. I tried 13.2 beta on my laptop and it was as good as most opensuse releases. I have not tried TW. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Proposed narrative: === Tumbleweed - OpenSUSE's rolling release candidate. TW is tested via extensive automated testing and has a user base in excess of 5,000 installs. In early fall each year the release team implements a major feature freeze and picks out a particularly stable instance of TW. At that point, a final release candidate is branched off of TW and final release customization such as translation support is performed. After the branch point, further testing and bug fixing occurs until the actual release occurs. Releases are typically in early November. TW itself starts rolling forward again immediately after the final release candidate is branched off. === Greg -- Greg Freemyer On Mon, Nov 17, 2014 at 3:02 PM, Claudio Freire wrote:

On Mon, Nov 17, 2014 at 4:57 PM, Greg Freemyer wrote:

...

On Mon, Nov 17, 2014 at 1:36 PM, Carlos E. R. wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2014-11-17 19:23, Roger Luedecke wrote:

...

Beta is the common parlance for "safe but needs work."

To me it means "can be unsafe, and needs *lots* of work". Not only with openSUSE in mind, but anything. Alpha means certainly unsafe and also half made.

Many people only installed factory till the RC phase - me included, with some exceptions. Maybe now I /might/ install TW at some point, for testing purposes only, and inside a virtual machine, as I don't have a real machine to dedicate to it.

That's how it is...

Carlos,

I assume you know factory was declared a decent release at the start of the summer. Over the summer the reports were that 6,000 installs of factory were made.

That's fantastic and way more usage than factory ever got before. I'm very curious how many Tumbleweed installs there are now. As to it being beta vs RC, I don't know. I tried 13.2 beta on my laptop and it was as good as most opensuse releases. I have not tried TW.

Well, it's not about what it is, but what it communicates to a user that isn't at all familiar with Factory, OBS or any of those dev-mostly concepts.

Regular users who want to check out if this new release fixed this or that, might consider installing an RC if it's visibly declared as mostly stable. They won't readily click the "Switch to development version" link (they don't develop nor wish to).

It's all about communication really. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Nov 17, 2014 at 5:18 PM, Greg Freemyer wrote:

...

Proposed narrative:

=== Tumbleweed - OpenSUSE's rolling release candidate. TW is tested via extensive automated testing and has a user base in excess of 5,000 installs. In early fall each year the release team implements a major feature freeze and picks out a particularly stable instance of TW.

At that point, a final release candidate is branched off of TW and final release customization such as translation support is performed. After the branch point, further testing and bug fixing occurs until the actual release occurs. Releases are typically in early November.

TW itself starts rolling forward again immediately after the final release candidate is branched off. ===

After the release of the RC I can imagine software.opensuse.org offering the RC instead of the latest stable by default, with the latest stable at hand (either scrolling down or through a very prominent link), and a link reading something like "learn more about release candidates" leading to that text.

I'd say, after that, wait a month or so for enough downloads to consider the RC tested, and do the release proper.

I think that'd improve exposure of the RC and stability/quality of the final release.

That's just my suggestion, take it with a grain of salt. Yes yes yes! Exactly the sort of thing I'm aiming at. Lets face it, our releases are very rough due to improper testing even though our RC etc. are mostly stable with the exception of a lack of repos for commonly needed packages. What I'm essentially saying is lets call what we consider a release now a beta or some such and use an extra month of

On Mon, 2014-11-17 at 17:41 -0300, Claudio Freire wrote: pushing it as the default download for catching last minute bugs and getting our repos online and working correctly. Then, at the end of that month we create a new FINAL set of installation images with the fixes that were uncovered in the faux-beta. -- Roger Luedecke openSUSE Project Member and Advocate since 2011 http://www.opensuseadventures.blogspot.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/17/2014 06:33 PM, Claudio Freire wrote:

...

On Thu, Nov 13, 2014 at 2:02 PM, Roger Luedecke wrote:

...

Poll on Google plus with over 1200 respondents shows 89% of our users support an annual release cycle. https://plus.google.com/110312141834246266844/posts/g5FdGJ9iSqB

I think we should however restructure the way we do releases in order to minimize the bumpiness of release. I propose a pseudo-annual release cycle. The idea being that our current state of release is messy at best and could use some last minute repository fixing and bug swatting. I propose that we esentially make the way we release now 'open-beta' at the 11th month.

We then use the 12th month to get all repos online and fixed. Also would be a good chance to give us about a month to fix problems with our disc images, and remaster the 'open-beta' 11th month GM with patches and hardware support fixes.

With this scheme we should see much smoother official release days by essentially duping the users into considering the state we currently call release to be beta, and giving us a month to clean things up.

Question is, if having this marked beta will cause more testing than having it marked release candidate.

Because there's already a lengthy time during which the images are released as "release candidate" and there still isn't enough bug swatting happening during that time. Will a beta period improve things?

Also, in my lingo, beta < rc.

Perhaps it's just a matter of sticking with RC longer and advertising and calling for testing more prominently.

I wouldn't expect a big difference just by renaming things and adjusting the time frames. I would actually change the process a bit.

Right now, we set a proposed date for the release. We set the RC and beta dates counting back from that day. The release happens in the proposed release date if it's "good enough" to go which mainly means that it's not badly broken.

Just from the top of my head, an alternative could be like this (just a first though). I'd NOT have a fixed date for the release in advance. We set a date for the "freeze" (call it beta, call it RC, I don't mind). For that frozen version (good enough for daily usage but not labeled as definitive) we encourage everybody to report bugs and we classify their severity. The actual release happens when the bugs count is below a threshold. Let's say less than 3 critical bugs and less than 15 medium bugs. I know bugzilla is currently a mess, but you get the idea. Something more similar to what Debian does.

Cheers.

-- Ancor González Sosa YaST Team at SUSE Linux GmbH I like that idea. I think the freeze point too though should be considered as I mentioned, and pushed as the default download. Sure, some people may get a nasty surprise because they didn't read the bold

On Tue, 2014-11-18 at 08:30 +0100, Ancor Gonzalez Sosa wrote: print... but we can't really be faulted for people not wanting to read. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-11-18 08:49, Roger Luedecke wrote:

On Tue, 2014-11-18 at 08:30 +0100, Ancor Gonzalez Sosa wrote:

...

Just from the top of my head, an alternative could be like this (just a first though). I'd NOT have a fixed date for the release in advance. We set a date for the "freeze" (call it beta, call it RC, I don't mind). For that frozen version (good enough for daily usage but not labeled as definitive) we encourage everybody to report bugs and we classify their severity. The actual release happens when the bugs count is below a threshold. Let's say less than 3 critical bugs and less than 15 medium bugs. I know bugzilla is currently a mess, but you get the idea. Something more similar to what Debian does.

I like that idea.

Me too. I think it has been proposed before, though, and rejected. I think I proposed something on that line years ago. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRrU1IACgkQtTMYHG2NR9XYrgCaA88z4wbZun/6OyTTF35TsjCn NyMAn2bFCSK2blD8rEz2lVVHXBZ1y5Ja =GoIv -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-11-18 17:47, Christian Boltz wrote:

(Besides that, I'd say the real goal should be to make Tumbleweed really stable so that we can take a snapshot and call it a release.)

I don't think that will ever happen. Be that stable, I mean.

Use Tumbleweed _now_ ;-)

Not everybody can _use_ it. For instance: will nvidia drivers and vmware keep working on TW during its lifetime? Unless things have changed much, it was not recommended. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRrizAACgkQtTMYHG2NR9UqEQCfV3FuNZ08URDkq0MMad1yE1Ij r60An1rWKniIeJtkc0kJBC8fb9BXwdP3 =DuCl -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Claudio Freire [11-18-14 13:27]:

On Tue, Nov 18, 2014 at 3:08 PM, Carlos E. R. wrote:

...

...

Use Tumbleweed _now_ ;-)

Not everybody can _use_ it.

For instance: will nvidia drivers and vmware keep working on TW during its lifetime? Unless things have changed much, it was not recommended.

Not only that. Not everybody that would test a beta is on this list.

These kinds of things really belong on s.o.o.

Also, why isn't Tumbleweed mentioned in s.o.o's landing page? ( http://software.opensuse.org/132/en )

I think it should be there somewhere. You get a suggestion to use TW if you click development version, but isn't a rolling release adequate for regular users as well?

Define "regular users". I have seen a few time when updating Tw got somewhat "hairy" but I do not run vanilla Tw. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-11-18 19:26, Claudio Freire wrote:

On Tue, Nov 18, 2014 at 3:08 PM, Carlos E. R. <> wrote:

I think it should be there somewhere. You get a suggestion to use TW if you click development version, but isn't a rolling release adequate for regular users as well?

IMO, no. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRrpbIACgkQtTMYHG2NR9Vq2gCfZwiA/LYh1KX9m0pKjpATU3mG t0kAn3XHj/SARwr2m/rM1uHtEWzWmy6e =uZja -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-11-18 19:27, Patrick Shanahan wrote:

* Carlos E. R. <> [11-18-14 13:11]:

I run nvidia binary drivers on most of my boxes and have not experienced downtime there.

which you probably install "the hard way", ie, not via the provided rpms, which in fact, are not provided except for stable releases.

But my experience doesn't reflect "change" in the nvidia binaries and I failed (still fail) to see any recommendataion not to use the binaries except from Greg KH and that was pertaining to unclean kernels *only*. Understandable with his relation to kernel development.

No, the issue is that you can not click on an rpm and install the driver, point and shoot. You have to do a manual installation, and must be prepared to repeat when the kernel updates. That's the meaning of his warning as I remember. You can install the rpms for 13.2 now, and probably they work. But as TW departs and gets a newer kernel, sooner or later it's bound to break the proprietary driver via rpm. Via bundle (whatever.run) it may still build, at least till the kernel does one of those changes that breaks the driver, that needs the nvidia devs to readapt, a task that takes them some time (months?), so much so that people often have time to publish patches. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRrqHIACgkQtTMYHG2NR9VN3wCdHybjNxAEvL50F2yWXrft4ooV XEAAnR8BWtq7LVf/LZfCmSP1zkmSKBZM =DriO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 18 Nov 2014 22:10, Patrick Shanahan wrote:

* Carlos E. R. [11-18-14 15:15]: [...]

...

No, the issue is that you can not click on an rpm and install the driver, point and shoot. You have to do a manual installation, and must be prepared to repeat when the kernel updates. That's the meaning of his warning as I remember.

You can install the rpms for 13.2 now, and probably they work. But as TW departs and gets a newer kernel, sooner or later it's bound to break the proprietary driver via rpm. Via bundle (whatever.run) it may still build, at least till the kernel does one of those changes that breaks the driver, that needs the nvidia devs to readapt, a task that takes them some time (months?), so much so that people often have time to publish patches.

Ahhhh,

I work-a-round this by retaining two or three previous kernels where I can use available drivers (NV..run) until updates are available. But, yes, it is not pointy-clicky. And I cannot believe that you are bound by pointy-clicky, either :^).

IMHO, the main difference between "Official Release" and Tumbleweed is, that "Official Release" can be used by "pointy-clicky" personnel while for Tumbleweed a working brain and the willingness to use it is a absolute must have. The repeating troubles with kernel upgrades, base-system changes, and needed configuration changes due to upgrading apps are NOT to be ignored. The unpleasantness surrounding closed source software, esp graphic drivers, adds to this continuous needed care and awareness during updates of Tumbleweed installations. In the official release versions the release teams shoulder this needed care and awareness for the "08/15" John Doe user. IMHO a Tumbleweed user would be the same group of users that would be willing to test "Windows 10" atop of a "Windows 8.1" installation, just to see what drivers, programs, tools, etc, need work to be done before the product is unleashed upon the (unwashed) masses. Sadly this group is not big enough to catch every issue, and thus a broader testing during the beta / release candidate phase is needed. Still, for me a rolling Tumbleweed helps to catch at least some of the issues much earlier than with the previous model. Thanks for the work. - Yamaban. -- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-11-18 22:57, Jan Engelhardt wrote:

On Tuesday 2014-11-18 22:36, Yamaban wrote:

...

The unpleasantness surrounding closed source software, esp graphic drivers, adds to this continuous needed care and awareness during updates of Tumbleweed installations.

So, talk to NVIDIA. It's not like openSUSE is responsible for their broken development model.

They see it differently. (nobody has the absolute truth) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRrxIIACgkQtTMYHG2NR9VsKgCfWgPE7Ec0OdMLzwt2PscB0bpE 6IoAmgKnLHiDdX6nOrVXMal5m7+BFfnC =hnDX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2014-11-18 23:24, Yamaban wrote:

OTOH, the linux kernel guys make a sport out of it to change the abi and api of the graphic drivers with each kernel patch version, regardless of needed or not.

I do not believe you have yet worked on the upstream kernel with such involvement so as to make a qualified statement on what changes are needed. What might happen if you kept every function signature the same you can exemplarily see in Windows. Yeah, you might get your closed driver updates — and at the same time lack everything else that makes Linux what it is today. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 19 Nov 2014 01:18, Carlos E. R. wrote:

On 2014-11-19 00:18, Jan Engelhardt wrote:

...

What might happen if you kept every function signature the same you can exemplarily see in Windows. Yeah, you might get your closed driver updates — and at the same time lack everything else that makes Linux what it is today.

Could you explain a bit more? I think I understand, but maybe not. What are those "function signatures"?

When you "declare" a function and its parameters, this declaration becomes the "signature" / calling hash of the function. Changing a mature function is mostly done inside the code, the declaration is only touched when absoluty needed, as when you change the declaration, you have to change every instance the function is called by other code. Thus changeing a interface / declaration of a library is normaly reserved for major jump in the version numbers of the library, e.g. introducting new functions or extending already existing functions, or, that also happens, removing a old function. The stableness of a declaration is deemed a measure of the "matureness" of the function itself. If a library is featuring a unstable interface, and changed often, there are calls for 'versioning' e.g. expressly "require" a special version and not allowing any deriversion. Hope this give the wanted info. - Yamaban

On Tue, Nov 18, 2014 at 9:53 PM, Carlos E. R. wrote:

...

When you "declare" a function and its parameters, this declaration becomes the "signature" / calling hash of the function.

Ah, yes, I understand. I know what it is, but that's not what I thought it was meant.

In Windows, the API functions are called by a number in a list. I thought you referred to this number changing or not. You can hardcode the numbers, or find them at runtime, if I recall correctly. AND, some, like M$, do not publish the entire list of available functions. Not even the, er... header definition, but nothing of what it does or how to use it. Secret functions. And some of these functions are absolutely needed to do important things, which this way, only M$ could do. Like the early explorer and desktop handler, which they were forced to disclose on court order.

You're confused with syscalls, which linux also handles in a similar way, and keeps stable. But what nVidia and AMD are facing isn't syscall instability, but internal kernel API instability. Basically, a kernel module is an object file (a chunk of kernel code) that is linked into the kernel when loaded. This makes modules intimately familiar with kernel internals: modules can access anything within the kernel since they are, effectively, part of the kernel. So what they complain about is internal instability. Some internal interfaces in the kernel are marked as "stable" (as in, don't change unless there's a very important reason for it), but the ones governing graphics are being kept outside that set. This particularly is what the companies complain about. Now, there are reasons not to mark functions as stable. One is that the interfaces may not be mature enough to commit to that interface. Doing so with an immature interface can be very limiting. Whether the decisions the kernel team takes are reasonable or not is what is being discussed in general. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-11-19 04:33, Andrei Borzenkov wrote:

В Tue, 18 Nov 2014 22:28:25 -0300 Claudio Freire <> пишет:

...

So what they complain about is internal instability. Some internal interfaces in the kernel are marked as "stable"

No, they are not.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documen...

At the best, some internal interfaces are so complicated that nobody dares to touch them because of unpredictable effects.

I think I understand now, thank you both :-) Let me see if I can put it in my words. Let's have a kernel module, internal part of the kernel source tree. If the api of some function it calls changes, the module doesn't build; being part of the kernel source tree, someone has to repair it before the entire kernel builds and can be published. But a module that is not part of the upstream kernel tree, but that is outside, external, has to be modified when their maintainers notice the problem, after the kernel is published. When, if, the module is inserted in the kernel, the problem is solved, not magically, but as a need, a necessity. Of course, as more modules are added, the kernel grows both in size and complexity, each small api change rippling over a cascade of changes in a pile of modules. But the nvidia kernel modules can never be inserted in the source tree, because of incompatible licenses. Thus, the lag. Nvidia can not, will not, open fully their sources. The kernel devs can not, will not, accept linking closed source blobs. Both sides have their valid reasons. Impasse. Another question is, whether Linux can offer some stable interface for graphic drivers so that they work, without breaking licenses, and without needing extensive rebuilds, and make users happy. I guess not. I don't mean not willing, but technically not possible. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRsIjcACgkQtTMYHG2NR9W+YwCfRfdJGslXE/Gw0zhqPuwpWGAM Y6kAn0m4R1WXe/+Z9TwPU6/o3k+NNRw3 =A+KJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-11-19 08:10, Larry Finger wrote:

On 11/18/2014 10:53 PM, Carlos E. R. wrote:

That is close, but not quite right. The rule is that if you are the one that changes an API such that it breaks part of the build, then you are required to fix all the users of that API. In fact, it is a requirement that the kernel build after every commit. That requirement is in place so that bisection of a regression will work.

Aha. Makes sense.

The API changes show up early in the evolution from version N to N+1. They are usually available in -rc1, and yes the external maintainer must adapt to these changes. If you look at any out-of-kernel driver that can be built for different kernel versions, you will see lots of preprocessor commands that test a macro named KERNEL_VERSION.

Yes, and that's the are where people have to add patches to the drivers when the maintainers are to slow to publish it.

...

But the nvidia kernel modules can never be inserted in the source tree, because of incompatible licenses. Thus, the lag.

Nvidia can not, will not, open fully their sources. The kernel devs can not, will not, accept linking closed source blobs. Both sides have their valid reasons. Impasse.

If nvidia were to publish their sources under GPL, and they were willing to modify those sources to meet kernel coding standards, then their drivers would be accepted into the kernel. As those steps would reveal their trade secrets to the competition, they will never do that.

Right.

Adding binary blobs to the kernel means that you are allowing code that cannot be reviewed to run with no restrictions. That is a major hit to security and stability.

Right.

For that reason, loading such a driver sets the "taint" flag that alerts all developers. Most refuse to investigate a reported bug unless it can be reproduced without such a taint. Fedora's automated OOPS reporting will not operate whenever any of the taint flags is set. Their reason is that an OOPS usually leads to others, and they only want the primary failure; however, their policy prevents such automated processing if a staging driver has been loaded.

I understand, but that is unfair to users. For instance, I have been suffering a particular breakage in the XFS filesystem, which got badly corrupted after hibernation. And it was unrepairable. Two bugs. I am using the proprietary driver. Thus, instead of reporting here, on bugzilla, I went upstream, to the XFS mail list. They grumbled a bit, but nevertheless investigated the issue, found it was real, that there was a problem in the code, corrected and published both corrections, and now we have that patch in the openSUSE kernel tree and upstream. It has not been released to the 13.1 update channel yet, though. It affects every release, and can potentially have a huge impact on 13.2 users. Thanks to the Penguin, these people did not refuse to investigate just on the grounds of my logs showing "tainted" flag, and I give a big thank you to them. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRsl98ACgkQtTMYHG2NR9XzgACgjmIEl5l1VEH4ZXy2KkyP1TOx c18AnjJnp5nmliZrdo+34VghVHuoOPEA =edAT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-11-19 17:46, Larry Finger wrote:

On 11/19/2014 07:15 AM, Carlos E. R. wrote:

For me, the tests are (1) Can I reproduce the problem, or (2) is the proprietary module something that is likely OK. If either is true, then I will work on the problem. The nvidia drivers get a lot of testing, and are usually OK.

Well, my bug was not easy to reproduce at all. The XFS people had to analyse the situation and the code, inferring from my report that there was a real problem. They could not even try to reproduce the issue. It is a random issue, happening about once per month. What triggers it is unknown (besides that its happen on restore from hibernation), but from the analysis they knew that they could do something and did it. IF there were a way to trigger the bug at will, then I would have removed the NVidia

The bug you found was fixed with kernel commit 8018ec0, which was added to the 3.18 kernel. Although the patch looks suitable for older kernels, it was not marked as applicable to "stable", which means that it will not automatically be backported. Perhaps you need to ask the XFS devs if it has been submitted for stable kernels.

The openSUSE maintainer told me he applied it also to the 13.1 tree. As far as I know, I'm the only one reporting this particular issue on openSUSE; but as 13.2 by default uses XFS on /home, there were bound to appear more cases. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRvBxYACgkQtTMYHG2NR9XDMQCfXu1OFlBw6q4vbvNr5d9a6for J4kAn2ZTB6Z83nB3e12OubMshRTs0420 =gUr3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-11-19 09:27, Jan Engelhardt wrote:

Well, if the driver got updated when -rc1 is released rather than at -final time, things would probably go a lot smoother.

True. Maybe they delay till a major distribution uses that kernel and people complain. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRsmKEACgkQtTMYHG2NR9Ww5QCgjp/XUgMP/rZVgRWvd01LHo6h LQ0AnRbJ16cIYuunJ1HyEwMFlGmuNCPv =Iu9W -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Nov 19, 2014 at 5:19 AM, Jan Engelhardt wrote:

On Wednesday 2014-11-19 02:28, Claudio Freire wrote:

...

...

In Windows, the API functions are called by a number in a list. I thought you referred to this number changing or not. You can hardcode the numbers, or find them at runtime, if I recall correctly.

You're confused with syscalls, which linux also handles in a similar way, and keeps stable.

No confusion - check DLL ordinals.

Still not relevant. There's no DLL on the kernel. The linking process replaces trampolines generated by the compiler with actual function/variable locations in memory, which is very different from "invoking a function by number". All symbols on the kernel are public to kernel modules, and not all kernel variables have a standard and stable layout, nor do all functions have a stable calling signature, so lots of things can and do break if you load a binary module that wasn't built for your kernel specifically. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 18 Nov 2014 19:08:50 +0100 "Carlos E. R." wrote:

For instance: will nvidia drivers and vmware keep working on TW during its lifetime? Unless things have changed much, it was not recommended.

I'm more or less having to use nVidia driver now as I've found that I need it to provide sound via hdmi; same seems to apply to Radeon (fglrx). Guess I'll find out whether it becomes a problem sooner or later. - -- Graham Davis [Retired Fortran programmer - now a mere computer user] openSUSE Tumbleweed (64-bit); KDE 4.14.2; AMD Phenom II X2 550 Processor; Kernel: 3.17.2; Video: nVidia GeForce 210 (using nVidia driver); Sound: ATI SBx00 Azalia (Intel HDA) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRrmTQACgkQDFqZ4PV8pUjK1gCbBNI4EM5+DFgCpu9sykfFzMhh cf8AnRHmMMcmKRKVLX0ARDKdq7NTWWs8 =7gIf -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-11-19 07:36, Ancor Gonzalez Sosa wrote:

On 11/18/2014 05:47 PM, Christian Boltz wrote:

...

(Besides that, I'd say the real goal should be to make Tumbleweed really stable so that we can take a snapshot and call it a release.)

The robustness in Tumbleweed is only "granted" by automated tests and automated tests has limitations (at least, for something as complex as a Linux distribution). The stability and robustness expected for a Linux stable release can only be achieved by a coordinated effort of testing and fixing. And for that we need a common reference point (frozen version) AND people doing the work.

Indeed. Exactly. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRsmWEACgkQtTMYHG2NR9U55ACePloFDDuItkNTai9ZsHs2/sKl mS4Anjqlr4PVSkqcYx8tDMjXyyyN5rcf =EmbP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2014-11-21 at 00:47 +0900, Fuminobu TAKEYAMA wrote:

...

Oh well. It's nice to see the same discussion at every release: - before the release: "Can we do the freeze later?" or "Can I have a freeze exception for $whatever, please?" - after the release: "We need a longer freeze and more testing"

Do you see the pattern? ;-)

That's a typical pattern :-)

But the package was not in that pattern. Its maintainer and reviewers determined that the update should be just a bug fix update. (Actually, the update contains a new feature interacting with an application from another package)

...

We had one release with 7 betas (or more? Bugzilla lists up to 9 betas and 5 RCs) some years ago[1]. Believe me, you DO NOT want that - having that many betas or RCs means you had lots of bugs to fix, and probably have more left than in two "quick" releases ;-)

Now we have Tumbleweed and openQA. So we maybe can use RCs to fix more minor bugs than ever, I think. If the release schedule is fixed, the number of RCs will not be a problem.

Fuminobu TAKEYAMA It's a common pattern for the simple reason that there is plenty of discussion, but no action.

This last release cycle we were good with action on openQA and such. I think we need to focus on retooling our collaboration infrastructure so we can better deal with these various things. The other point for working is that we need to have better marketing communication of changes. I've found that our Google+ page seems to be our most powerful marketing and information tool. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org