On 09/03/10 19:06, Doug Ledford wrote:
On 03/09/2010 11:45 AM, Kevin Kofler wrote:
Jesse Keating wrote:
Slight variation on this. All builds from devel/ (or master in the new
git world) would go to the koji tag dist-rawhide-candidate. Builds
which are tagged with
On 03/09/2010 07:46 PM, Kevin Kofler wrote:
Doug Ledford wrote:
Things like the libata kernel change and KDE 3 to 4 migration are
intentional events
That's the whole problem. Under our current model, we have places and times
where to perform those intentional disruptive changes, they're
Doug Ledford wrote:
You're assuming that each flag day will in fact be one where the user
has to do something. That's not necessarily true. The hda-sda switch
happened, what, 2 years or more ago? Yeah, it was a big deal. We've
not really had an event like that since, and don't currently
On Tue, Mar 09, 2010 at 14:06:12 -0500,
Doug Ledford dledf...@redhat.com wrote:
Things like the libata kernel change and KDE 3 to 4 migration are
intentional events and all that's needed to make the transition smooth
is to coordinate the release of a seamless upgrade package set. You
I
Doug Ledford wrote:
Things like the libata kernel change and KDE 3 to 4 migration are
intentional events
That's the whole problem. Under our current model, we have places and times
where to perform those intentional disruptive changes, they're called
releases. In a consumable Rawhide, we
Jesse Keating wrote:
Slight variation on this. All builds from devel/ (or master in the new
git world) would go to the koji tag dist-rawhide-candidate. Builds
which are tagged with dist-rawhide-candidate trigger AutoQA tests, of
the nature rawhide acceptance (this would have to get fleshed
On Tue, 2010-03-09 at 17:45 +0100, Kevin Kofler wrote:
The assumption is that automated QA catches all possible breakage, which is
not true. In fact *no* QA will catch all the Rawhide breakage as some is
caused by the mere fact of things being different, which is intentional and
part of
On 03/09/2010 11:45 AM, Kevin Kofler wrote:
Jesse Keating wrote:
Slight variation on this. All builds from devel/ (or master in the new
git world) would go to the koji tag dist-rawhide-candidate. Builds
which are tagged with dist-rawhide-candidate trigger AutoQA tests, of
the nature rawhide
On Thu, 2010-03-04 at 15:59 -0500, Doug Ledford wrote:
1) Make rawhide consumable.
A) Create rawhide-unstable. Any time a known disruptive change is
being worked on, it should be built here by the developer. In
addition, add rpmdiff checks to all builds from devel into
Till Maas wrote:
F13 updates will be supported until F15 Alpha is created, so
everyone has a about a three month update window to get from FN-updates to
F(N+1)-updates or F(N+1)-updates-stable.
FN-updates to F(N+1)-updates-stable is unlikely to work, because FN-updates
will be including stuff
On Fri, Mar 05, 2010 at 08:52:56AM +0100, Hans de Goede wrote:
One size does still not fit all, although this is a great idea for
most packages in Fedora for packages in certain niches this is a bad idea.
I've said this before (and got 0 response), I believe there should
be some divide made
On Fri, Mar 05, 2010 at 08:52:56AM +0100, Hans de Goede wrote:
Make rawhide consumable as a semi-rolling release itself.
We already have this it is called early branching of the next release. I
would fully agree with you if it were not for the early branching
feature, which means we
On 03/05/2010 04:49 AM, Kevin Kofler wrote:
Doug Ledford wrote:
So, I'm going to reiterate my policy suggestion:
Make Fedora releases (all of them) stable in nature, not semi-rolling.
Make rawhide consumable as a semi-rolling release itself.
And let me reiterate my objections, because you
On 03/05/2010 02:52 AM, Hans de Goede wrote:
One size does still not fit all, although this is a great idea for
most packages in Fedora for packages in certain niches this is a bad idea.
I've said this before (and got 0 response), I believe there should
be some divide made between core
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
On Fri, 05 Mar 2010 12:56:11 -0500, Doug wrote:
It seems obvious to me that even if
we made a policy that Fedora was primarily stable once released, that
there would always be exceptions to that rule and things that should be
updated more aggressively. So I would not advocate for any policy
Obviously, some people want this and some don't. It isn't appropriate
to simply hand down an edict that things will be one way or the other if
we truly consider Fedora a community run project. It must be a
community decision. That means, as Adam Williamson pointed out, this is
likely a decision
On Thu, Mar 04, 2010 at 03:59:16PM -0500, Doug Ledford wrote:
But let's be clear. That's a *policy* decision. One of the things that
got very confusing in the previous thread(s) was the intermixing of
policy decisions and technical issues. For instance, Kevin's response
So, I'm going to
Doug Ledford wrote:
[the whole nine yards]
I like this idea. As a user of fedora updates-
testing and kde-redhat, in order to get the
latest software the soonest onto my computer,
without having the burden of reinstalling my
system twice a year on 2 computers, x86_64
desktop and i686/PAE
On 03/04/2010 06:27 PM, Kevin Kofler wrote:
Doug Ledford wrote:
But let's be clear. That's a *policy* decision. One of the things that
got very confusing in the previous thread(s) was the intermixing of
policy decisions and technical issues. For instance, Kevin's response
to my proposal
Doug Ledford dledf...@redhat.com writes:
Limitations, yes. Current state, no. You can't make a policy to do the
impossible and expect it to just happen. But you *can* make a policy to
do the very hard and seemingly impossible and make it happen. To that
end I reference the fact that man
Hi,
On 03/04/2010 09:59 PM, Doug Ledford wrote:
Obviously, some people want this and some don't. It isn't appropriate
to simply hand down an edict that things will be one way or the other if
we truly consider Fedora a community run project. It must be a
community decision. That means, as
22 matches
Mail list logo
