On 03/13/2013 12:02 PM, Kevin Fenzi wrote:
2) You can take the longer release time, get the new codebase in and
done and then you are in much better shape moving forward.
We choose 2.
(Anaconda folks, feel free to drop in and correct me if I got anything
wrong).
I can't see much way to explai
On Tue, 12 Mar 2013 23:23:35 +0100
Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > Why? if we reverted no work would have gone on on the new codebase
>
> That's the whole problem. The Anaconda team cannot manage to develop
> in a branch or trunk which is only put into Rawhide when it's ready.
Well
On Tue, Mar 12, 2013 at 11:23 PM, Kevin Kofler wrote:
> Kevin Fenzi wrote:
>> Why? if we reverted no work would have gone on on the new codebase
>
> That's the whole problem. The Anaconda team cannot manage to develop in a
> branch or trunk which is only put into Rawhide when it's ready.
I've bee
Kevin Fenzi wrote:
> Why? if we reverted no work would have gone on on the new codebase
That's the whole problem. The Anaconda team cannot manage to develop in a
branch or trunk which is only put into Rawhide when it's ready. Somehow all
other upstreams manage, even where they happen to be Red H
On Mon, 11 Mar 2013 19:55:39 +0100
Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > Well, not sure it would. If builds were tagged into f19-pending and
> > the tests ran from that, then tagged into f19, the max delay would
> > be when a newrepo just started and it has to wait for the next
> > newrepo
Kevin Fenzi wrote:
> Well, not sure it would. If builds were tagged into f19-pending and the
> tests ran from that, then tagged into f19, the max delay would be when
> a newrepo just started and it has to wait for the next newrepo to be
> added. The min delay would be that it gets added and newrepo
On Mon, 11 Mar 2013 03:49:38 +0100
Kevin Kofler wrote:
> Miloslav Trmač wrote:
> > If a new package doesn't break tests, it will tagged into rawhide
> > immediately or overnight - just like now. No extra work needed, no
> > change in workflow.
>
> Running the tests alone will slow down chain bu
Michael Scherer wrote:
> Given the target of rawhide, I expect people to be able to clean the
> unneeded packages after a while. Heck, like they do for packages that
> got orphaned and removed.
My concern is not Rawhide, my concern is stable releases, especially if one
upgrades from one release o
Le lundi 11 mars 2013 à 03:44 +0100, Kevin Kofler a écrit :
> Michael Scherer wrote:
> > A few wasted mega of disk space do not seems to be big problem if that
> > permit to have more people on rawhide, faster tests and faster feedback.
>
> Old libraries accumulate over the lifetime of an install
Miloslav Trmač wrote:
> If a new package doesn't break tests, it will tagged into rawhide
> immediately or overnight - just like now. No extra work needed, no
> change in workflow.
Running the tests alone will slow down chain builds significantly, even if
the builds get tagged immediately after
Michael Scherer wrote:
> keeping unused library is not worst that keeping old perl modules.
Conceptually, keeping old Perl modules is just as bad. Our Perl packaging
does not keep old versions lying around either!
Practically, libraries tend to be a lot larger than Perl modules.
> A few wasted
On Wed, Mar 6, 2013 at 11:15 PM, Bill Nottingham wrote:
> Colin Walters (walt...@verbum.org) said:
>> On Tue, 2013-03-05 at 16:58 -0500, Bill Nottingham wrote:
>>
>> > We don't ship in a way that easily allows this though, now. Admittedly,
>> > this is due to the sheer *amount* of stuff involved i
Le mardi 05 mars 2013 à 23:26 +0100, Kevin Kofler a écrit :
> Olav Vitters wrote:
> > Mageia packages libraries by the .so major version. So you can upgrade a
> > library and then work on rebuilding all the software.
> >
> > Example (library name is not too important):
> > lib64spice-client-gtk3
On Thu, Mar 7, 2013 at 5:17 PM, Rahul Sundaram wrote:
> On 03/07/2013 05:16 PM, Adam Williamson wrote:
>>
>> I don't know for sure, but I'm not aware of any, sadly. A lot of the
>> discussion happened in a big free-for-all that ensued from the flaming
>> wreckage of spot's talk on a proposed new r
On 03/07/2013 05:16 PM, Adam Williamson wrote:
I don't know for sure, but I'm not aware of any, sadly. A lot of the
discussion happened in a big free-for-all that ensued from the flaming
wreckage of spot's talk on a proposed new release cycle (not spot's
fault, but the discussion of his proposa
On Thu, 2013-03-07 at 07:48 -0500, Mark Bidewell wrote:
> Are there any records of these FUDCon discussions? Creating defined
> core of functionality seems like it could solve several problems. I
> would be curious as to what ideas we proposed on that.
I don't know for sure, but I'm not aware of
Le Jeu 7 mars 2013 17:27, Jan Zelený a écrit :
> Also, you still have to put this information into the old package somehow,
> i.e. rebuild it. If you don't do that, you will miss a piece of the
> timeline.
>
> Much easier to bump epoch or release IMO.
You may possibly work around this problem by
On 5. 3. 2013 at 18:50:45, Colin Walters wrote:
> On Tue, 2013-03-05 at 16:58 -0500, Bill Nottingham wrote:
> > We don't ship in a way that easily allows this though, now. Admittedly,
> > this is due to the sheer *amount* of stuff involved in just maintaining
> > single versions of things, and how
On Wed, 06 Mar 2013 21:07:45 -0800
Adam Williamson wrote:
> > Sure. Note however that we don't currently run autoqa on rawhide
> > builds and that was at least the initial target for this. ;)
>
> Um. I think we do? I see results from rpmguard (and other tests) for
> builds with 'fc19' in them a
On Wed, Mar 6, 2013 at 10:03 PM, Adam Williamson wrote:
> So just a couple of notes on the proposal:
>
> It's phrased in very technical terms here - probably a wise choice - but I
> think it's worth noting one of the angles we took in discussing it in
> person at FUDCon is that it has the potentia
On 06/03/13 09:00 PM, Kevin Fenzi wrote:
On Wed, 06 Mar 2013 18:31:06 -0800
Adam Williamson wrote:
We do already have an AutoQA test which runs rpmguard, and rpmguard
notes dependency/provision version changes. Here it is spotting an
ABI bump for binutils:
http://autoqa.fedoraproject.org/resu
On Wed, 06 Mar 2013 18:31:06 -0800
Adam Williamson wrote:
> We do already have an AutoQA test which runs rpmguard, and rpmguard
> notes dependency/provision version changes. Here it is spotting an
> ABI bump for binutils:
>
> http://autoqa.fedoraproject.org/results/531743-autotest/qa02.qa/rpmgu
On 04/03/13 10:18 AM, Miloslav Trmač wrote:
This is a proposal of changes to the way future Fedora cycles should
work and integrate changes.
So just a couple of notes on the proposal:
It's phrased in very technical terms here - probably a wise choice - but
I think it's worth noting one of the
On 06/03/13 04:40 AM, Jaroslav Reznik wrote:
- Original Message -
On Tue, 5 Mar 2013 03:48:29 -0500 (EST)
From tooling perspective - that's the question if we want to
enhance
our tools, step into other similar project (for collaboration with
our downstreams? other distros...).
yeah,
Colin Walters (walt...@verbum.org) said:
> On Tue, 2013-03-05 at 16:58 -0500, Bill Nottingham wrote:
>
> > We don't ship in a way that easily allows this though, now. Admittedly,
> > this is due to the sheer *amount* of stuff involved in just maintaining
> > single versions of things, and how muc
On Tue, Mar 5, 2013 at 11:30 PM, Kevin Kofler wrote:
> Miloslav Trmač wrote:
>> We also propose to build up automated tests to verify the tier 1 and
>> tier 2 functionality, and use those tests on newly-built packages to
>> gate inclusion in rawhide.
>
> Please no! Extending the already painful re
- Original Message -
> On Tue, 5 Mar 2013 03:48:29 -0500 (EST)
> > From tooling perspective - that's the question if we want to
> > enhance
> > our tools, step into other similar project (for collaboration with
> > our downstreams? other distros...).
>
> yeah, I don't know.
>
> Perhaps so
On 5 March 2013 17:52, Kevin Fenzi wrote:
> On Tue, 05 Mar 2013 12:44:39 -0500
> Stephen Gallagher wrote:
>> This is local testing that has been done in concert with the feature
>> to add enterprise login support to Anaconda/firstboot. There's
>> currently no way to actually install from Rawhide
On Mon, Mar 04, 2013 at 07:18:04PM +0100, Miloslav Trmač wrote:
> This is a proposal of changes to the way future Fedora cycles should
> work and integrate changes.
>
> Some of the things we want to achieve:
> * Make rawhide to be reliably installable and usable by developers by
> coherently intro
On Tue, 2013-03-05 at 16:58 -0500, Bill Nottingham wrote:
> We don't ship in a way that easily allows this though, now. Admittedly,
> this is due to the sheer *amount* of stuff involved in just maintaining
> single versions of things, and how much that would jump if we started
> having multiple ve
Miloslav Trmač wrote:
> We also propose to build up automated tests to verify the tier 1 and
> tier 2 functionality, and use those tests on newly-built packages to
> gate inclusion in rawhide.
Please no! Extending the already painful red tape we have in stable releases
to Rawhide will completely
Olav Vitters wrote:
> Mageia packages libraries by the .so major version. So you can upgrade a
> library and then work on rebuilding all the software.
>
> Example (library name is not too important):
> lib64spice-client-gtk3.0_1-0.9-1.mga2
> lib64spice-client-gtk3.0_4-0.15-3.mga3
This is a re
On Tue, 5 Mar 2013 16:58:49 -0500
Bill Nottingham wrote:
> seth vidal (skvi...@fedoraproject.org) said:
> > On Tue, 05 Mar 2013 13:28:58 -0500
> > Colin Walters wrote:
> >
> > > On Tue, 2013-03-05 at 13:17 -0500, seth vidal wrote:
> > >
> > > > If the issue was only 'newer is better' then rpm
seth vidal (skvi...@fedoraproject.org) said:
> On Tue, 05 Mar 2013 13:28:58 -0500
> Colin Walters wrote:
>
> > On Tue, 2013-03-05 at 13:17 -0500, seth vidal wrote:
> >
> > > If the issue was only 'newer is better' then rpm can easily get
> > > around it. Hell, so can yum, now.
> >
> > But koji
Le Mar 5 mars 2013 19:28, Colin Walters a écrit :
> True, but the biggest problems are things like new versions of colord
> that trip up a selinux-policy denial which then in turn cause
> gnome-settings-daemon to crash which in turn gives you a failure at GDM.
Given how fast our selinux people r
On Tue, Mar 5, 2013 at 1:57 PM, Przemek Klosowski
wrote:
> On 03/05/2013 01:28 PM, Colin Walters wrote:
>>
>> On Tue, 2013-03-05 at 13:17 -0500, seth vidal wrote:
>>
>>> If the issue was only 'newer is better' then rpm can easily get around
>>> it. Hell, so can yum, now.
>
> ...
>
>>> So - I don't
On 03/05/2013 01:28 PM, Colin Walters wrote:
On Tue, 2013-03-05 at 13:17 -0500, seth vidal wrote:
If the issue was only 'newer is better' then rpm can easily get around
it. Hell, so can yum, now.
...
So - I don't see how adding another layer is really a problem - since
the 'infinite versions
On Tue, 05 Mar 2013 13:28:58 -0500
Colin Walters wrote:
> On Tue, 2013-03-05 at 13:17 -0500, seth vidal wrote:
>
> > If the issue was only 'newer is better' then rpm can easily get
> > around it. Hell, so can yum, now.
>
> But koji, createrepo and such can't, right?
createrepo is version agno
On Tue, 2013-03-05 at 13:17 -0500, seth vidal wrote:
> If the issue was only 'newer is better' then rpm can easily get around
> it. Hell, so can yum, now.
But koji, createrepo and such can't, right?
> The issue is that we have nothing that even resembles a backward-compat
> process for user DATA
On Tue, 05 Mar 2013 13:07:59 -0500
Colin Walters wrote:
> On Tue, 2013-03-05 at 12:44 -0500, Stephen Gallagher wrote:
>
> > Well, in that case I suppose we'd need to add a new tag-set,
> > something like rawhide-pending
>
> In other words, another layer.
>
> I'll only repeat this maybe every
On Tue, 2013-03-05 at 12:44 -0500, Stephen Gallagher wrote:
> Well, in that case I suppose we'd need to add a new tag-set, something
> like rawhide-pending
In other words, another layer.
I'll only repeat this maybe every 6 months or yearly, depending on how
annoying people find me. But basical
On Tue, 05 Mar 2013 12:44:39 -0500
Stephen Gallagher wrote:
> Well, in that case I suppose we'd need to add a new tag-set, something
> like rawhide-pending and run the tests over the combination rawhide
> and rawhide-pending tags. If they started failing, don't move the
> rawhide-pending tag to r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue 05 Mar 2013 12:25:04 PM EST, Kevin Fenzi wrote:
> On Tue, 05 Mar 2013 12:10:58 -0500 Stephen Gallagher
> wrote:
>
>> Our original thoughts on this were that we would tie this to the
>> bodhi/repocreate phase of things. Basically, before each
On Tue, 05 Mar 2013 12:10:58 -0500
Stephen Gallagher wrote:
> Our original thoughts on this were that we would tie this to the
> bodhi/repocreate phase of things. Basically, before each automatic
> repocreate run in Rawhide, we would run the set of tier 1 and tier 2
> acceptance tests. If any of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/05/2013 11:47 AM, Kevin Fenzi wrote:
> On Tue, 5 Mar 2013 03:48:29 -0500 (EST) Jaroslav Reznik
> wrote:
>
>> The idea is autoqa (but those test run as part of package build
>> could be part of it too). Yes, it means it will take a time to
>> ha
On Tue, 5 Mar 2013 03:48:29 -0500 (EST)
Jaroslav Reznik wrote:
> The idea is autoqa (but those test run as part of package build could
> be part of it too). Yes, it means it will take a time to have a good
> set of tests and with autoqa support it's main problem I see but...
So, say I do the fol
- Original Message -
> On Mon, Mar 04, 2013 at 07:18:04PM +0100, Miloslav Trmač wrote:
> > Some of the things we want to achieve:
> > * Make rawhide to be reliably installable and usable by developers
> > by
> > coherently introducing changes.
>
> Another factor is that on Fedora, it seem
On Mon, Mar 04, 2013 at 07:18:04PM +0100, Miloslav Trmač wrote:
> Some of the things we want to achieve:
> * Make rawhide to be reliably installable and usable by developers by
> coherently introducing changes.
Mageia packages libraries by the .so major version. So you can upgrade a
library and th
- Original Message -
> On Mon, 4 Mar 2013 20:35:08 +0100
> Miloslav Trmač wrote:
> > On Mon, Mar 4, 2013 at 7:50 PM, Josh Boyer
> > wrote:
>
> ...snip...
>
> > >> Finally, the planning process will recognize the existence of
> > >> these
> > >> tiers by classifying each proposed change:
On Mon, 4 Mar 2013 20:35:08 +0100
Miloslav Trmač wrote:
> On Mon, Mar 4, 2013 at 7:50 PM, Josh Boyer wrote:
...snip...
> >> Finally, the planning process will recognize the existence of these
> >> tiers by classifying each proposed change:
> >>
> >> * Changes to tiers 1 and 2:
> >> Strong r
On Mon, Mar 04, 2013 at 08:35:08PM +0100, Miloslav Trmač wrote:
> On Mon, Mar 4, 2013 at 7:50 PM, Josh Boyer wrote:
> >> 1: Long-term ABI for applications that we don't want to break without
> >> significant discussion.
> >> For now, this will include the stable kernel and libc ABIs
> >
On Mon, Mar 4, 2013 at 7:50 PM, Josh Boyer wrote:
>> 1: Long-term ABI for applications that we don't want to break without
>> significant discussion.
>> For now, this will include the stable kernel and libc ABIs
>
> Please define what you mean by "stable kernel ABI". Do you mean the
> kernel
On Mon, Mar 4, 2013 at 1:18 PM, Miloslav Trmač wrote:
> This is a proposal of changes to the way future Fedora cycles should
> work and integrate changes.
>
> Some of the things we want to achieve:
> * Make rawhide to be reliably installable and usable by developers by
> coherently introducing cha
53 matches
Mail list logo
