REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

classic Classic list List threaded Threaded
63 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

PGNet Dev-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

Richard Brown
On 10 November 2015 at 18:07, PGNet Dev <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

Richard Brown
On 10 November 2015 at 18:27, Richard Brown <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

PGNet Dev-2
On 11/10/2015 09:30 AM, Richard Brown wrote:

> On 10 November 2015 at 18:27, Richard Brown <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

Patrick Shanahan-2
In reply to this post by PGNet Dev-2
* PGNet Dev <[hidden email]> [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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

Josef Reidinger-3
In reply to this post by PGNet Dev-2
On Tue, 10 Nov 2015 09:33:34 -0800
PGNet Dev <[hidden email]> wrote:

> On 11/10/2015 09:30 AM, Richard Brown wrote:
> > On 10 November 2015 at 18:27, Richard Brown
> > <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

Richard Brown
In reply to this post by PGNet Dev-2
On 10 November 2015 at 18:33, PGNet Dev <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

PGNet Dev-2
In reply to this post by Josef Reidinger-3
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

PGNet Dev-2
In reply to this post by Richard Brown
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

gregfreemyer
In reply to this post by Richard Brown
On Tue, Nov 10, 2015 at 12:39 PM, Richard Brown <[hidden email]> wrote:

> On 10 November 2015 at 18:33, PGNet Dev <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

PGNet Dev-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

Richard Brown
In reply to this post by gregfreemyer
On 10 November 2015 at 19:05, Greg Freemyer <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

PGNet Dev-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

gregfreemyer
In reply to this post by Richard Brown
On Tue, Nov 10, 2015 at 1:42 PM, Richard Brown <[hidden email]> wrote:

> On 10 November 2015 at 19:05, Greg Freemyer <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

Richard Brown
In reply to this post by PGNet Dev-2
On 10 November 2015 at 19:48, PGNet Dev <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

Stefan Seyfried
In reply to this post by PGNet Dev-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

Stefan Seyfried
In reply to this post by Richard Brown
Am 10.11.2015 um 18:39 schrieb Richard Brown:
> On 10 November 2015 at 18:33, PGNet Dev <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

Stefan Seyfried
In reply to this post by Richard Brown
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

PGNet Dev-2
In reply to this post by Stefan Seyfried
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REQUEST implementing process to enable non-home/devel repos for a new release PRIOR to its release

PGNet Dev-2
In reply to this post by Stefan Seyfried
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: [hidden email]
To contact the owner, e-mail: [hidden email]

1234