Fedora BECAUSE of the version
upgrades!)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Rakesh Pandit wrote:
Well, update to latest release (every 6 month) and you will get latest
and greatest anyway.
With a wait of up to 6 months. That's way too long. That leaves Rawhide,
which isn't suitable for production use. So no option left.
Kevin Kofler
--
devel mailing list
months as
point releases. Have an annual roll-up release and then keep rolling.
Therefore, that suggestion would not work as well as the status quo.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
still
provide an option to those of us who like the updates, at least if it
actually works (i.e. if it doesn't lead to maintainers only caring about the
conservative stream).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
metadata after the fact at this time. Bodhi admins
might be able to do it, but maintainers definitely aren't.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
James Antill wrote:
On Wed, 2010-03-03 at 07:38 +0100, Kevin Kofler wrote:
People who use updates-testing under the current system are signing up to
doing testing. Under your proposal, they'd be forced to sign up to get
any current updates.
Get current updates = so they can be tested
the
package itself. We have a packaging guideline for initscripts:
https://fedoraproject.org/wiki/Packaging:Guidelines#Initscripts
Currently, only SystemV-style initscripts are supported in Fedora.
https://fedoraproject.org/wiki/Packaging:SysVInitScript
This guideline MUST be followed.
Kevin Kofler
, but having stuff be fixed only in the
next Fedora release is unacceptable.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Mathieu Bridon wrote:
On Wed, Mar 3, 2010 at 18:27, Kevin Kofler kevin.kof...@chello.at wrote:
We can't change Bodhi metadata after the fact at this time. Bodhi admins
might be able to do it, but maintainers definitely aren't.
Where's the RFE ticket?
I've never felt the need
, it didn't even have a testing
repo at all (!), but it still worked.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
things, e.g. KOffice 2 is not
a suitable update for a release which shipped with KOffice 1 (and indeed KDE
SIG is not pushing that one, we are not the insane mindless push
everything drones people are portraying us as!).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
rawhide) to be able to use latest versions with features they want.
... sure you can.
Not if you want to keep your users. Rawhide is no option for many users.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
the updates and won't answer any
question until they do. I'm not going to waste my time trying to debug
already fixed problems in old versions of KDE.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
-in choice), when actually the regular
updates is what most of our users would be best off with (at least IMHO).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
write that down anywhere).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Juha Tuomala wrote:
On Wed, 3 Mar 2010, Kevin Kofler wrote:
You're distorting the Fedora model to accommodate KDE roadmaps.
No, this goes far beyond KDE. KDE roadmaps are just one strong argument
for doing things this way. Many more packages benefit or would benefit
from version upgrades
Chris Adams wrote:
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
Usually, the first question I ask is Do you have all updates installed?
If the answer is no, I ask them to install the updates and won't answer
any question until they do. I'm not going to waste my time trying
benefit of making us even MORE more up to date than
Ubuntu.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
a pure rolling to a semi-rolling model but
then would we need to have a rawerhide?
Our stable releases are already semi-rolling (at least in some sense), why
can't we just keep things the way they are?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
.
And those initscripts belong directly in the package, not some subpackage
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
and F12 updates and works
fine there, though I didn't bother testing this as clearly nobody cares
about the KDE spin test results anyway), so nobody cares.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
? Or should the translation
updates be pushed directly to stable? Otherwise there's no way they can be
in your compose in only 2 days.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
need to re-think that proposal again.
You mean the KDE stability proposal? As this is F11, i.e. previous stable,
KDE 4.4 would actually not have been pushed to F11 under that proposal.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
filed etc.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Enrico Scholz wrote:
Kevin Kofler kevin.kof...@chello.at writes:
The mandatory (MUST) guideline is that %post MUST NOT OUTPUT anything
this means only output like license agreements, but not diagnostic
output on stderr
No, diagnostic output is also not allowed, especially not when
.
If we only could get KDE SIG to start thinking like their upstream
have intended them to think, lot of people wouldn't be in this mess
right now.
Upstream has no policy about what kind of releases are to be provided as
updates, this is a distribution decision.
Kevin Kofler
--
devel
Juha Tuomala wrote:
On Thu, 4 Mar 2010, Kevin Kofler wrote:
I would argue having this within Fedora infrastructure would be better as
it would prevent proliferation of third-party repos replacing Fedora
packages and the resulting compatibility issues (see e.g. the chaos we're
having for RHEL
cause more chaos, crossing
fingers. The resource-eating Strigi file indexing will stay disabled by
default in F11 and F12, of course.)
It's just that it's a more productive use of everyone's time to help fixing
the issues instead of complaining about what's already done.
Kevin Kofler
?). So the only thing we can do
is to try to prevent such a policy from being passed in the first place.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
just because it
doesn't happen in GNOME.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Chris Adams wrote:
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
It's actually almost no extra work to build the updates also for the
previous stable release. We have to build them for the current stable
anyway. It just means doing the usual routine (copying the specfile
.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
which is only in F(N+1)-updates, not F(N+1)-updates-
stable.
(And FWIW, I'd call them conservative rather than stable, I don't like
the implication that the other stream would be unstable, which to most
users means crashy.)
Kevin Kofler
--
devel mailing list
devel
other
committee deciding otherwise doesn't change this, it's like deciding that
apples are fruit and any other fruit can only be an orange fruit, a
pear fruit etc., but not a fruit because only apples are that). :-/
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
really work on
that kind of software.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Juha Tuomala wrote:
On Thu, 4 Mar 2010, Kevin Kofler wrote:
What bugfix releases would we be supposed to push? There are no further
4.3.x releases.
Nothing, if that's the case.
That means bugs will no longer be fixed, is that a price we want to pay just
to avoid the small risk
it from the NFS
home directory.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
libs that are actually needed.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
because of unresolved symbols, that's not any more acceptable
for KDE than it is for GNOME or any other desktop?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
, we will import it to Rawhide first, and kde-redhat unstable
will get builds of the same stuff.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
no metric that actually works to magically figure that
out. Date of creation does not work because the targeted release can get
changed after the fact. So fixing things manually where the script makes an
unwanted change or doesn't make a wanted change is the only way.
Kevin Kofler
--
devel
regenerate the full metadata, the
more the incremental one grows).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
For all those who're claiming users don't want upgrades like KDE 4.4.0:
http://lists.fedoraproject.org/pipermail/users/2010-February/367266.html
http://lists.fedoraproject.org/pipermail/kde/2010-March/006102.html
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
Mike McGrath wrote:
On Fri, 5 Mar 2010, Kevin Kofler wrote:
For all those who're claiming users don't want upgrades like KDE 4.4.0:
http://lists.fedoraproject.org/pipermail/users/2010-February/367266.html
http://lists.fedoraproject.org/pipermail/kde/2010-March/006102.html
Now, lets see
easy to close those as NOTABUG (sorry,
multilib is not supported for this package, just use the 64-bit version).
If those reports become a big problem, isa-based Conflicts tags could be
added.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
second-
class citizens for having to wait longer, those who don't want it just don't
want it at all, staged or not.
So I don't think staged updates are a workable solution (there's a reason
almost no maintainer works that way at this time).
Kevin Kofler
--
devel mailing list
devel
Doug Ledford wrote:
On 03/05/2010 04:49 AM, Kevin Kofler wrote:
Yet it is the only solution which really satisfies both groups of people.
You should always be more clear when writing emails such as this. The
Yet it is above is unclear. Are you referring to a stable rawhide, or
the two
duplication in the repos, smaller metadata for those
of us with pure 64-bit systems etc.), unlike some gratuitously removed
options in e.g. GNOME.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
to handle this kind of
changes in a smooth way. But automated QA will also miss many actual bugs.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
?
If they're happy with Ubuntu, Winblow$ or whatever, let them use what
they're happy with. Just blindly copying the competition helps no one.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
place, but
even if it was, that doesn't say anything about our update policy. Well,
actually it even says that it was good that version updates were allowed
because 4.1 and 4.2 were big improvements.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
as a
whole. The fact that what you're saying is so clearly wrong makes this all
the more an issue.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
a
waste of time and effort to even consider it. Software will never be perfect
anyway.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
policy.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
, that statement sounds more
like something out of The Onion than like something one can actually claim
with a straight face!
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Matthew Woehlke wrote:
You forget people developing proprietary software...
Why would we want to encourage or even support that?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
directly to
stable (which by its own would already be annoying enough).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
queueing N and queueing N-1).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
. I'm just proposing not to raise it, as the current
setting of the bar is already optimal.
I'm sorry Kevin, but you and I will simply have to agree to disagree. I
will *not* capitulate to your stance on this issue.
But I think you're entirely missing my point!
Kevin Kofler
--
devel
in the previous stable release
not getting bugfixes in a timely manner, if at all, anymore, as it has a lot
fewer testers.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
is an implementation of the M$ Exchange protocols, allowing Free
Software groupware clients to interoperate with M$ Exchange.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
explicitly requested or required by dependencies
(This has now been the default for several Fedora releases anyway.),
* yum install glibc.i686.
You don't actually need multilibbed x86_64 repositories.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
that it makes it worth delaying all
updates, including bugfixes, while waiting for testing that may never arrive
(because those folks who like testing things tend to run the current stuff)?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
option and require explicitly picking the
wanted 32-bit stuff from the 32-bit repo, that shouldn't be a real issue for
you.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
the release to be supported equally throughout its lifetime.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
not a solution for Fedora at all. It's a completely different package
manager (competing with RPM). It also works by keeping all the old versions
of all packages stored on disk all the time, a massive waste of disk space,
and also not compliant with the FHS (Filesystem Hierarchy Standard).
Kevin
a 3 month gap, not 6 months. In my opinion, I don't
think it is entirely unreasonable to wait 3 months for a major new
release.
I disagree. Sorry.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
.
If the application is in Fedora as all applications eventually ought to be,
we will take care of rebuilding it. Otherwise, whoever built it (some third-
party repository or the user him/herself) is responsible for rebuilding it.
This has always worked fine, I don't see the problem.
Kevin
is not really negotiable.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
, and if
that breaks, that's going to be a very big issue for that somebody.
But if they're outdated, that can also be a big issue. Some leaf packages
are under heavy development, so users don't want to run old versions, nor do
upstream developers want them to.
Kevin Kofler
--
devel
it once is not going to be the end of the world.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
is not broken if whoever built it does his/her job. It's not
like there's no notification about soname bumps (when done right; I know
some people do not follow procedures, but then that's the problem, not the
soname bump).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
Chris Adams wrote:
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
The average is 3 months which is just as unreasonable.
Why? What do you consider a reasonable interval?
The time it actually takes to test the update. I.e. at most 3 weeks.
For example (just an example
the current release. And no, backporting fixes is often
not practical.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
about it ahead of time, there is no dumping things on people overnight.
Except it's not a mini-release. You can't just stay on the old branch (and
still get security, bugfix and other nondisruptive updates) if you aren't
ready for the change as you can with our releases.
Kevin Kofler
Fedora. What
counts is that all software in Fedora depending on the library gets rebuilt
and pushed at the same time. (That's what grouped updates are for.) We do
not support third-party software.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
a library with the wrong soname is quite clear!
And the next time it happens, you know that you should just make clean; make
before checking anything else if something like this happens.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
broadband Internet connection to Fedora's
system requirements all the time. It is pretty much a requirement in
practice.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
away some of our
unique advantages.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
double as some form of ABI
guarantee.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Matthew Garrett wrote:
users do do things like download stuff and run ./configure; make; make
install
Why would we even try to support that? Packaging exists for a reason.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
not be compiling software. :-)
In this context, if you're writing homegrown apps, you're a developer, not
a user, so the above sentence obviously does not apply. Instead, my
original point does (you'll be compiling your own software very often
anyway).
Kevin Kofler
--
devel mailing list
to support that?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Andrew Haley wrote:
Because we don't despise our users. I don't, anyway.
If we don't despise our users, we shouldn't let them use crap like third-
party connectivity software which isn't even packaged properly. :-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
application, at least within our repository. Those routinely get
bumped, and I really don't see why we'd need to stop that.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
dial-
up is usually metered (by time duration of use, so reducing bandwidth
requirements only helps indirectly) whereas broadband is usually on a
flatrate.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
try to coordinate to reduce the amount of grouped updates,
e.g. libmtp and other such libraries such as libnjb often get updated
together, and they frequently come together with some new version of Amarok
as well.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
their
bandwidth to get current software use?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
. Especially for the conservative
folks, this will be a big annoyance. With low bandwidths, you have to get a
CD/DVD shipped each time! In addition, I think the inconsistency will
confuse our users a lot.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
who cannot wait those couple months, can do checkout
and compile themselves.
What about the thousands of non-security bugs? Do you not want those fixed?
All large software projects have thousands of bugs.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
conservative (e.g. GNOME, Firefox).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
on the Fedora end.
:-(
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
upstream projects simultaneously.
(And no, upstream projects won't all align to the same schedule, no matter
how much Mark Shuttleworth pushes for that.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Simo Sorce wrote:
On Fri, 12 Mar 2010 21:21:41 +0100
Kevin Kofler kevin.kof...@chello.at wrote:
The problem with all the proposals centered on the idea of N-1 as
conservative, N as less conservative, including yours above and
jreznik's, is that it forces all the people who expect
Simo Sorce wrote:
On Fri, 12 Mar 2010 21:18:11 +0100
Kevin Kofler kevin.kof...@chello.at wrote:
The problem is, if all the
distributions optimize for people with low bandwidth, then what
should people like me who have higher bandwidths and would like to
use their bandwidth to get current
to integrate.
That is still too slow for many of our users.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
of view difference indeed. But the former is the
point of view many of our users defend, too. :-) See e.g. the results of
Adam Williamson's poll.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
601 - 700 of 4295 matches
Mail list logo
