On 10 November 2015 at 18:27, Richard Brown wrote:

I have a better solution

Stop keeping stuff in home: repos!

Typo - meant to say "home & non-home repos!" Point still stands, if people want those packages, get them in the distribution and maintain them properly! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 10 Nov 2015 09:33:34 -0800 PGNet Dev wrote:

On 11/10/2015 09:30 AM, Richard Brown wrote:

...

On 10 November 2015 at 18:27, Richard Brown wrote:

...

I have a better solution

Stop keeping stuff in home: repos!

Typo - meant to say "home & non-home repos!"

Point still stands, if people want those packages, get them in the distribution and maintain them properly!

I'm not speaking at all about 'home' repos. I specifically mentioned "non-home" & devel repos.

They're the ones not getting enabled that matter. I don't care one whit about a project-wide solution to 'home' repos' status; by their very nature, they're the purvue of each home:user.

And it's nonsense to expect that each/every devel repos' contents should be automatically promoted to the distribution. That's what tumbleweed is for.

And, what's "improper" about the maintenance of packages currently in the devel & non-home repos?

E.g. if I speak for Yast devel project. We often get into situation that sources do not work for released distribution as code changes. Often something missing in released distro like certain version of build tool, library, etc. So even if you automatically enable build for distro, there is no guarantee that it can build nor work. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 10 November 2015 at 18:33, PGNet Dev wrote:

And, what's "improper" about the maintenance of packages currently in the devel & non-home repos?

Devel projects & all non-home repos are not tested. Our distributions are. Devel proejcts & all non-home repos do not have to follow our packaging policies and quality standards. Our distributions do Devel projects (and the majority of non-home repos) exist for a primary purpose of *developing* packages *before* their inclusion into Tumbleweed By definition that means Devel projects and non-home repos are going to be *BROKEN* at some point Because that is precisely the place where our developers have SO they can break stuff before it hits one of our distributions In fact, if those projects are NOT breaking from time to time, then I argue that the maintainers are doing something wrong Yes, I know people like to see those projects as shortcuts to the latest version of software Yes, I know people are going to use the packages in those projects regardless of what I say Yes, I know there are some Projects which do a very good job of very carefully being 'Stable' sources of addition packages for our users But there is no way in heck I'm going to loose sleep about the fact that Leap 42.1 doesn't have those repos enabled yet when the answer is simple If people want those packages in the release of openSUSE Leap 42.1, they should have submitted them to the release of openSUSE Leap 42.1 And the same will be true for 42.2..if people want those packages in our next release next year, get them in Tumbleweed now, and make sure they get into Leap 42.2 next year. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Nov 10, 2015 at 12:39 PM, Richard Brown wrote:

On 10 November 2015 at 18:33, PGNet Dev wrote:

...

And, what's "improper" about the maintenance of packages currently in the devel & non-home repos?

Devel projects & all non-home repos are not tested. Our distributions are.

Devel proejcts & all non-home repos do not have to follow our packaging policies and quality standards. Our distributions do

Devel projects (and the majority of non-home repos) exist for a primary purpose of *developing* packages *before* their inclusion into Tumbleweed

By definition that means Devel projects and non-home repos are going to be *BROKEN* at some point

Because that is precisely the place where our developers have SO they can break stuff before it hits one of our distributions

In fact, if those projects are NOT breaking from time to time, then I argue that the maintainers are doing something wrong

Yes, I know people like to see those projects as shortcuts to the latest version of software

Yes, I know people are going to use the packages in those projects regardless of what I say

Yes, I know there are some Projects which do a very good job of very carefully being 'Stable' sources of addition packages for our users

But there is no way in heck I'm going to loose sleep about the fact that Leap 42.1 doesn't have those repos enabled yet when the answer is simple

If people want those packages in the release of openSUSE Leap 42.1, they should have submitted them to the release of openSUSE Leap 42.1

And the same will be true for 42.2..if people want those packages in our next release next year, get them in Tumbleweed now, and make sure they get into Leap 42.2 next year.

