[opensuse-factory] REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release
At every Opensuse release, scads of non-home repos fail to be enabled by the time of the release. As a result, we don't upgrade until WELL AFTER release -- when, in response to our incessant nagging, all the repos finally get enabled. And, since that's the 'real world' we operate in, we don't test the release in that 'real world' until AFTER the release. Is that a desired project outcome? 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. Easily solved by having those equivalent repos enabled for new distro asap ... If a devel repo has a >50% probability of being enabled eventually, it should be enabled @ release. Perhaps it'd be useful for release mgmt to create a script that goes over all devel repos and submits an SR for enabling the new repository for the new release. My bog-simple, after-the-fact script to find which repos' maintainers to nag is: cat test_urls.sh #!/bin/bash URLS=`grep ^baseurl *\.repo | cut -d"=" -f2` for u in $URLS do status=$(curl -s --head -w %{http_code} $u -o /dev/null) echo $status " @ $u" Each repo that returns a 404 sh test_urls.sh | grep 404 gets a ping/request. -- 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:07, PGNet Dev <pgnet.dev@gmail.com> wrote:
At every Opensuse release, scads of non-home repos fail to be enabled by the time of the release.
As a result, we don't upgrade until WELL AFTER release -- when, in response to our incessant nagging, all the repos finally get enabled.
And, since that's the 'real world' we operate in, we don't test the release in that 'real world' until AFTER the release.
Is that a desired project outcome?
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.
Easily solved by having those equivalent repos enabled for new distro asap ...
If a devel repo has a >50% probability of being enabled eventually, it should be enabled @ release.
Perhaps it'd be useful for release mgmt to create a script that goes over all devel repos and submits an SR for enabling the new repository for the new release.
My bog-simple, after-the-fact script to find which repos' maintainers to nag is:
cat test_urls.sh #!/bin/bash URLS=`grep ^baseurl *\.repo | cut -d"=" -f2` for u in $URLS do status=$(curl -s --head -w %{http_code} $u -o /dev/null) echo $status " @ $u"
Each repo that returns a 404
sh test_urls.sh | grep 404
gets a ping/request.
I have a better solution Stop keeping stuff in home: repos! If you want stuff in the main distributions, then get it out of a home: repo and into a devel: repo and then into Tumbleweed and Leap And then this problem goes away, and everyone benefits -- 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:27, Richard Brown <RBrownCCB@opensuse.org> 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 11/10/2015 09:30 AM, Richard Brown wrote:
On 10 November 2015 at 18:27, Richard Brown <RBrownCCB@opensuse.org> 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? -- 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 <pgnet.dev@gmail.com> wrote:
On 11/10/2015 09:30 AM, Richard Brown wrote:
On 10 November 2015 at 18:27, Richard Brown <RBrownCCB@opensuse.org> 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 11/10/2015 09:38 AM, Josef Reidinger wrote:
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.
So what's new? There are failures in existing repos ALL THE TIME. If the repo's enabled, and there are failures, then there's something to look at and work with. I.e., we can help. OTOH, No repo, nothing to work with. No help. -- 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 <pgnet.dev@gmail.com> 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
Again, I am not talking about getting them "in the release". I'm asking to have repos that we in the real world work with simply enabled. It's the click of ONE checkbox. More energy has already been spent arguing against a reasonable, simple request than fulfilling it. If you will "lose no sleep", and prefer to sit on your hands in this matter, that is your choice. Don't force that limited flexibility on others. -- 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 <RBrownCCB@opensuse.org> wrote:
On 10 November 2015 at 18:33, PGNet Dev <pgnet.dev@gmail.com> 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 11/10/2015 10:05 AM, Greg Freemyer wrote:
(Personally I'm sticking to 13.2 for my production systems for at least a few months to let some of the dust settle.)
Which is exactly the same situation we'll likely be in. The distro's always asking for help -- sooner rather than later. When there's an opportunity to get such help with the simple click of a checkbox -- so that there'd be more skilled eyes on the pre-released/just-released distro -- and the dust would settle much more quickly, there's an argument against it. It's an unfortunate irony, lacking any sense I can yet fathom. -- 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 <greg.freemyer@gmail.com> 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 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 ... If you're not interested in this solution, then stop participating in this discussion. If you want to do ... whatever the daylights it is you're suggesting ... the start your own thread, and don't hijack this one. -- 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 <pgnet.dev@gmail.com> 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
On Tue, Nov 10, 2015 at 1:42 PM, Richard Brown <RBrownCCB@opensuse.org> wrote:
On 10 November 2015 at 19:05, Greg Freemyer <greg.freemyer@gmail.com> 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
Very, very surprising. Greg -- Greg Freemyer www.IntelligentAvatar.net -- 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
On Tuesday 10 November 2015 16:01:43 Felix Miata wrote:
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?
- oS 13.2 already had KF5 (5.1), although Leap has some new applications which were not yet ported for early KF5 releases. - Leap dropped KDE3, so a bunch of packages less - oS 13.2 had gcc 3.3, 4.8 and 4.9, Leap only has 3.3 (LSB requirement) and 5.2 So although Leap dropped several hardly maintained packages, it still has more *source* packages in the core distribution. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- 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
On 11/10/2015 11:24 AM, Stefan Seyfried wrote:
But don't assume that everyone has low standards.
+1 I generally find the devel repos to be as reliable, if not more so than the distro 'release'. And, the majority of the developers that develop/maintain them are both reasonable and responsive. Which is in large part why we choose to use them in the first place, and grow to depend on them -- even in production, where we use the distro as core. -- 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
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? -- 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 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
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. 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. 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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
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. 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. (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
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
Hello, On Nov 10 21:59 Luca Beltrame wrote:
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.
I do not fully understand what you mean. Could you describe it in more detail? What I do not understand: Assume there is a project "something_useful" where packages build currently for "Leap 42" and "Tumbleweed". At some time in the future "Leap 43" starts to be made and an initial "Leap_43_alpha" respository exists. By default the "something_useful" packages are not built for "Leap_43_alpha". Now I wonder how the maintainers of "something_useful" could try out if their packages could work at all in the upcoming "Leap 43"? Do they only local builds only on their local computers? Now in contrast assume the "something_useful" packages would be built for "Leap_43_alpha": What goes wrong for "Leap 42" and "Tumbleweed" users of the "something_useful" packages? As far as I know those users would not get packages built for "Leap_43_alpha" installed when they have the "something_useful" repository enabled on their "Leap 42" and "Tumbleweed" systems. 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". 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 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)
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
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 <lbeltrame@kde.org> 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 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 -- 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 <mkubecek@suse.cz> 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 11 November 2015 at 23:16, Jimmy Berry <jimmy@boombatower.com> wrote:
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.
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. It doesn't help the development of Leap 42.1 - when we have Leap 42.2, we're going to be building it against a totally new base system (from SLE 12 SP2) So, encouraging people to build against Leap 42.1 leads to the following 1 People wasting time testing new versions of software that will almost-certainly never end up on Leap 42.1 2 Maintainers wasting time fixing build issues and debugging bugs that do not occur on Leap 42.1 and likely would not occur on 42.2 3 Sad users and Mailing List and Forum users wasting time trying to help people who broke their machines with wonderful combinations of software that would never work together (FOO from RepoA broken because of BAR from RepoB) 4 Some happy users who for a short while might be lucky enough to get something that works on their custom Leap 42.1 + Repo-of-their-choice I like 4, I absolutely hate outcomes 1-3. I therefore think it should be the responsibility of our maintainers to decide whether or not they can provide 4 without causing 1-3 by activating Leap 42.1 on their repositories Which is how they do things right now. I do not think increasing the pressure on maintainers to activate Leap 42.1 repos is a smart idea, because I do think that in the vast majority of cases, the problems with outcomes 1-3 are significantly worse than the benefits of outcome 4 *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 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. 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. 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. -- 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
Il Thu, 12 Nov 2015 14:17:31 +0100, Michal Kubecek ha scritto:
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.
It's still better than no tests. And it uncovered issues that would have been pushed to TW users otherwise.
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
And that's why you never do stats with a sample size of 1. ;) I run 3 TW machines, including this one, which is my work machine. The only times things broke was because it was my fault. Things were *much* worse with the Factory model. Of course, if sample size of 1 isn't stats, neither is 2. -- 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
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. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- 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
Johannes Meixner wrote:
[...] 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.
IOW yes, every update is a tradeoff. Assuming upstream doesn't break support for already supported printers all the time it might be worth the risk. Especially when the alternative is to train users to add 'random' obs devel projects that most likely have side effects as well. I assume the version updates are also submitted to TW so the package will get some testing from there already. And we have an update test repo (tbd for leap) where the update can stay a while longer as well. 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. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- 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
On 2015-11-13 11:34, Johannes Meixner wrote:
If package version downgrade is sufficiently easy for the user I will think about printer driver version upgrades for Leap.
Yes, but many users do not know how to do it. Ie, fire yast package manager, go to the version tab, manually select the appropriate version (which may come from the OSS repo, not from update repo), etc.
I have an additional question:
Is it possible to provide a package version upgrade for Leap in an optional way?
Yes, updates can be marked optional. YaST online update does not mark them, but they are offered on display. However, the short description (meaning a line or two) must make clear to the user that he should not apply the update unless he has this or that problem. With my user hat on, I'd say that it is very tempting to "tick" any optional update ;-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
* Michal Kubecek <mkubecek@suse.cz> [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 11/12/2015 10:35 AM, Patrick Shanahan wrote:
* Michal Kubecek <mkubecek@suse.cz> [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 :)
If it's Irish luck then I must have "A wee bit of Irish in me" as well. -:) I have not experienced any problems in time I have been using TW which is going on two years (if my failing memory is correct). -- Ken Schneider -- 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/10/2015 02:50 PM, Lars Müller wrote:
Also please don't try to fool us with such a ominously "we" usage.
Srsly? Quite the melodrama ... Good luck. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11/11/15 05:42, Richard Brown wrote:
On 10 November 2015 at 19:05, Greg Freemyer <greg.freemyer@gmail.com> 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
Op woensdag 11 november 2015 22:13:47 schreef Basil Chupin:
On 11/11/15 05:42, Richard Brown wrote:
On 10 November 2015 at 19:05, Greg Freemyer <greg.freemyer@gmail.com> 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?
Let's not make this personal. I haven't read any suggestion re. low quality of previous versions and I don't like the suggestions you're making here.
You've lost the plot, Richard. Sorry.
[pruned]
BC
-- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- 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 <pgnet.dev@gmail.com> 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
Stefan Seyfried wrote:
Am 10.11.2015 um 18:39 schrieb Richard Brown:
On 10 November 2015 at 18:33, PGNet Dev <pgnet.dev@gmail.com> 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.
That is very good of course. The problem is that it's not verifiable. A package in Factory however gives the promise to adhere to the packaging policies and that the combination with other packages in the distribution doesn't cause havoc. That promise is made by the process a package has to follow in order to get checked in. Ie a number of automated and manual checks and the application of at least four eyes principle. The process does not guarantee that an individual package is bug free of course. If you already adhere to the standards it should be only a small step to Factory inclusion.
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).
Correct me if I'm wrong but to the best of my knowledge the patch tagging is still up to the individual package or devel project. It's recommended but not mandatory. 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. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- 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
Hello Ludwig, Am 12.11.2015 um 16:35 schrieb Ludwig Nussel:
Stefan Seyfried wrote:
Am 10.11.2015 um 18:39 schrieb Richard Brown:
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.
That is very good of course. The problem is that it's not verifiable. A package in Factory however gives the promise to adhere to the packaging policies and that the combination with other packages in the distribution doesn't cause havoc. That promise is made by the process a package has to follow in order to get checked in. Ie a number of automated and manual checks and the application of at least four eyes principle.
Yes, and as I already stated, some of these policies are the reason to not submit things to Factory. 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 fledged patch header in the patch itself (and I'm the only contributor anyway). 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.
The process does not guarantee that an individual package is bug free of course. If you already adhere to the standards it should be only a small step to Factory inclusion.
(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).
Correct me if I'm wrong but to the best of my knowledge the patch tagging is still up to the individual package or devel project. It's recommended but not mandatory.
I cannot say when it happened last, but it definitely happened when submitting stuff to Factory (or Base:System, which does not really have a "project maintainer").
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. 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 :-) -- 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 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
* PGNet Dev <pgnet.dev@gmail.com> [11-10-15 12:14]:
At every Opensuse release, scads of non-home repos fail to be enabled by the time of the release.
As a result, we don't upgrade until WELL AFTER release -- when, in response to our incessant nagging, all the repos finally get enabled.
Who is "we"? I generally do upgrades when they are issued.
And, since that's the 'real world' we operate in, we don't test the release in that 'real world' until AFTER the release.
Again remains the question, who is we.
Is that a desired project outcome?
No, probably closer to a reality.
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.
Easily solved by having those equivalent repos enabled for new distro asap ...
If a devel repo has a >50% probability of being enabled eventually, it should be enabled @ release.
And who/how is it decided that ">50% probability" is met? aisi, only by a vote of *every* openSUSE (not Opensuse) user. How would you achieve that? And who is to say that that is not already the case with the inability to actually accurately determine 50%? Are you going to provide or recruit the necessary manpower to accomplish and maintain this? Intrested as this would be a *great* enhancement to openSUSE. -- (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
Am 10.11.2015 um 18:07 schrieb PGNet Dev:
At every Opensuse release, scads of non-home repos fail to be enabled by the time of the release.
Then just start nagging the developers earlier. 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.
Easily solved by having those equivalent repos enabled for new distro asap ...
Well, see above. -- 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 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. -- 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 11/10/2015 11:30 AM, Stefan Seyfried wrote:
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).
Agreed, in principle. Then again, I've no problems with repos failing -- I've an issue with the lack of having the repos, and even the failing packages -- available. If available -- even with FAILs -- there are more eyes on the problem, willing to fix. Not-so-rhetorical question: as a maintainer, when would you prefer to have additional eyes on your packages -- before or after the 'official' release of the corresponding distro?
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.
According to tacit in #irc, such an email *was* sent. The issue is that it's not acted on ... Of course it can be 'manually' worked around -- by nagging if necessary. For a distro -- maintainers and users alike -- that's always legitimately complaining about limited time & resources, choosing to continue a process that causes more work for all involved seems ludicrous. -- 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
On 10.11.2015 23:45, Jan Engelhardt wrote:
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.
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 this way. Sounds useful. -- 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
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
On Tue, 10 Nov 2015 20:26:09 +0100, PGNet Dev wrote:
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!
It's not so minority. Many devel projects containing the packages for Leap enabled the build quite some time ago. There were some announcements on ML, too, IIRC. It wasn't too trivial, no single click action, unless you know of osc tool, though. 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. Takashi -- 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
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. Why couldn't you do it before the release? The Devel Repos I maintain had leap enabled before the beta, there is no reason why you couldn't have downloaded the RC1 and started checking everything and asking developers to enable it then if you really wanted it done before the release. This may have even had the benefit of prodding a few devs to get there builds started earlier
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. Another Issue that hasn't been mentioned here yet is that enabling all
On 11/11/2015 07:44 AM, PGNet Dev wrote: those repos takes up build cycles on obs which is not a infinite resource, there are a number of home projects that are no longer maintained or used by anyone what are we gaining by automatically switching on another repo for them? Then there are the home repos that don't even have a openSUSE target currently should they be enabled as well? Cheers Simon -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (26)
-
Andrei Borzenkov -
Basil Chupin -
Carlos E. R. -
Christian Boltz -
Dominique Leuenberger / DimStar -
Felix Miata -
Greg Freemyer -
Jan Engelhardt -
Jimmy Berry -
Johannes Meixner -
Josef Reidinger -
Ken Schneider - Factory -
Knurpht - Gertjan Lettink -
Lars Müller -
Luca Beltrame -
Ludwig Nussel -
Michal Kubecek -
Patrick Shanahan -
PGNet Dev -
Richard Brown -
Simon Lees -
Stefan Bruens -
Stefan Seyfried -
Stefan Seyfried -
Takashi Iwai -
Tomáš Chvátal