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 curren
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, the
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 d
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
On Tue, Mar 09, 2010 at 14:06:12 -0500,
Doug Ledford 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 lived through the
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
On Tue, 2010-03-09 at 19:39 +0100, Kevin Kofler wrote:
> Jesse Keating wrote:
> > Yes, you bear some risk in using rawhide. There is no reward without
> > risk. We can mitigate some of that risk by placing automated testing
> > between the builds and the users. Some reduction in risk is far bett
Jesse Keating wrote:
> Yes, you bear some risk in using rawhide. There is no reward without
> risk. We can mitigate some of that risk by placing automated testing
> between the builds and the users. Some reduction in risk is far better
> than no reduction is it not? Would it not be nice to see
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
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 fles
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
>
Hi,
On 03/05/2010 06:32 PM, Toshio Kuratomi wrote:
> 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
Hi,
On 03/05/2010 06:56 PM, Doug Ledford wrote:
> 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 bel
Doug Ledford wrote:
> and in those days Fedora Core did in fact have the more conservative
> update style as a general rule.
Oh really?
http://lists.fedoraproject.org/pipermail/announce/2005-December/thread.html#1678
| Fedora Core 4 Update: arts-1.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update:
On 03/05/2010 03:58 PM, Kevin Kofler wrote:
> Doug Ledford wrote:
>> It comes with less extra work than doing two update streams. Face it,
>> there is *no* solution to this problem that both solves the issue for
>> both parties involved and does not include at least *some* extra work
>> for you.
>
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 poli
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
> th
Am Freitag, den 05.03.2010, 12:56 -0500 schrieb Doug Ledford:
> There should be room for human judgment to
> play a role.
One of the most sensible comments I read!
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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 pa
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, be
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 ef
On Fri, 2010-03-05 at 11:30 +0100, Nicolas Mailhot wrote:
>
> Le Jeu 4 mars 2010 23:09, Till Maas a écrit :
>
> > And they must pass all AutoQA tests, which is not a big issue currently,
> > but will be if AutoQA becomes what I would like it to be.
>
> People seem to assume AutoQA is going to be
Le Jeu 4 mars 2010 23:09, Till Maas a écrit :
> And they must pass all AutoQA tests, which is not a big issue currently,
> but will be if AutoQA becomes what I would like it to be.
People seem to assume AutoQA is going to be black/white tests. However, I
think we'll need automated warnings too
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 asked for it. :-)
> Reasons:
>
> 1) Most
On Fri, Mar 05, 2010 at 06:46:01AM +0100, Kevin Kofler wrote:
> 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)-upd
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
Doug Ledford wrote:
> You only need enough details to know that it isn't impossible, not
> enough to know the exact route to get to the end goal.
Only an actually working implementation, or a detailed technical description
of one, can prove that it really isn't impossible and doesn't lead to
uns
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 stu
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, a
Doug Ledford 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 has in fact been t
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 pro
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 la
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 was all about technical issues he saw. Tech
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 t
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
35 matches
Mail list logo