Richard, The impression I got about Leap was the support matrix was to involve a longer time commitment to support any submitted packages so I *assume* there are less packages in Leap than in openSUSE 13.2. If so, there is a greater need for users to rely on devel projects with Leap than ever before. (Personally I'm sticking to 13.2 for my production systems for at least a few months to let some of the dust settle.) Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 10 November 2015 at 19:05, Greg Freemyer wrote:

Richard,

The impression I got about Leap was the support matrix was to involve a longer time commitment to support any submitted packages so I *assume* there are less packages in Leap than in openSUSE 13.2.

You know what they say about assumptions... Leap source packages - 7829 openSUSE 13.2 source packages - 7441

If so, there is a greater need for users to rely on devel projects with Leap than ever before.

A user who 'relys' on a devel project, is relying on something that WILL fail them sooner or later Leap is for users who want something tested, reliable, that works, with stability favoured at the potential cost of some newer software versions and features Tumbleweed is for users who want something tested, reliable, that works, with the latest versions at a potential (but mitigated) cost of some newer software versions and features. In EITHER case, using anything from a devel or non-home repo is throwing out all of the effort we, the Project, expends on ensuring Leap and Tumbleweed are high quality, tested, distributions, in exchange for an untested, uncertain quality package that not only COULD be broken - it SHOULD be broken at least some of the time. PGNet Dev's post comes less than a week after the release of Leap 42.1. It paints a picture of a person who will not upgrade because some software they require is not in the main distributions. The answer is easy. If you want it in the distribution, do the work, or work with maintainers, to get it in the distributions. Suggesting that all project maintainers need to do is tick a box in OBS is foolhardy to an extreme. It requires work. Consider the following 4 questions: If it doesn't build, who's going to fix it? If it does build, who's going to test it? If it doesn't work, who's going to fix it? If it does work, who's going to keep it working? Guess what - if you have answers to all those questions, then the _proper_ solution to this problem is *get the bloody packages in the bloody distributions* If you have answers to all those questions and you do not bother getting the packages in the distribution, you're ignoring a great opportunity to benefit from all the work we do as a community to collaboratively make sure that everything we ship is built properly, built well, and works. You are on your own, you are creating more work for yourself, and guess what, that WILL mean you will screw up sooner or later, and that will mean stuff you are working on will break. and no one will be around to help you. If you don't have answers to all those questions, all pressing that tickbox in OBS produces is unhappy users. It _WILL_ break. If not today, then tomorrow, or the next day, either way, we're openSUSE, we want to deliver software to our users that works. And the way we do that, is by building two Linux distributions that are, integrated, checked, tested, polished, tested again, before being shipped, whether they are Stable or Rolling. Accept no substitute. - Rich -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 10 November 2015 at 19:48, PGNet Dev wrote:

On 11/10/2015 10:42 AM, Richard Brown wrote:

...

It paints a picture of a person who will not upgrade because some software they require is not in the main distributions.

wtf? You really have no clue what you're talking about. Try reading the OP ...

Oh I think I do..and I did read your OP

We'd test more broadly if upgrading to a new distro didn't break stuff by forcing downgrades to our prior-distro's-non-home-repo-upgraded-packages.

You'd test if we didn't force downgrades on your totally untested, unchecked, and unsupportable combination of whatever repositories you've smashed together? I'm not sure we'd really get any benefit from your testing In doing so, everything you test would be totally and utterly meaningless and unhelpful for what we're trying to do with openSUSE Leap. The second you add a Devel repo and install stuff from it, you can consider everything you find related to that software in the Devel repo to be your own fault Every bug you file related to that Devel repo, might as well be marked as INVALID This is a little less true when it comes to using Devel repos with Tumbleweed, but then the need to actually use a devel repo with Tumbleweed should be much less, given the difference between a Devel repo and Tumbleweed should always be minimal. If you want to help us testing the latest and greatest openSUSE packages, the ones that will be important for Leap 43.0 and beyond, then download and start using Tumbleweed. without Devel repos, unless you're actually a contributor to the packages in those Devel repos.

If you're not interested in this solution, then stop participating in this discussion.

I'm interested in any solution which prevents users from running unreviewed, untested, and unsupported software.

If you want to do ... whatever the daylights it is you're suggesting ... the start your own thread, and don't hijack this one.

I'm suggesting that automatically turning on Leap 42.1 for Devel Projects will lead to users breaking their own machines, will not help the development of either openSUSE Leap 42.2, 43.0, or Tumbleweed, and is therefore a _stupid_ idea. I do not use that word lightly -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Greg Freemyer composed on 2015-11-10 13:55 (UTC-0500):

Richard Brown wrote:

...

Greg Freemyer wrote:

...

...

The impression I got about Leap was the support matrix was to involve a longer time commitment to support any submitted packages so I *assume* there are less packages in Leap than in openSUSE 13.2.

...

You know what they say about assumptions...

...

Leap source packages - 7829 openSUSE 13.2 source packages - 7441

Very, very surprising.

Isn't that difference mostly or maybe entirely because 13.2 has KDE4, and Leap has a KF5 replacement that split a bunch of large packages into a bazillion smaller packages, along with other projects similarly dividing up? What's the differential in mirror space consumed? Is the -32bit count in Leap similarly larger, more, or less? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 10.11.2015 um 19:42 schrieb Richard Brown:

A user who 'relys' on a devel project, is relying on something that WILL fail them sooner or later

Richard, please stop insulting people. It's really discouraging how you claim that everybody is working carelessly and breaking everything all the time. If that's the way you work -- fine. But don't assume that everyone has low standards. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dne Út 10. listopadu 2015 20:24:56, Stefan Seyfried napsal(a):

Am 10.11.2015 um 19:42 schrieb Richard Brown:

...

A user who 'relys' on a devel project, is relying on something that WILL fail them sooner or later

Richard, please stop insulting people. It's really discouraging how you claim that everybody is working carelessly and breaking everything all the time. If that's the way you work -- fine. But don't assume that everyone has low standards.

Stefan It is not insulting everybody. If i would go with insults I could say that vdr is so broken on openSUSE I still have to use my Gentoo box to provide that. As it is not tested in openqa at all (not possible from my pov) so it only relies on you doing good job, and that is not perfect as we can't be ever without proper test coverage. 99% of develprojects are plenty of the time broken. There are always people for some reason thinking that adding LO:Factory will solve their life with libreoffice and then report bugs that I have to close as invalid. Or people desperately adding X11 stack from develprj and suddenly suprised their GA is deadlocking... And don't get me started on crazy bugs from people adding whole of devel:languages:python or any other core prj . Develprojects on big scale should not be enabled for end distribution. If there is something borked or needs update it should go via regular maintenance process for the distro or user has to go for Tumbleweed. We can even add new packages in maintenance if it is proven to be tested... Tom

On Tue, Nov 10, 2015 at 11:41:00AM -0800, PGNet Dev wrote:

Tue, 10 Nov 2015 at 08:36:08PM +0100, Tomáš Chvátal wrote:¹

...

Develprojects on big scale should not be enabled for end distribution.

So, IYO, 'Virtualization' or 'devel:gcc' (as examples) which *are* devel repos, and almost always have a newer-than-distro version should never be enabled / made available for the distro?

Tomáš wrote "on big scale". With other words: it depends! Example: We're happy if users give the code from network:samba:STABLE a try to check if a seen issue exists there too or if it is already addressed. If we get a defect report against it and all the requested information we try as good as possible to address the issue. And if possible we backport it to released products. Happier we're even if people point us to a solutuion - might it be a patch, a simple tweak in the build process, or an upstream bug report. But we're not suggesting to everyone to use the code available from network:samba:STABLE even if it is the development project. And even not if we're most of the time push this code quite frquently into openSUSE Factory. Why have we enabled openSUSE Leap 42.1 this late or at all for network:samba:STABLE? Cause we needed it to verify if a particular bug is present or not. Will we disable it now that we know what the state is? No. But other projects, developers might handle this differently. All depending on the particular project needs. With other words again it heavily depends. Instead of a heated (and a bit disappointing) discussion I suggest to contact the project maintainers and request/ suggest to enable openSUSE Leap 42.1 as build target. In general I believe a smaller and by this a less complex matrix is of advantage to the project and the _majority_ of our users. In this direction it's a good default by the web UI in the first place to display the software as it is available from the released version. Cheers, Lars ¹ please quote properly -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

Il Tue, 10 Nov 2015 12:55:52 -0800, PGNet Dev ha scritto:

distro-availble ecosystem of leading-edge software in well-if-not-officially maintained repos -- simply vanishes.

The key here is "not officially maintained". E.g., the community KDE team provides extra packages on additional repositories, but they come with *no support* as yes, things may break if upstream introduces changes, or patches have to been rebased, etc. In fact, that's why we prefer, where possible, to submit updates via the official distro mechanism (maintenance updates). And that's why at least we're not keen on auto-opening repositories for new distributions. Often packages need adjustments before doing so, and if done automatically this would just break a lot of users' software. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

11.11.2015 01:29, PGNet Dev пишет:

On 11/10/2015 01:59 PM, Luca Beltrame wrote:

...

And that's why at least we're not keen on auto-opening repositories for new distributions. Often packages need adjustments before doing so, and if done automatically this would just break a lot of users' software.

Not speaking specifically to KDE here ...

It boils down to this: if 'you' (the maintainers) want to do all the work of those adjustments by yourselves, with minimal help from other users, then don't enable the repos to make them available for users to test.

I expected this sentence to end with "to contribute". But you simply confirmed what Luca said (and you omitted in your quote) - you suggest that all hard work is done by maintainers. In this case leave it to maintainer's discretion *when* they want to do hard work.

And you'll continue with the status quo -- countless, random requests to enable those repos after release, and the subsequent issues and bugs that are reported.

If, OTOH, you'd like more resources/eyeballs/etc on the problems beforehand, minimizing the problems that actually migrate INTO the release, then enable the repos before, so we have something to work with.

It takes single mouse click to branch project/package and you already have something that you can "work with" and then contribute back. What prevents you from doing it *now*?

(There's also the issue of the distro/release repos themselves not being "in beta" prior to release date, but that's a different discussion/thread.)

This holds true whether they're auto-enabled, or manually-enabled -- simply an issue of whether we can see/use them or not, and whether you want help or not.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2015-11-11 11:08, Johannes Meixner wrote:

But when the "something_useful" packages would be built for "Leap_43_alpha" the maintainers of "something_useful" could see early if their "something_useful" packages fail to build for "Leap_43_alpha".

Additionally venturous users who have "Leap_43_alpha" installed (e.g. in a virtual machine only for testing) could download ready-made "something_useful" packages for "Leap_43_alpha" and provide feedback to the maintainers of "something_useful" how far their packages work under "Leap_43_alpha".

How about maintainers opting-in to have those new targets added automatically when the time comes? Is it possible? Then those that do not want this new feature would not be disturbed. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

I really don't get all the push back on this. The proposal has absolutely nothing to do with package quality or reliability. If people were using said repos in previous release they already take the "risk" as some people see it. Nothing changes when they upgrade to new point release of distro. All the original author was asking for was automation of a mundane repeated task...ie exactly what automation is for. As far as build errors, that again was not the question. For many repos that are not integrally tied to the core distro (ie not yast, etc) they'll almost never have issues and either way as the original author pointed out the only way to know is to try it. Seeing what build errors there are makes it a lot more likely for drive by contribution. Scenario: John needs packages from devel:somelang, but there is a build error due to newer version of gcc with an easy to apply upstream patch or flag. John files pull request and maintainers simply review (and see builds passing in John's branch). Everyone benefits, rather than maintainers waiting until they need/want the packages or someone pesters them. The whole point here is we have computers...they're already setup...they can check if the packages compile/build..why not let them? In order to make everyone happy (for those who feel there is some implied contract by enabling repos) make it an opt in or better yet an opt out feature. Either way it should be highly encouraged. This was a simple request and as I've seen many times on this list people get caught up on a lot of non-relevant side-topics. Especially given this heavily plays into power-users testing out new releases it should be considered. -- Jimmy On Wed, Nov 11, 2015 at 6:31 AM, Luca Beltrame wrote:

Il Wed, 11 Nov 2015 11:08:26 +0100, Johannes Meixner ha scritto:

...

Do they only local builds only on their local computers?

No, but given the number of people involved (contributing) the best we could check was to ensure that packages would build correctly.

But things break every now and then in devel projects, in particular when we land betas of new KDE software that need packaging adjutsments (I killed my own mail access once or twice due to missing buildrequires).

...

"Leap_43_alpha" the maintainers of "something_useful" could see early if their "something_useful" packages fail to build for "Leap_43_alpha".

That is, if there are reports of said breakage (few tested stuff when the Plasma 5 move was announced).

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Nov 12, 2015 at 12:19 AM, Michal Kubecek wrote:

On Wednesday 11 of November 2015 16:16:06 Jimmy Berry wrote:

...

The whole point here is we have computers...they're already setup...they can check if the packages compile/build..why not let them?

Well, there is always the argument of not wasting the (limited) resources of OBS.

On the other hand, current situation of new (or old) targets missing in devel (and other) projects is often worked around by people simply linking them to their own project to get the packages built. This, of course, means much bigger wasting than if the targets were enabled in the original project.

Michal Kubeček

Seems like we agree the end result is the same...the new distro gets added as a target. It's just a matter of wasting time nagging people or just flipping the switch automatically.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 12 of November 2015 13:53:48 Richard Brown wrote:

But that's the point.. "testing out new releases" is done by testing the Alphas, Betas, and RC's we provide of that new release

Testing the latest version of Software-Stack-A built against Leap 42.1 doesn't help anyone

It doesn't help the development of Tumbleweed - Devel repos built against Tumbleweed do that.

For broken builds. Not for functional bugs. I'm afraid you overestimate the dependency of bugs on overall distribution environment. In my experience, most bugs in latest upstream version of a package can be also reproduced on older versions of a distribution. Not all of them but definitely a majority. So running newer versions of selected packages does in fact help Tumbleweed (and future releases).

*especially* when we have Tumbleweed which offers the latest of everything, as soon as it's been tested and confirmed to be working with the latest of everything else

Tested to be working? You really believe running a few (mostly install) tests in OpenQA is "tested and confirmed to be working"? I don't.

People need to realise that Tumbleweed is always going to be more reliable than whatever Frankenstein they can produce by taking Leap 42.1 and adding whatever cocktail of Devel repos they think they need.

I strongly disagree here. I have complete Tumbleweed on one machine (two, actually, but the other one is one big problem itself) and 13.1 with newer versions of selected packages on few others. Based on my experience with the Tumbleweed one, I would never dare to run it on a system I rely on for my work or on my main machine at home. On the other hand, I have no problem running such systems on 13.1 with newer versions of selected packages.

And if/when there are still issues on Tumbleweed, it's infinately easier for us to fix them, and prevent them happening again, with the Factory development process, than it is when they're taking Leap 42.1 and adding a cocktail of Devel repos.

It's not infinitely easier, not by far. It can be easier for a minority of bugs; for most, it doesn't matter at all.

So yeah, I understand this seems like a simple request, but years of experience has taught us that the road requested leads to dragons, and should therefore best be avoided.

I may remember wrong but wasn't it you who reprimanded another list member few days ago for using "us/we" while actually presenting his personal opinion? Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, I think the original question was basically whether or not OBS should enable building packages for the newest openSUSE distribution in an automated way (i.e. "by default"). I think manually enabling building of selected packages for the newest openSUSE distribution is and was always o.k. Nevertheless an addendum FYI: On Nov 12 14:17 Michal Kubecek wrote (excerpt):

In my experience, most bugs in latest upstream version of a package can be also reproduced on older versions of a distribution. Not all of them but definitely a majority. So running newer versions of selected packages does in fact help Tumbleweed (and future releases).

I like to confirm this for "my" packages in the OBS "Printing" project. Cf. http://lists.opensuse.org/opensuse-factory/2015-10/msg00594.html FYI: Meanwhile epson-inkjet-printer-escpr-1.6.1 in OBS "Printing" provides PPD files for 467 printer models i.e. there are 81 more printer models available compared to Leap only via this single printer driver package. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello Ludwig, On Nov 12 16:28 Ludwig Nussel wrote:

Johannes Meixner wrote:

...

[...] FYI: Meanwhile epson-inkjet-printer-escpr-1.6.1 in OBS "Printing" provides PPD files for 467 printer models i.e. there are 81 more printer models available compared to Leap only via this single printer driver package.

So you could every once in a while submit a new version of that to Leap to make it support more printers.

Could you do me a favour and read my mail completely before you reply to small excerpts without context or alternatively do not cut away what I had written that already addresses your issue? Here again: Cf. http://lists.opensuse.org/opensuse-factory/2015-10/msg00594.html plus an excerpt that addresses your issue: ---------------------------------------------------------------- For printer driver packages a version upgrade makes sense only for those users who actually have a printer device that is not yet supported with the version that we have in Leap (which is what we have in SLE12). Because printer driver packages support very many different printer models it is less than hopeless to have them tested by us in a reasonable way which means: Basically printer driver packages are not at all tested for all the different supported printer models. Therefore a printer driver package version upgrade as maintenance update is not possible because regressions for this or that printer model are unknown in advance. Or in other words: When a printer driver package version works for a particular user with a particular printer model there is zero reason to enforce a version upgrade for that user by a general maintenance update. On the other hand when a printer driver package version does not work for a particular user with a particular printer model there is zero reason not to do a version upgrade and try out if the newer version may work for that particular model (provided the newer version claims that model is supported). Therefore what I do to provide the newest versions to users who may need them is that I build them in the OBS "Printing" project for as many openSUSE and SLE versions as possible with reasonable effort, cf: https://build.opensuse.org/project/show/Printing ---------------------------------------------------------------- This does of course not mean that other openSUSE contributors cannnt take maintainership of printer driver packages. Of course when openSUSE contributors maintain packages they can - as they like - every once in a while submit new versions of their maintained packages to Leap and maintain their new versions in Leap. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Nov 13 09:05 Ludwig Nussel wrote (excerpt):

If all that fails it's not the end of the world either as the update repo keeps previous package versions around so a downgrade is possible for the user.

Oh! This looks interesting - I did not know it. If package version downgrade is sufficiently easy for the user I will think about printer driver version upgrades for Leap. Cf. https://build.opensuse.org/project/show/Printing ---------------------------------------------------------------- In the end all software in the "Printing" project are only applications which means that your system should not "explode" when you upgrade with packages from the "Printing" project (provided you use the matching packages for your particular system). If a new version does not work it should usually help to downgrade (and to reconfigure as needed) to get it working again. ---------------------------------------------------------------- I have an additional question: Is it possible to provide a package version upgrade for Leap in an optional way? I will never enforce a printer driver version upgrade on all Leap users. I want that the user makes an explicit decision that he agrees to get the printer driver version upgrade. The reason is that I like to make sure the user knows when a printer driver version upgrade happened so that he also knows what the reason is when his printer does no longer work afterwards. Bottom line: I would prefer to get useful bug reports like "With foodriver 1.2.3 my FancyPrinter does no longer work. After downgrading to foodriver 1.2.2 it works again." and not complaints like "openSUSE messed it up! All of a sudden my FancyPrinter does no longer work!! Leap is NOT a stable system!!!" Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Michal Kubecek [01-01-70 12:34]:

On Thursday 12 of November 2015 13:53:48 Richard Brown wrote: [...]

...

People need to realise that Tumbleweed is always going to be more reliable than whatever Frankenstein they can produce by taking Leap 42.1 and adding whatever cocktail of Devel repos they think they need.

I strongly disagree here. I have complete Tumbleweed on one machine (two, actually, but the other one is one big problem itself) and 13.1 with newer versions of selected packages on few others. Based on my experience with the Tumbleweed one, I would never dare to run it on a system I rely on for my work or on my main machine at home. On the other hand, I have no problem running such systems on 13.1 with newer versions of selected packages.

And I have four local boxes running Tw with only occasional minor problems usually quickly and easily resolved and *usually* not appearing on all four boxes, a dell and an acer laptop and an hp store-bought desktop and a home built desktop (diversity). My work machine primarily for photography processing is Tw and needs to *work*. I have not experienced a 24hr period of downtime on my work machine since Greg KH initiated Tumbleweed. The others have not been on Tw as long but none of them have had a 24hr downtime either. But it might just be Irish Luck :) -- (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

On Tue, Nov 10, 2015 at 12:55:52PM -0800, PGNet Dev wrote:

On 11/10/2015 12:32 PM, Lars Müller wrote:

...

I suggest to contact the project maintainers and request/ suggest to enable openSUSE Leap 42.1 as build target.

Which is *exactly* what we do -- every release -- and is exactly the misuse of resource & time that initiated this thread. An investment of time that's apparently not considered of interest or value to the 'majority', however measured.

a) How many releases does openSUSE see? b) How many repositories require this special attention? Calculate it at your own. And then reconsider if this isn't much noise about nothing.

If this remains status-quo, then one of our historically longest & strongest arguments for Opensuse's use -- its incredibly flexible & distro-availble ecosystem of leading-edge software in well-if-not-officially maintained repos -- simply vanishes.

Nothing vanishes. And see Luca's reply too. You're panting a drama which doesn't exist.

We've alternatives for ensuring well-vetted leading-edge software repos; I'd much rather we do it 'here', but it's not in our interest to push rocks uphill by chasing down dozens of maintainers at/after every release.

We're neither 'the project', nor 'the community' that this^^ is apparently a "stupid idea" for.

So you made a suggestion and got replies which explain the different views to how and why individual openSUSE Build Service (OBS) projects handle it in different ways. In particular you got explained why your general "automatically enable the next release as build target" suggestion based on some heuristic would not work well by default for all projects. Here we're at the end of the discussion. Unfortunately you have to continue to contact the individual project maintainers approximately once in a year. Alternatively you get more involved and at the end are able to enable targets on your own. But instead of being productive you're pushing and that isn't appreciated. In particular we tried to explain to you that this isn't a simple black or white decision. But it sounds like argumentation doesn't matter. Also please don't try to fool us with such a ominously "we" usage. Either you're one user or you represent a group. But in both cases there is no need to hide behind this "we". This makes your arguments even weaker. Anyhow, here is the end of the discussion for me. There are so many more productive items to work on. Thanks, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On 11/11/15 05:42, Richard Brown wrote:

On 10 November 2015 at 19:05, Greg Freemyer wrote:

...

Richard,

The impression I got about Leap was the support matrix was to involve a longer time commitment to support any submitted packages so I *assume* there are less packages in Leap than in openSUSE 13.2. You know what they say about assumptions...

Leap source packages - 7829 openSUSE 13.2 source packages - 7441

...

If so, there is a greater need for users to rely on devel projects with Leap than ever before. A user who 'relys'

Richard, you know that the word you were looking for is "relies", don't you?

on a devel project, is relying on something that WILL fail them sooner or later

Leap is for users who want something tested, reliable, that works, with stability favoured at the potential cost of some newer software versions and features

Tumbleweed is for users who want something tested, reliable, that works, with the latest versions at a potential (but mitigated) cost of some newer software versions and features.

In EITHER case, using anything from a devel or non-home repo is throwing out all of the effort we, the Project, expends on ensuring Leap and Tumbleweed are high quality, tested, distributions, in exchange for an untested, uncertain quality package that not only COULD be broken - it SHOULD be broken at least some of the time.

Richard, WHAT *are* you jabbering about?! Are you suggesting that until Leap and the new, "re-invented" Tumbleweed which only came into prominence in recent months, that until you came on the scene and started making your pronouncements on this subject all efforts to produce earlier versions of openSUSE and Tumbleweed were simply a waste of time and were of low or, at best, of uncertain quality but now, suddenly, Leap has become a high quality product? You've lost the plot, Richard. Sorry. [pruned] BC -- Using openSUSE 13.2, KDE 4.14.9 & kernel 4.3.0-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 10.11.2015 um 18:39 schrieb Richard Brown:

On 10 November 2015 at 18:33, PGNet Dev wrote:

...

And, what's "improper" about the maintenance of packages currently in the devel & non-home repos?

Devel projects & all non-home repos are not tested. Our distributions are.

Devel proejcts & all non-home repos do not have to follow our packaging policies

Thats the reason for not submitting everything to Factory / Leap

and quality standards. Our distributions do

I do not buy that "quality standards" argument. I hold my packages in e.g. "vdr" and "vdr:plugins" projects to high standard. But vdr:plugins simply contains the things that I do not use myself or where I know that the code is not well maintained. The more commonly used things are in "vdr" or some of them even in Factory / Leap. But e.g. constant annoyance because I, as the single maintainer of these packages, using absolutely descriptive patch names and patch headers (either by using the git patch or by writing a descriptive patch header) refuse to add an additional patch tag, leads me to not bothering submitting those to Factory. (I'm not questioning that there are projects like GNOME:Factory or whatever, where people like patch tags and find them useful, but for me they are just annoying).

Devel projects (and the majority of non-home repos) exist for a primary purpose of *developing* packages *before* their inclusion into Tumbleweed

No, they exist so that people can provide quality software without the overhead of dealing with the factory policies.

By definition that means Devel projects and non-home repos are going to be *BROKEN* at some point

No. Only badly maintained ones.

Because that is precisely the place where our developers have SO they can break stuff before it hits one of our distributions

Maybe that's how you work. I have extra projects where I test the really experimental stuff before submitting it to vdr and vdr:plugins. If the best I could do was to randomly break stuff for my users, I would immediately put the packages up for adoption.

In fact, if those projects are NOT breaking from time to time, then I argue that the maintainers are doing something wrong

Thanks for your encouraging words!

And the same will be true for 42.2..if people want those packages in our next release next year, get them in Tumbleweed now, and make sure they get into Leap 42.2 next year.

Then get rid of some of those stupid policies. But your way of looking at things explains a lot of the sorry state some parts of the distributions are in... -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Nov 12 16:35 Ludwig Nussel wrote (excerpt):

The only mandatory policy in that regard is to mention added or removed patches in the .changes file in order to be able to track them.

Yes. In "my" packages in the OBS "Printing" project I do not use sophisticated patch names (not needed for packages with only a few patches) but I do carefully mention them in the .changes file (mainly because I need that for my own "lossy" brain). Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, 2015-11-12 at 22:00 +0100, Stefan Seyfried wrote:

I don't think anyone will be able to explain to me how a patch tag in the spec file increases the package quality when I already have a full

FUD ! Once and for all: PATCH TAGS ARE NOT MANDATORY. They CAN be a help for the package maintainer if the use it properly. https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines lists two variants of patch markup: * in the spec file * in the .patch itself. it is REALLY a good idea to at least do ONE of them... if you use git- formatted patches, the 2nd part is already given. A description of what that commit does should be naturally required on all serious upstream projects If you think this info is not needed, I am sure I can find examples to challenge you what a patch is good for - especially if it was there for 2 years without explanation why it was added, what bug/error it tried to address. Don't live for the moment and for yourself: live for the future and consider that other people might not have all the info in their head as you do.

fledged patch header in the patch itself (and I'm the only contributor anyway).

I hope you can never guarantee that you're the only contributor.

Before fighting such windmills (having perfectly good packages rejected just because of missing patch tags, but all the others that depend on the rejected one checked in and thus being broken was a frequenc encounter), I prefer to simply keep stuff out of Factory.

FUD (I could repeat above statement.. but I guess it's clear that PATCH TAG LINES in the spec are NOT MANDATORY

...

 

...

(I'm not questioning that there are projects like GNOME:Factory or whatever, where people like patch tags and find them useful, but for me they are just annoying).

so don't use them - but make sure it's clear what the patch does in one way or another (patch description inside the .patch file for example)

...

The only mandatory policy in that regard is to mention added or removed patches in the .changes file in order to be able to track them.

And even this is often questionable when it is only the obvouis post-release build fix which was already accepted upstream and will automatically be removed next version update because it will only reverse apply anyway.

If you object that much adding a simple statement that you added a patch: ask upstream to release a build fix brown paper bag release - if they can't manage release tarballs to build properly, I'm sure a quick fix release should not be an issue (yes, I've seen such cases as well and in no case did I have an issue to convince an upstream to re- release a fixed tarball)

It's nice to have lots of policies to enforce and give people the power to reject the work of others, but don't be surprised if those othere decide to spend their time on more rewarding projects :-

/you really misunderstand the use of the guidelines - they are not there to give the power to reject - like in every review process, they are there to give a sort of consistency across the board. Try to submit a fix to any serious upstream.. you will get stuff rejected for using "main();" instead of "main ();" (or vice-versa) So far, we do not have a 'no white space policy enforced in Factory' Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 10.11.2015 um 20:26 schrieb PGNet Dev:

On 11/10/2015 11:08 AM, Stefan Seyfried wrote:

...

For example, I have enabled building for Leap in "my" devel repos "vdr" and "vdr:plugins" since quite some time, I'd guess about six weeks ago already.

Then, IMO, you're in the under-appreciated minority. Thanks!

Nagging's a waste of everyone's time, and unpleasant to boot -- particularly in the case that a well-considered process can solve the problem.

Well, OTOH I would certainly object if someone (besides my co-maintainers) would just start enabling build targets for my repo (and me getting build fail notifications etc). So politely asking people here and on opensuse-packaging to enable their repos for $NEXT_UPCOMING_RELEASE is probably the best we can do now. Maybe we can implement something in OBS that reminds people (and maybe helps them to enable it on all their packages / repos easily), but then there are developers like me, who only sporadically log on to the OBS webfrontend and thus won't see it anyway. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2015-11-10 20:30, Stefan Seyfried wrote:

Maybe we can implement something in OBS that reminds people (and maybe helps them to enable it on all their packages / repos easily), but then there are developers like me, who only sporadically log on to the OBS webfrontend and thus won't see it anyway.

Why just remind them? We could have a add_repository type SR, similar to the delete_repository type(*), and involved people will be email notified as usual. (*) More exactly, this one is a "delete" type SR with a repository="" XML attribute. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hallo Leute, Am Donnerstag, 12. November 2015 schrieb Stefan Seyfried:

...

Why just remind them? We could have a add_repository type SR, similar to the delete_repository type(*), and involved people will be email notified as usual. That would be great. I, for example, try to not enable too much repos in my projects to save build power, and because of this e.g. SLES12 is not enabled. But if people need / want it, they could request it

On 10.11.2015 23:45, Jan Engelhardt wrote: ... this way. Sounds useful.

I agree, and therefore opened a feature request ;-) https://github.com/openSUSE/open-build-service/issues/1370 Regards, Christian Boltz -- The goal is simple: no more gnome related bugs in the 12.2 release :) (ok, we ARE optimists). [Dominique Leuenberger in opensuse-factory] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

It's not so minority.

I was referring more to the 'under-appreciated' ...

Many devel projects containing the packages for Leap enabled the build quite some time ago.

On the day of release, when i started to track the superset of Opensuse v* non-home/devel repos used across our linux developers, there were 47 that were not enabled, reporting 404s. After the nagging "phase", I'm down to just 6 that are reporting 404s. Once that #'s == 0, then we'll start testing the release in our real-world environments.

There were some announcements on ML, too, IIRC. It wasn't too trivial, no single click action, unless you know of osc tool, though.

Most of the to-be-enabled repos did the trick immediately after enabling; couple of minor exceptions required some back & forth, but were fixed by responsive developers. Exactly the process I'd prefer we were doing before the release. But as I mentioned in last post, not pushing that rock uphill.

So, basically your request was already possible by a manual action all the time. But the missing piece is the communication, it could have been better advertised.

IIUC, it *was* communicated. Maybe it could have been *better* communicated. Follow-through & follow-up are what's lacking in many cases. That it was possible manually has never been in question. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org