12:18 p.m.
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 changes.
* Define the interfaces that applications can rely on (and by
inference, the ones that they can't).
* Ensure that functionality implemented in Fedora doesn't
unintentionally regress, and provide a clear way to change or replace
earlier implementations.
To do this, we propose to specify three levels of stability we
attempt. These are defined at the level of interfaces (e.g. specific
library/command/file), not at the level of packages:
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
2: "Base design": A set of functionality that was implemented and
needs to be kept working in any composed tree, including rawhide; may
include specific commands.
Behavior that other parts of the distribution depends on.
Functionality accepted for this tier by FESCo using the planning
process, and some interfaces this functionality relies on.
3: "Internal API": we'll do our best not to change it within a release
lifetime; basically the existing Fedora compatibility and update
rules.
e.g. Python/Perl/Ruby X.Y version, most library interfaces, and
major aspects of UI.
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.
Finally, the planning process will recognize the existence of these
tiers by classifying each proposed change:
* Changes to tiers 1 and 2:
Strong recommendation that new stable APIs have new tests
delivered at approximately the same time, if possible. This benefits
change owners by diminishing the risk of accidental breakage of the
functionality. Existing tests for the functionality must be updated at
the same time as well.
Waivers may be requested of FESCo.
* Complex changes not affecting tiers 1/2 (e.g., new core library version):
Strong recommendation that landing of these be coordinated, via
the use of side tags or similar features.
* Self-contained changes (mostly announcement-only) (e.g. user-visible
changes to applications)
The original idea for this proposal was discussed at length during
FUDCon Lawrence by the following individuals:
Stephen Gallagher
Jon Stanley
Miloslav Trmač
Adam Williamson
Bill Nottingham
Jaroslav Reznik
Jesse Keating
Paul Frields
Emily Dirsh
Justin M. Forbes
Peter Jones
Toshio Kuratomi
Additionally, further discussion took place at the Brno Developer
Conference between:
Bill Nottingham
Marcela Mašláňová
Miloslav Trmač
Stephen Gallagher
Tomáš Mráz
12:50 p.m.
On Mon, Mar 4, 2013 at 1:18 PM, Miloslav Trmač <mitr(a)volny.cz> 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 changes.
* Define the interfaces that applications can rely on (and by
inference, the ones that they can't).
* Ensure that functionality implemented in Fedora doesn't
unintentionally regress, and provide a clear way to change or replace
earlier implementations.
To do this, we propose to specify three levels of stability we
attempt. These are defined at the level of interfaces (e.g. specific
library/command/file), not at the level of packages:
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 <-> userspace syscall ABI? If you mean anything other than that
I really don't think it's going to work. There is no internal stable
kernel ABI and upstream is very against having one.
Put another way: There is no way Fedora is doing anything like kABI.
2: "Base design": A set of functionality that was
implemented and
needs to be kept working in any composed tree, including rawhide; may
include specific commands.
Behavior that other parts of the distribution depends on.
Functionality accepted for this tier by FESCo using the planning
process, and some interfaces this functionality relies on.
Isn't this basically just critpath? Why is it being called something
new? Or if it isn't just critpath, can you explain how it is different?
3: "Internal API": we'll do our best not to change it
within a release
lifetime; basically the existing Fedora compatibility and update
rules.
e.g. Python/Perl/Ruby X.Y version, most library interfaces, and
major aspects of UI.
Just to be clear, when you stay "within a release" you mean after it
is actually released? Or do you mean after it's branched? Clearly not
rawhide or we'd never update anything, but at what point is this in
effect?
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.
Finally, the planning process will recognize the existence of these
tiers by classifying each proposed change:
* Changes to tiers 1 and 2:
Strong recommendation that new stable APIs have new tests
delivered at approximately the same time, if possible. This benefits
change owners by diminishing the risk of accidental breakage of the
functionality. Existing tests for the functionality must be updated at
the same time as well.
Waivers may be requested of FESCo.
Are you envisioning the package maintainers to have to write these tests
if they don't exist upstream?
* Complex changes not affecting tiers 1/2 (e.g., new core library
version):
Strong recommendation that landing of these be coordinated, via
the use of side tags or similar features.
We already encourage this today, correct? So this is just a
formalization of that.
josh
1:35 p.m.
On Mon, Mar 4, 2013 at 7:50 PM, Josh Boyer <jwboyer(a)gmail.com> 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 <-> userspace syscall ABI? If you mean anything other than that
I really don't think it's going to work.
This means "whatever the Linux kernel project says is their stable
ABI". It was not at all intended to expand the ABI boundary.
> 2: "Base design": A set of functionality that was
implemented and
> needs to be kept working in any composed tree, including rawhide; may
> include specific commands.
> Behavior that other parts of the distribution depends on.
> Functionality accepted for this tier by FESCo using the planning
> process, and some interfaces this functionality relies on.
Isn't this basically just critpath? Why is it being called something
new? Or if it isn't just critpath, can you explain how it is different?
* Critical path is a set of packages; this is a set of functionality/interfaces.
* Tier 2 may include both both user-visible aspects and programming interfaces.
* Tiers 1 and 2 are expected to be kept working (as primarily verified
by the tests) even in rawhide.
* Changes to tiers 1 and 2 are required to go through the planning process.
A few possible examples of how this could work (without necessarily
claiming that all of these things should be in tier 2, that's up to
maintainers and FESCo):
* /bin/bash is an important part of the CLI, and any package build
that breaks it would not be accepted into rawhide (modulo possible
temporary waivers for merging a change). OTOH broken
/usr/bin/bashbug, missing info documentation, or other less important
aspects of the package would not prevent rawhide inclusion.
* The polkit D-Bus API is an important cross-package interface, and
any package build that breaks applications using it would not be
accepted into rawhide.
* Since F18 we have
https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop , and
any update that reverts that would not be accepted into rawhide.
NOTE: In all of these cases, the situation is NOT set in stone -
incompatible changes to the functionality in tier 2 can happen, can
even happen in every Fedora release. The only hard requirements are
that the change must go through the Planning process and be acked by
FESCo, and that existing tests must be updated.
> 3: "Internal API": we'll do our best not to change
it within a release
> lifetime; basically the existing Fedora compatibility and update
> rules.
> e.g. Python/Perl/Ruby X.Y version, most library interfaces, and
> major aspects of UI.
Just to be clear, when you stay "within a release" you mean after it
is actually released? Or do you mean after it's branched? Clearly not
rawhide or we'd never update anything, but at what point is this in
effect?
"Basically the existing Fedora compatibility and update rules":
http://fedoraproject.org/wiki/Updates_Policy
> Finally, the planning process will recognize the existence of
these
> tiers by classifying each proposed change:
>
> * Changes to tiers 1 and 2:
> Strong recommendation that new stable APIs have new tests
> delivered at approximately the same time, if possible. This benefits
> change owners by diminishing the risk of accidental breakage of the
> functionality. Existing tests for the functionality must be updated at
> the same time as well.
> Waivers may be requested of FESCo.
Are you envisioning the package maintainers to have to write these tests
if they don't exist upstream?
Yes.
My personal opinion:
* For UI and APIs, we want the things included in tier 2 to be
sufficiently stable/tested, which probably means they should already
have an upstream test suite; if they don't, and Fedora decides that
they
are important, Fedora should contribute an upstream test suite.
* I expect that many "change" owners will find it worth their time to
write a test - e.g. in the above example of Avahi it's one-time cost
of writing a fairly simple test that will save manual checking and
worry for the future.
> * Complex changes not affecting tiers 1/2 (e.g., new core library
version):
> Strong recommendation that landing of these be coordinated, via
> the use of side tags or similar features.
We already encourage this today, correct? So this is just a
formalization of that.
Yes, this has even been accepted by FESCo (last sentence of
https://fedoraproject.org/wiki/User:Mmaslano/Feature_process , in
https://fedorahosted.org/fesco/ticket/896). So this is just a matter
of making it possible/easy, and making it actually happen.
Mirek
1:56 p.m.
On Mon, Mar 04, 2013 at 08:35:08PM +0100, Miloslav Trmač wrote:
On Mon, Mar 4, 2013 at 7:50 PM, Josh Boyer <jwboyer(a)gmail.com>
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 <-> userspace syscall ABI? If you mean anything other than that
> I really don't think it's going to work.
This means "whatever the Linux kernel project says is their stable
ABI". It was not at all intended to expand the ABI boundary.
The only really guaranteed stable ABI the kernel exports is the syscall/ioctl
interface, and to a lesser extent the proc/sysfs ABI.
Kernels in rawhide do differ from what we end up shipping in releases,
because they are continually rebased during the merge window/rc phase,
wherein it's entirely possible that a new interface is refined.
We've had situations for example where a new syscall added during the merge window
has had additional parameters added/existing ones changed during -rc phase.
This hasn't been a problem because typically, nothing relies upon an interface in
unreleased kernels, but we need to make it clear here that nothing in new interfaces
is frozen until a .0 release, in case people start thinking "you shipped it in
rawhide,
so it must be stable".
Dave
10:37 p.m.
On Mon, 4 Mar 2013 20:35:08 +0100
Miloslav Trmač <mitr(a)volny.cz> wrote:
On Mon, Mar 4, 2013 at 7:50 PM, Josh Boyer <jwboyer(a)gmail.com>
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 recommendation that new stable APIs have new tests
>> delivered at approximately the same time, if possible. This
>> benefits change owners by diminishing the risk of accidental
>> breakage of the functionality. Existing tests for the
>> functionality must be updated at the same time as well.
>> Waivers may be requested of FESCo.
>
> Are you envisioning the package maintainers to have to write these
> tests if they don't exist upstream?
Yes.
Are these tests that run as part of package build?
Or are we talking something like autoqa tests? Or ?
My personal opinion:
* For UI and APIs, we want the things included in tier 2 to be
sufficiently stable/tested, which probably means they should already
have an upstream test suite; if they don't, and Fedora decides that
they
are important, Fedora should contribute an upstream test suite.
* I expect that many "change" owners will find it worth their time to
write a test - e.g. in the above example of Avahi it's one-time cost
of writing a fairly simple test that will save manual checking and
worry for the future.
How is this gating to rawhide going to work?
Or that's yet to be determined?
While I like the idea overall, I think the devil will be in the details
here. :) If we make the tests too strict, we are going to slow things
down, if we make them too manual we push more work on rel-eng, if we
don't make them strict enough, we have what we have today, but with
more red tape.
kevin
2:48 a.m.
----- Original Message -----
On Mon, 4 Mar 2013 20:35:08 +0100
Miloslav Trmač <mitr(a)volny.cz> wrote:
> On Mon, Mar 4, 2013 at 7:50 PM, Josh Boyer <jwboyer(a)gmail.com>
> 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 recommendation that new stable APIs have new tests
> >> delivered at approximately the same time, if possible. This
> >> benefits change owners by diminishing the risk of accidental
> >> breakage of the functionality. Existing tests for the
> >> functionality must be updated at the same time as well.
> >> Waivers may be requested of FESCo.
> >
> > Are you envisioning the package maintainers to have to write
> > these
> > tests if they don't exist upstream?
>
> Yes.
Are these tests that run as part of package build?
Or are we talking something like autoqa tests? Or ?
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...
> My personal opinion:
>
> * For UI and APIs, we want the things included in tier 2 to be
> sufficiently stable/tested, which probably means they should
> already
> have an upstream test suite; if they don't, and Fedora decides that
> they
> are important, Fedora should contribute an upstream test suite.
>
> * I expect that many "change" owners will find it worth their time
> to
> write a test - e.g. in the above example of Avahi it's one-time
> cost
> of writing a fairly simple test that will save manual checking and
> worry for the future.
How is this gating to rawhide going to work?
Or that's yet to be determined?
While I like the idea overall, I think the devil will be in the
details
here. :) If we make the tests too strict, we are going to slow things
down, if we make them too manual we push more work on rel-eng, if we
don't make them strict enough, we have what we have today, but with
more red tape.
Yep, it's really about the detail - that's why we have this thread.
In the beginning it can definitely cause slow downs...
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...).
Jaroslav
kevin
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
10:47 a.m.
On Tue, 5 Mar 2013 03:48:29 -0500 (EST)
Jaroslav Reznik <jreznik(a)redhat.com> 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 following:
- announce a week in advance that libfoo is going to break abi.
- mail all the affected package maintainers that I will rebuild their
packages.
- test rebuilding locally and fix things.
- push new libfoo to build against it in rawhide.
Then the new check says "Sorry, there's an ABI bump, fail"
How am I going to be able to tell it, 'yes, I know, but do it anyhow'
Then, when we answer that, whats to prevent people from just doing that
without doing all the proper steps. ;)
I suppose one way would be to have the checker be the thing that
actually tags the package into f19 (or whatever). If it fails a test it
doesn't move it over, but a koji admin could manually tag something in.
That would lead to more work for releng tho.
We could leave the tag open (as it is now) and anyone could override
and tag into f19, but then it's open for some abuse as someone might
just do that when they shouldn't.
For released versions we could tie this check into bodhi I suppose.
Have it require a 'pass' from some set of tests before being allowed to
go out as an update.
...snip...
Yep, it's really about the detail - that's why we have this
thread.
In the beginning it can definitely cause slow downs...
Sure.
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 someone could ask around and see if there's any projects/setups
inside Red Hat that would be good for this? ABI checking and perhaps
rpm diffing?
Also, do any of the folks working on AutoQA think it could be used for
this? Or would they suggest a different framework?
I think we should definitely start small here and slowly work forward.
The hardest part will be getting the initial tooling in place.
(All this is assuming that this is a good idea that people want I
guess). ;)
kevin
11:10 a.m.
-----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
<jreznik(a)redhat.com> 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 following:
- announce a week in advance that libfoo is going to break abi. -
mail all the affected package maintainers that I will rebuild
their packages. - test rebuilding locally and fix things. - push
new libfoo to build against it in rawhide.
Then the new check says "Sorry, there's an ABI bump, fail"
How am I going to be able to tell it, 'yes, I know, but do it
anyhow'
Then, when we answer that, whats to prevent people from just doing
that without doing all the proper steps. ;)
I suppose one way would be to have the checker be the thing that
actually tags the package into f19 (or whatever). If it fails a
test it doesn't move it over, but a koji admin could manually tag
something in. That would lead to more work for releng tho.
We could leave the tag open (as it is now) and anyone could
override and tag into f19, but then it's open for some abuse as
someone might just do that when they shouldn't.
For released versions we could tie this check into bodhi I suppose.
Have it require a 'pass' from some set of tests before being
allowed to go out as an update.
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 them failed, we would send out emails to
the owners of any package that would have been pushed to the repo and
not push any of them.
Yes, it would be a manual step to update the tests to allow the push
to go through. I'm not going to deny the possibility that some people
might opt to bypass the process and just update the tests as they go.
We would prefer they did not (and if someone gets caught doing this
repeatedly, there are steps that can be taken), but it helps us to
avoid *unintentional* breakage, which is the hallmark of Rawhide at
this point.
It's worth noting that right now we are less than a week from Alpha
freeze for Fedora 19, and yet Rawhide is not installable. This is what
we would like to avoid.
...snip...
> Yep, it's really about the detail - that's why we have this
> thread. In the beginning it can definitely cause slow downs...
Sure.
> 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 someone could ask around and see if there's any
projects/setups inside Red Hat that would be good for this? ABI
checking and perhaps rpm diffing?
Also, do any of the folks working on AutoQA think it could be used
for this? Or would they suggest a different framework?
When we drafted the proposal, our expectation was that AutoQA would be
a good fit here, mostly due to its current positioning within the
updates system. We reasoned that it would be a fit place to make the
gating decisions. If this proposal sees sufficient support and
approval, we will petition Red Hat for dedicated resources on AutoQA
(or whatever framework we settle on). We believe that an installable
Rawhide and more stable development platform is in the best interests
of Red Hat as well (Note: I am not speaking in an official capacity as
a Red Hat employee here; this is my view as a member of both communities).
I think we should definitely start small here and slowly work
forward.
The hardest part will be getting the initial tooling in place.
(All this is assuming that this is a good idea that people want I
guess). ;)
kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlE2JyIACgkQeiVVYja6o6Or6ACeIl6kaHJoJTiRICQxInja39Af
YeoAnjvfovFRvUg8ZnY10NRiOSDTGTtg
=+G30
-----END PGP SIGNATURE-----
11:25 a.m.
On Tue, 05 Mar 2013 12:10:58 -0500
Stephen Gallagher <sgallagh(a)redhat.com> 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 them failed, we would send out emails to
the owners of any package that would have been pushed to the repo and
not push any of them.
I don't think koji has any sense of 'new packages' there.
newRepo tasks just run over all the packages in a tag and make the
repos. They don't know what package(s) change. :(
Yes, it would be a manual step to update the tests to allow the push
to go through. I'm not going to deny the possibility that some people
might opt to bypass the process and just update the tests as they go.
We would prefer they did not (and if someone gets caught doing this
repeatedly, there are steps that can be taken), but it helps us to
avoid *unintentional* breakage, which is the hallmark of Rawhide at
this point.
Sure.
It's worth noting that right now we are less than a week from
Alpha
freeze for Fedora 19, and yet Rawhide is not installable. This is what
we would like to avoid.
Oh? How would we know? We don't make rawhide install images anymore...
Or this is some local testing you have done?
When we drafted the proposal, our expectation was that AutoQA would
be
a good fit here, mostly due to its current positioning within the
updates system. We reasoned that it would be a fit place to make the
gating decisions. If this proposal sees sufficient support and
approval, we will petition Red Hat for dedicated resources on AutoQA
(or whatever framework we settle on). We believe that an installable
Rawhide and more stable development platform is in the best interests
of Red Hat as well (Note: I am not speaking in an official capacity as
a Red Hat employee here; this is my view as a member of both
communities).
Well, bodhi is not used for rawhide in any way currently... so, not
sure how we can properly fit autoqa in there. :(
kevin
11:44 a.m.
-----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
<sgallagh(a)redhat.com> 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 them failed, we would
> send out emails to the owners of any package that would have been
> pushed to the repo and not push any of them.
I don't think koji has any sense of 'new packages' there. newRepo
tasks just run over all the packages in a tag and make the repos.
They don't know what package(s) change. :(
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 rawhide.
I'm not going to pretend at the moment that I know the perfect
technical solution to accomplish this at the moment.
> Yes, it would be a manual step to update the tests to allow the
> push to go through. I'm not going to deny the possibility that
> some people might opt to bypass the process and just update the
> tests as they go. We would prefer they did not (and if someone
> gets caught doing this repeatedly, there are steps that can be
> taken), but it helps us to avoid *unintentional* breakage, which
> is the hallmark of Rawhide at this point.
Sure.
> It's worth noting that right now we are less than a week from
> Alpha freeze for Fedora 19, and yet Rawhide is not installable.
> This is what we would like to avoid.
Oh? How would we know? We don't make rawhide install images
anymore...
Or this is some local testing you have done?
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 cleanly in order to
do that testing.
> When we drafted the proposal, our expectation was that AutoQA
> would be a good fit here, mostly due to its current positioning
> within the updates system. We reasoned that it would be a fit
> place to make the gating decisions. If this proposal sees
> sufficient support and approval, we will petition Red Hat for
> dedicated resources on AutoQA (or whatever framework we settle
> on). We believe that an installable Rawhide and more stable
> development platform is in the best interests of Red Hat as well
> (Note: I am not speaking in an official capacity as a Red Hat
> employee here; this is my view as a member of both communities).
Well, bodhi is not used for rawhide in any way currently... so,
not sure how we can properly fit autoqa in there. :(
Hmm, I suppose I thought Bodhi was involved quietly. If it's not, then
you may be right and we should look into other integration points.
I suppose the biggest question that needs answering in this thread is
this: Is this a goal that the Fedora community as a whole sees as
worth investing time and effort into? Obviously, my view is "yes". I
think that if we can make Rawhide more consumable, we'll have a place
where we can reasonably expect people to do development (as opposed to
the current model where people are mainly using Rawhide as a place to
either throw untested upstream packages or else do last-minute
integration right before a freeze).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlE2LwcACgkQeiVVYja6o6MJSQCcCOGPPqz3SIpypxUJ5JPd/av2
WaMAniSF0nw34Pr2+EthDjhtVYYYDH4i
=Alu0
-----END PGP SIGNATURE-----
11:52 a.m.
On Tue, 05 Mar 2013 12:44:39 -0500
Stephen Gallagher <sgallagh(a)redhat.com> 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 rawhide.
Yeah. Ie, a official build tags your build into f19-pending, tests are
run on it, if they pass it tags over to f19.
I'm not going to pretend at the moment that I know the perfect
technical solution to accomplish this at the moment.
Sure. Just brainstorming here for others to also jump in with ideas.
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 cleanly in order to
do that testing.
Bummer. ;(
There was a plan to do weekly install composes, but it was blocked by
mock in rawhide being broken for a while. I am not sure what the hold
up is now.
Hmm, I suppose I thought Bodhi was involved quietly. If it's not,
then
you may be right and we should look into other integration points.
Yeah, it's not. The rawhide and released/branched versions will have to
handle this slightly differently I suspect. Or perhaps we can use
whatever we come up with for rawhide for others as well and just have
it be before bodhi in the process.
I suppose the biggest question that needs answering in this thread
is
this: Is this a goal that the Fedora community as a whole sees as
worth investing time and effort into? Obviously, my view is "yes". I
think that if we can make Rawhide more consumable, we'll have a place
where we can reasonably expect people to do development (as opposed to
the current model where people are mainly using Rawhide as a place to
either throw untested upstream packages or else do last-minute
integration right before a freeze).
Yep.
I think its a worthwhile goal. I'd like to avoid slowing down rawhide
or adding too much red tape, but I think catching inadvertent breakage
should be welcomed by everyone.
kevin
4:55 a.m.
On 5 March 2013 17:52, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Tue, 05 Mar 2013 12:44:39 -0500
Stephen Gallagher <sgallagh(a)redhat.com> 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 cleanly in order to
> do that testing.
Bummer. ;(
There was a plan to do weekly install composes, but it was blocked by
mock in rawhide being broken for a while. I am not sure what the hold
up is now.
Just to follow this up, F19 composes are occurring (I've just tried to
check the latest on koji, but it seems to be busy). It seems Anaconda
is broken in them, Brian Monroe reported this trying out the latest
Fedora Jam compose on the music list:
I'm getting this traceback on the most recent nightly iso when I try
to install to Hard Drive.
File "/sbin/anaconda", line 719, in <module>
from pyanaconda import kickstart
File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py",
line 760, in <module>
class Network(commands.network.F19_Network):
AttributeError: 'module' object has no attribute 'F19_Network
--
imalone
http://ibmalone.blogspot.co.uk
12:07 p.m.
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 basically, the #1 problem is the inability
of RPM to go backwards (i.e. versions must always go up).
It's like a car with no brakes and no reverse gear, driving down a road
that's being dynamically built in front of it.
A lot of times, the correct response to "stuff just broke!" is
"revert".
Not just revert - revert *quickly*. Don't let the master tree be broken.
Don't go off a cliff just because someone put a wrong sign
on the road.
For example, let's say a new version of Mesa breaks GNOME with llvmpipe.
One really can't fault the Mesa maintainers, because it's quite possible
they tested it, just on the Intel or AMD hardware on their laptop.
But the correct response here is still to revert to the previous Mesa
until the problem is found and fixed.
If instead what we have is another "layer"/"repo" or state of
packages,
this issue would end up blocking progress on *everything else* into
rawhide until it was fixed, because the AutoQA tests would just keep
failing. That's very problematic.
(This is assuming the AutoQA tests are something interesting and useful
like booting GNOME, and not spelling checks for the spec file
descriptions or something)
But given the drastic changes to RPM (and all the software built on top
of it like mock, koji, createrepo, etc.), that would be required to fix
this "newer is always better" problem, I can't fault you for saying we
should add another layer.
12:17 p.m.
On Tue, 05 Mar 2013 13:07:59 -0500
Colin Walters <walters(a)verbum.org> 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 6 months or yearly, depending on how
annoying people find me. But basically, the #1 problem is the
inability of RPM to go backwards (i.e. versions must always go up).
It's like a car with no brakes and no reverse gear, driving down a
road that's being dynamically built in front of it.
A lot of times, the correct response to "stuff just broke!" is
"revert". Not just revert - revert *quickly*. Don't let the master
tree be broken. Don't go off a cliff just because someone put a wrong
sign on the road.
For example, let's say a new version of Mesa breaks GNOME with
llvmpipe. One really can't fault the Mesa maintainers, because it's
quite possible they tested it, just on the Intel or AMD hardware on
their laptop.
But the correct response here is still to revert to the previous Mesa
until the problem is found and fixed.
If instead what we have is another "layer"/"repo" or state of
packages, this issue would end up blocking progress on *everything
else* into rawhide until it was fixed, because the AutoQA tests would
just keep failing. That's very problematic.
(This is assuming the AutoQA tests are something interesting and
useful like booting GNOME, and not spelling checks for the spec file
descriptions or something)
But given the drastic changes to RPM (and all the software built on
top of it like mock, koji, createrepo, etc.), that would be required
to fix this "newer is always better" problem, I can't fault you for
saying we should add another layer.
If the issue was only 'newer is better' then rpm can easily get around
it. Hell, so can yum, now.
The issue is that we have nothing that even resembles a backward-compat
process for user DATA.
I can roll back package binaries all day long, but if there is a
db or config format which has moved on - and been modified -the user is
screwed.
For fun - try to run a desktop of f16 and f18 using a shared homedir
sometime.
So - I don't see how adding another layer is really a problem - since
the 'infinite versions in every direction' won't help our users losing
their configs or worse their data.
am I missing something here? Have we solved the user data problem?
-sv
12:28 p.m.
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.
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.
None of that involves user data.
For fun - try to run a desktop of f16 and f18 using a shared homedir
sometime.
At least in GNOME we used to have a strong policy of enabling this, but
admittedly a lot of core applications do it wrong.
So - I don't see how adding another layer is really a problem -
since
the 'infinite versions in every direction' won't help our users losing
their configs or worse their data.
am I missing something here?
Yes - that we don't need to solve the user data problem for all software
immediately to support rolling back a Mesa upgrade.
12:39 p.m.
On Tue, 05 Mar 2013 13:28:58 -0500
Colin Walters <walters(a)verbum.org> 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 agnostic. It cares not at all.
koji can build whatever, too.. I'm not sure how those are related here.
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.
None of that involves user data.
gdm does change your user settings when you login, though. For desktop
environment selection (or at least it used to)
> So - I don't see how adding another layer is really a problem -
> since the 'infinite versions in every direction' won't help our
> users losing their configs or worse their data.
>
> am I missing something here?
Yes - that we don't need to solve the user data problem for all
software immediately to support rolling back a Mesa upgrade.
I'm not sure how much software you're actually talking about here that
doesn't end up touching the user somewhere.
-sv
3:58 p.m.
seth vidal (skvidal(a)fedoraproject.org) said:
On Tue, 05 Mar 2013 13:28:58 -0500
Colin Walters <walters(a)verbum.org> 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 agnostic. It cares not at all.
koji can build whatever, too.. I'm not sure how those are related here.
Well, on the koji side there are build concerns, but that's somewhat
separate from giving users something they can stay on stably.
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 versions available all the time. That being said,
as long as we're willing to take the hit in disk space & repodata size,
and we're willing to nuke deltas from orbit (they won't scale to this,
sorry), we could certainly support having multiple versions of everything
available for easier rollback.
Bill
4:06 p.m.
On Tue, 5 Mar 2013 16:58:49 -0500
Bill Nottingham <notting(a)redhat.com> wrote:
seth vidal (skvidal(a)fedoraproject.org) said:
> On Tue, 05 Mar 2013 13:28:58 -0500
> Colin Walters <walters(a)verbum.org> 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 agnostic. It cares not at all.
>
> koji can build whatever, too.. I'm not sure how those are related
> here.
Well, on the koji side there are build concerns, but that's somewhat
separate from giving users something they can stay on stably.
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 versions available all the time.
That being said, as long as we're willing to take the hit in disk
space & repodata size, and we're willing to nuke deltas from orbit
(they won't scale to this, sorry), we could certainly support having
multiple versions of everything available for easier rollback.
Bill
Bill,
provided the above is not an unfunded mandate - then yes - I think
you're right. I don't think we could do it w/o money.
-sv
5:50 p.m.
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 versions available all the time.
To be clear, I am not suggesting multiple versions. The suggestion is
that the old version of mesa overrides the new version and the tests
(and users) get it.
Pretend like we bumped the Epoch.
In this model where version numbers are merely descriptive, other things
would have to change to use the "build serial" and not the ENVR, since
the ENVR is now merely descriptive.
For example, from systemd.spec:
Obsoletes: upstart < 1.2-7
The 1.2-7 is an ENVR, obviously. But if you think about it, the
relationship of systemd and upstart here has *nothing* to do with the
upstream version of 1.2, nor the fact that it was the 7th build.
That 1.2-7 is capturing a *point in time* in Fedora (the combination of
packages of systemd and upstart), and a point in time is exactly what a
build serial is.
4:15 p.m.
Colin Walters (walters(a)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 much that would jump if we started
> having multiple versions available all the time.
To be clear, I am not suggesting multiple versions. The suggestion is
that the old version of mesa overrides the new version and the tests
(and users) get it.
Pretend like we bumped the Epoch.
That requires more tooling changes, of course. (Or really dirty tricks
in the repodata).
Bill
3:36 p.m.
On Wed, Mar 6, 2013 at 11:15 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Colin Walters (walters(a)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 much that would jump if we started
> > having multiple versions available all the time.
>
> To be clear, I am not suggesting multiple versions. The suggestion is
> that the old version of mesa overrides the new version and the tests
> (and users) get it.
>
> Pretend like we bumped the Epoch.
That requires more tooling changes, of course. (Or really dirty tricks
in the repodata).
Or we could just use epoch ... yes I know it is "ugly" etc etc but ...
10:27 a.m.
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 much that would jump if we started
> having multiple versions available all the time.
To be clear, I am not suggesting multiple versions. The suggestion is
that the old version of mesa overrides the new version and the tests
(and users) get it.
I think what Bill meant was to keep older versions of package in repos, as
Debian distros do. It's not necessary to keep them locally. Having multiple
versions in repos would solve the issue, as you would always have the option
to install any of the older ones.
However your proposal for old version explicitly overriding new version isn't
just a problem of tooling. It's a problem of understanding the entire package
release timeline. If you want an old package to override the new package, you
will of course need to somehow specify that the new version of the package
obsoletes all the old ones except the "reversion" while the new-new version
obsoletes all of them, including the reversion. Diificult to comprehend? Now
imagine implementing and actually using it as maintainer ;-)
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.
In this model where version numbers are merely descriptive, other
things
would have to change to use the "build serial" and not the ENVR, since
the ENVR is now merely descriptive.
For example, from systemd.spec:
Obsoletes: upstart < 1.2-7
The 1.2-7 is an ENVR, obviously. But if you think about it, the
relationship of systemd and upstart here has *nothing* to do with the
upstream version of 1.2, nor the fact that it was the 7th build.
That 1.2-7 is capturing a *point in time* in Fedora (the combination of
packages of systemd and upstart), and a point in time is exactly what a
build serial is.
Let's consider that EVR is an abstraction of point in time. Version marks
point in time for upstream, release marks point in time for Fedora release. In
that case all you need to do is update the "point in time" to more recent
value, i.e. bump the release, right? I don't see anything complicated here,
that's what release numbers are for.
Thanks
Jan
1:40 p.m.
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 keeping old builds for some
time and adding a way to temporary override timeline at the repo metadata
level (not at the package level).
I suspect this could work at a small scale, but would wreak havoc in dep
resolution if used more than a couple of days on packages with deep
descendant trees. Even with --skip-broken yum is not able to resolve all
conflicts in koji repos now, without adding such possibilities to the mix.
And that is assuming all the administrative details (who sets the
overrides, when, with what tools, how to deal with conflicting requests)
could be worked out sanely.
While seductive the idea seems about as safe as attempting to reverse
direction on a highway. The more traffic (repo churn) there is the less
likely you'll end up in one piece.
Regards,
--
Nicolas Mailhot
12:57 p.m.
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 in every direction' won't help our users losing
> their configs or worse their data.
>
> am I missing something here?
Yes - that we don't need to solve the user data problem for all software
immediately to support rolling back a Mesa upgrade.
I thought that the current plan was to use BTRFS to snapshot the system
before updates, and revert on failure. Of course this implies losing new
data, which is I guess better than a priori unknowable corruption.
1 p.m.
On Tue, Mar 5, 2013 at 1:57 PM, Przemek Klosowski
<przemek.klosowski(a)nist.gov> 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 see how adding another layer is really a problem - since
>> the 'infinite versions in every direction' won't help our users
losing
>> their configs or worse their data.
>>
>> am I missing something here?
>
>
> Yes - that we don't need to solve the user data problem for all software
> immediately to support rolling back a Mesa upgrade.
I thought that the current plan was to use BTRFS to snapshot the system
before updates, and revert on failure. Of course this implies losing new
data, which is I guess better than a priori unknowable corruption.
That plan depends on btrfs being dependable enough to deploy everywhere
and snapshots working. That won't happen anytime soon.
It's also just working around the problem with another layer.
josh
1:09 p.m.
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 react to problem reports I doubt a
rollback would be the fastest path here (also: gnome-settings-daemon being
so crash-prone is a real problem)
--
Nicolas Mailhot
6:40 a.m.
----- 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 someone could ask around and see if there's any
projects/setups
inside Red Hat that would be good for this? ABI checking and perhaps
rpm diffing?
I'm trying to ask guys around, what do they have and what they could
offer for us. And sell it as a good thing for both sides ;-)
Also, do any of the folks working on AutoQA think it could be used
for
this? Or would they suggest a different framework?
I think we should definitely start small here and slowly work
forward.
Every single step in this direction would be great, I agree.
The hardest part will be getting the initial tooling in place.
Yep.
(All this is assuming that this is a good idea that people want I
guess). ;)
Well, we have to do something - I expect we know it - now the
question is how far do we want to go ;-)
Jaroslav
kevin
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
8:31 p.m.
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, I don't know.
>
> Perhaps someone could ask around and see if there's any
> projects/setups
> inside Red Hat that would be good for this? ABI checking and perhaps
> rpm diffing?
I'm trying to ask guys around, what do they have and what they could
offer for us. And sell it as a good thing for both sides ;-)
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/rpmguard/...
Now, whether you'd want to somehow parse such results out from the
existing rpmguard test externally, or write a new more specific test, or
do something else, or dance a little jig, is a different question. But
to a certain extent we're Already Doing That. The rpmguard test is
currently entirely informational, no policies are enforced, but you can
go read the output if you want to be an informed package maintainer...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11 p.m.
On Wed, 06 Mar 2013 18:31:06 -0800
Adam Williamson <awilliam(a)redhat.com> 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/rpmguard/...
Now, whether you'd want to somehow parse such results out from the
existing rpmguard test externally, or write a new more specific test,
or do something else, or dance a little jig, is a different question.
But to a certain extent we're Already Doing That. The rpmguard test
is currently entirely informational, no policies are enforced, but
you can go read the output if you want to be an informed package
maintainer...
Sure. Note however that we don't currently run autoqa on rawhide builds
and that was at least the initial target for this. ;)
But yeah, good test to know...
kevin
11:07 p.m.
On 06/03/13 09:00 PM, Kevin Fenzi wrote:
On Wed, 06 Mar 2013 18:31:06 -0800
Adam Williamson <awilliam(a)redhat.com> 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/rpmguard/...
>
> Now, whether you'd want to somehow parse such results out from the
> existing rpmguard test externally, or write a new more specific test,
> or do something else, or dance a little jig, is a different question.
> But to a certain extent we're Already Doing That. The rpmguard test
> is currently entirely informational, no policies are enforced, but
> you can go read the output if you want to be an informed package
> maintainer...
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 at
http://autoqa.fedoraproject.org/resultsdb/frontend , right now.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9:36 a.m.
On Wed, 06 Mar 2013 21:07:45 -0800
Adam Williamson <awilliam(a)redhat.com> 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 at
http://autoqa.fedoraproject.org/resultsdb/frontend , right now.
Ah right, rpmguard is opt-in right now and does run against rawhide
packages. ;) Thanks.
kevin
4:26 a.m.
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 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
Developers can work on the new library, then gradually packagers can
work on rebuilding all the software. At no point will a users machine
break because you still have the old library.
Obvious drawback is making 'yum' (or whatever) intelligent enough to
automatically remove those libraries. Also it should be removed from the
main mirror at one point (Mageia does that after 2 weeks, so any
dependant package needs to be rebuild within those 2 weeks). After those
2 weeks you could have issues if you install 'Rawhide' and the old
library is not available in the repository anymore.
Another factor is that on Fedora, it seems that it is ok to break
Rawhide. At Mageia that is totally unacceptable. If it happens
accidentally, ok, but very frowned upon if you just push changes you
know might cause issues. Various things are done for those: test
some changes yourself (when it seems needed), announce possible problems
on the mailing list, push some changes to a special testing repository
(to get more people to test your changes other than just you).
--
Regards,
Olav
5:23 a.m.
----- 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 seems that it is ok to break
Rawhide. At Mageia that is totally unacceptable. If it happens
accidentally, ok, but very frowned upon if you just push changes you
know might cause issues. Various things are done for those: test
some changes yourself (when it seems needed), announce possible
problems
on the mailing list, push some changes to a special testing
repository
(to get more people to test your changes other than just you).
This is really what we would like to achieve - not to have
Rawhide to break stuff but to work on next releases (and even
not only on the next releases but upstreams etc., where you need
latest bits).
One of the ideas is to have merge windows for Rawhide, doing as much
changes as possible in side repositories (coprs?)/branches and
merge in a specific time, with the acceptance test as proposed
in this revamp. That's the question on our infrastructure, how
it would be possible (from dist-git, autoqa, build infra)....
Jaroslav
--
Regards,
Olav
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
4:26 p.m.
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 really ugly hack which has several drawbacks, e.g.:
* the one you already cited:
Obvious drawback is making 'yum' (or whatever) intelligent
enough to
automatically remove those libraries.
(and in particular, how to ensure that it
removes only old libraries and not
packages the user actually wants which just happen to not be Required by
anything anymore).
* the fact that this makes the package names much less user-friendly. E.g.,
soname-based package naming is particularly confusing for kdelibs, where you
end up with kdelibs4 actually being kdelibs 3 and kdelibs5 being kdelibs 4.
(What we use for kdelibs in Fedora is 1. suffixes reflecting the actual
major version, not the soname version and 2. the default kdelibs has no
version suffix at all, though it Provides: kdelibs4 and we recommend that
packages Require/BuildRequire kdelibs4(-devel) rather than kdelibs-devel.)
I can see how Debian needs this, because dpkg doesn't handle soname
Provides, and thus their equivalent of AutoReq relies on the versioned
package names, but I think it is a really bad idea for RPM-based distros.
Kevin Kofler
6:08 a.m.
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.0_1-0.9-1.mga2
> lib64spice-client-gtk3.0_4-0.15-3.mga3
This is a really ugly hack which has several drawbacks, e.g.:
* the one you already cited:
> Obvious drawback is making 'yum' (or whatever) intelligent enough to
> automatically remove those libraries.
(and in particular, how to ensure that it removes only old libraries and not
packages the user actually wants which just happen to not be Required by
anything anymore).
keeping unused library is not worst that keeping old perl modules.
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.
The priority for rawhide should be having something that work first.
And I think the problem could be solved ( and in fact, it is already a
problem we have for those that install something, then remove the main
software without cleaning deps ).
* the fact that this makes the package names much less user-friendly.
E.g.,
soname-based package naming is particularly confusing for kdelibs, where you
end up with kdelibs4 actually being kdelibs 3 and kdelibs5 being kdelibs 4.
(What we use for kdelibs in Fedora is 1. suffixes reflecting the actual
major version, not the soname version and 2. the default kdelibs has no
version suffix at all, though it Provides: kdelibs4 and we recommend that
packages Require/BuildRequire kdelibs4(-devel) rather than kdelibs-devel.)
We should not refuse the idea on the ground that this is too complex
for some users to understand the concept of soname. Either they don't,
and then we should just hide libraries from the UI at some point ( and
that's already done ), because with or without soname, that will not
change anything, or they are able to understand and then we should not
treat them as they couldn't.
So 2 drawbacks do not seems much, or at least not "several".
Can you maybe explain others issues so we can find a solution that work
fine ?
--
Michael Scherer
9:44 p.m.
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 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 installation, eating many
MiB, not just "a few".
The priority for rawhide should be having something that work first.
It feels really wrong to design a whole library packaging policy around
Rawhide. The focus needs to be on making stable releases clean without
useless legacy compatibility baggage, and Rawhide needs to be the
development bed for that. Compatibility libraries only make sense where the
packages cannot be ported to the new version in time for the release.
And I think the problem could be solved ( and in fact, it is already
a
problem we have for those that install something, then remove the main
software without cleaning deps ).
The solution for that problem is called yum history undo, and it doesn't
solve the old library problem.
We should not refuse the idea on the ground that this is too
complex
for some users to understand the concept of soname. Either they don't,
and then we should just hide libraries from the UI at some point ( and
that's already done ), because with or without soname, that will not
change anything, or they are able to understand and then we should not
treat them as they couldn't.
IMHO, having KDE 3 libs versioned as kdelibs4 is totally unacceptable. It's
really confusing. (The only worse way to do things is to append an
unreadable suffix for the C++ ABI to that as Debian did with "kdelibs4c2a".
But if you insist on keeping old ABIs around for any and all ABI changes in
Rawhide, we'll eventually end up with the same mess!)
So 2 drawbacks do not seems much, or at least not
"several".
Can you maybe explain others issues so we can find a solution that work
fine ?
Sorry, there is just no solution that can make soname-suffixed libraries
work.
Kevin Kofler
7:47 a.m.
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 installation, eating many
MiB, not just "a few".
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.
And do you have any number ? Cause I have been running distro with such
policy and "many MiB" still doesn't make much to my experience, so
provides credible numbers if you wish to make your point , especially
when talking to people who have seen this policy in action.
> The priority for rawhide should be having something that work
first.
It feels really wrong to design a whole library packaging policy around
Rawhide.
I do not see how it would feel wrong to try to fix a issue by changing a
policy. And I do not see why Rawhide should be less important than
stable for that matter.
The focus needs to be on making stable releases clean without
useless legacy compatibility baggage, and Rawhide needs to be the
development bed for that. Compatibility libraries only make sense where the
packages cannot be ported to the new version in time for the release.
Usually, you have 3 months for branched to make sure everything is
rebuild and that there is only 1 version of a lib. Have you read what
Olav said, about "packages without source rpm will be removed after 2
weeks", and "then they show as having "broken deps in report" ?
The script is not that hard to do, you can even get the one I wrote from
svn ( http://svnweb.mageia.org/adm/puppet/modules/mirror_cleaner/ ).
Not to mention that having the old version for a few days doesn't mean
people cannot go ahead and rebuild their packages as they do now, the
only difference is for users, since this permit to have a installable
rawhide for a more longer period of time.
> And I think the problem could be solved ( and in fact, it is
already a
> problem we have for those that install something, then remove the main
> software without cleaning deps ).
The solution for that problem is called yum history undo, and it doesn't
solve the old library problem.
yum history undo work fine for simple and medium cases, but after a
while due to the level of churn on stable release, it can break :
http://pastebin.com/Bdt6ngy2
And there is nothing broken on my system according to yum check all.
> We should not refuse the idea on the ground that this is too
complex
> for some users to understand the concept of soname. Either they don't,
> and then we should just hide libraries from the UI at some point ( and
> that's already done ), because with or without soname, that will not
> change anything, or they are able to understand and then we should not
> treat them as they couldn't.
IMHO, having KDE 3 libs versioned as kdelibs4 is totally unacceptable. It's
really confusing. (The only worse way to do things is to append an
unreadable suffix for the C++ ABI to that as Debian did with "kdelibs4c2a".
But if you insist on keeping old ABIs around for any and all ABI changes in
Rawhide, we'll eventually end up with the same mess!)
That's just package naming. If you are more concerned by the name of the
rpm than by having users, there is priority issue.
> So 2 drawbacks do not seems much, or at least not
"several".
> Can you maybe explain others issues so we can find a solution that work
> fine ?
Sorry, there is just no solution that can make soname-suffixed libraries
work.
That's still not explaining. 2 is not "several". And "I do not accept
solution" is not the same as "there is no solution".
--
Michael Scherer
11:59 a.m.
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 of Fedora to the next, then to the next etc.
Fedora installations usually go through many upgrades, seeing how we release
every 6 months. The problem with your proposal is that it is focused on
Rawhide and ignores the impact on our actual releases.
And do you have any number ? Cause I have been running distro with
such
policy and "many MiB" still doesn't make much to my experience, so
provides credible numbers if you wish to make your point , especially
when talking to people who have seen this policy in action.
Let's just take one of the few compatibility stacks we actually have to
carry (because porting is far from trivial) as an example:
Name : qt3
Version : 3.3.8b
Release : 41.fc17
Architecture: i686
Size : 10467741
Name : kdelibs3
Version : 3.5.10
Release : 42.fc17
Architecture: i686
Size : 38669698
Name : kdebase3
Version : 3.5.10
Release : 20.fc17
Architecture: i686
Size : 17612161
Name : kdebase3-libs
Version : 3.5.10
Release : 20.fc17
Architecture: i686
Size : 1317496
Now multiply this by the number of soname bumps in the lifetime of an
installation (just look at how often there are broken dependencies from a
soname bump in the Rawhide reports) and see for yourself what doing the math
leaves you with.
And in addition to the space issue, the old libraries would also be
unmaintained and not get any security fixes. Maintaining all the old
libraries with old sonames we ever releases just does not scale! See e.g.
how upgrading to a new version for security reasons is explicitly listed as
an exception to the policy of not bumping sonames in updates for stable
releases in https://fedoraproject.org/wiki/Updates_Policy . It's all the
more valid for Rawhide / between different releases (because each individual
release goes EOL after ~13 months, Rawhide never goes EOL, nor does Fedora
as a whole of course, so old stuff can get REALLY old). Leaving old
unmaintained libraries lying around on user systems is a security disaster!
I do not see how it would feel wrong to try to fix a issue by
changing a
policy. And I do not see why Rawhide should be less important than
stable for that matter.
Because the whole purpose of Rawhide is to serve as a development bed for
our stable releases. Rawhide is not and should not be our product, our
releases are.
And in any cases, the releases do exist and you cannot entirely ignore their
existence in your proposal.
Usually, you have 3 months for branched to make sure everything is
rebuild and that there is only 1 version of a lib. Have you read what
Olav said, about "packages without source rpm will be removed after 2
weeks", and "then they show as having "broken deps in report" ?
Removing the old packages is not enough, you actually have to add Obsoletes
to the current version if you don't want the old versions to accumulate on
upgrades from one stable release to the next.
And who is going to enforce the Obsoletes? It WILL get forgotten more often
than not. We already have enough broken upgrade paths as it stands.
In addition, having those Obsoletes will make users complain "Why does yum
want to remove the compatibility library my [broken, not recompiled against
the current Fedora] third-party package needs?", whereas not having them
will make old (and unmaintained!) versions accumulate (as I said before).
The best way to avoid such confusion is to avoid setting false expectations
in the first place by just not version-suffixing the libraries.
Not to mention that having the old version for a few days doesn't
mean
people cannot go ahead and rebuild their packages as they do now, the
only difference is for users, since this permit to have a installable
rawhide for a more longer period of time.
Just to avoid a window of a few days, your proposal wants to introduce a
version suffix we're stuck with forever. This seems very wrong.
yum history undo work fine for simple and medium cases, but after a
while due to the level of churn on stable release, it can break :
http://pastebin.com/Bdt6ngy2
The use case I was talking about is, you try the package, you don't like it,
you uninstall it (before doing any other yum operations). Indeed, undoing an
older yum operation may or may not work. But it's not the common case: Why
would you want to uninstall a package after deciding you like it?
That's just package naming. If you are more concerned by the name
of the
rpm than by having users, there is priority issue.
We have users right now, without your proposal.
And naming is an important issue: If you buy beef lasagne, you don't want to
have horse meat in them! Likewise, if you install kdelibs4, you don't want
to get kdelibs 3 installed.
That's still not explaining. 2 is not "several".
With the security issue, I listed 3 reasons now. :-) There are certainly
more, but those 3 are already severe enough to make your proposal a complete
no go.
And "I do not accept solution" is not the same as
"there is no solution".
It's not that *I* don't accept your "solution", it's just that it
doesn't
work.
Kevin Kofler
4:30 p.m.
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 stall development!
And it's all the more ridiculous that this is being proposed after we
allowed the team for one of our most "core" components (Anaconda) to
KNOWINGLY break its functionality in Rawhide, forcing a release slip. What
use is it to add more tests against unintentional breakage which are
inevitably going to slow down all Rawhide builds (especially chain builds)
when we are happily tolerating INTENTIONAL breakage?
Kevin Kofler
8:09 a.m.
On Tue, Mar 5, 2013 at 11:30 PM, Kevin Kofler <kevin.kofler(a)chello.at> 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 red tape we have in stable releases
to Rawhide will completely stall development!
I think this would require very little red tape; certainly not the
14-day wait that bodhi typically imposes.
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.
If a new package does break tier 1/2 tests, yes, the rawhide gate
requires a change in the workflow: the breakage must be fixed "now".
OTOH the breakage will have to be fixed _anyway_; the tests will make
it:
1) easier to spot (we wouldn't need to rely on manual testing)
2) easier to diagnose (we would know fairly precisely what has changed
between the working and broken version, and it would be a fairly small
set of packages)
3) much better for everyone else working within rawhide.
All of these should save time for everybody involved. Yes, the
rawhide gate may mean more work "now", but overall shouldn't require
extra work for package owners. (It may require extra work for
"Change" owners that implies updating the tests.)
And it's all the more ridiculous that this is being proposed
after we
allowed the team for one of our most "core" components (Anaconda) to
KNOWINGLY break its functionality in Rawhide, forcing a release slip.
I don't think there is any obvious reason to exempt anaconda from this
process. Of course, we start with zero tests, and thus also zero
requirements on anaconda; OTOH I expect somebody will propose to add a
test that "minimal network install should always be working" very soon
after the infrastructure is ready. Such a test would obviously apply
both to anaconda updates and to changes of everything else that may
break anaconda.
Mirek
9:49 p.m.
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 the tests pass.
I don't think there is any obvious reason to exempt anaconda from
this
process. Of course, we start with zero tests, and thus also zero
requirements on anaconda; OTOH I expect somebody will propose to add a
test that "minimal network install should always be working" very soon
after the infrastructure is ready. Such a test would obviously apply
both to anaconda updates and to changes of everything else that may
break anaconda.
It's quite funny that you're talking about enforcing requirements on
Anaconda AFTER FESCo gave Anaconda developers carte blanche to put a KNOWN
BROKEN Anaconda into pre-F18 Rawhide and leave it there even when it was
known not to get fixed in time for the release, causing release slippage.
Does this mean you admit that FESCo made a mistake? Or that FESCo as a whole
finally admits to having made a mistake? :-)
Kevin Kofler
12:27 p.m.
On Mon, 11 Mar 2013 03:49:38 +0100
Kevin Kofler <kevin.kofler(a)chello.at> 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 builds significantly,
even if the builds get tagged immediately after the tests pass.
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 starts
right then.
So with current newrepo tasks about 13min per newrepo, so thats 13 or
26 min per build.
> I don't think there is any obvious reason to exempt anaconda
from
> this process. Of course, we start with zero tests, and thus also
> zero requirements on anaconda; OTOH I expect somebody will propose
> to add a test that "minimal network install should always be
> working" very soon after the infrastructure is ready. Such a test
> would obviously apply both to anaconda updates and to changes of
> everything else that may break anaconda.
It's quite funny that you're talking about enforcing requirements on
Anaconda AFTER FESCo gave Anaconda developers carte blanche to put a
KNOWN BROKEN Anaconda into pre-F18 Rawhide and leave it there even
when it was known not to get fixed in time for the release, causing
release slippage. Does this mean you admit that FESCo made a mistake?
Or that FESCo as a whole finally admits to having made a mistake? :-)
<eye-roll>
Hasn't this been discussed to death? We could have taken the hit in f18
and landed the new anaconda, or we could have reverted and taken the
hit in f19 to land the new anaconda, etc. It had to be done, sooner is
better than latter.
kevin
1:55 p.m.
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 starts
right then.
So with current newrepo tasks about 13min per newrepo, so thats 13 or
26 min per build.
+ the time it takes to run the tests themselves! The more tests you add, the
longer they will take.
Hasn't this been discussed to death? We could have taken the hit
in f18
and landed the new anaconda, or we could have reverted and taken the
hit in f19 to land the new anaconda, etc. It had to be done, sooner is
better than latter.
How is sooner better? It led to a release slippage by months (!) and the
installer that was released is still missing features (not only the
intentionally dropped ones, which are another issue entirely). It would have
been better to punt the new Anaconda to F19 or even F20, if it had to be
done at all.
Kevin Kofler
2:09 p.m.
On Mon, 11 Mar 2013 19:55:39 +0100
Kevin Kofler <kevin.kofler(a)chello.at> 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 to be added. The min delay would be that it gets added and
> newrepo starts right then.
>
> So with current newrepo tasks about 13min per newrepo, so thats 13
> or 26 min per build.
+ the time it takes to run the tests themselves! The more tests you
add, the longer they will take.
Only with a 13 minute granularity. Ie, if they take less than 13
minutes, it's only going to take 26 min to land. They would have to
take 14-26 min to miss the next one, etc.
> Hasn't this been discussed to death? We could have taken the
hit in
> f18 and landed the new anaconda, or we could have reverted and
> taken the hit in f19 to land the new anaconda, etc. It had to be
> done, sooner is better than latter.
How is sooner better? It led to a release slippage by months (!) and
the installer that was released is still missing features (not only
the intentionally dropped ones, which are another issue entirely). It
would have been better to punt the new Anaconda to F19 or even F20,
Why? if we reverted no work would have gone on on the new codebase, all
work would have happened to bandaid the old codebase into working.
So, we would have been in the exact same place for f19 or f20 or
whatever. This way it's done and we can move forward with a more sane
code base and get it fixed up.
if it had to be done at all.
https://fedoraproject.org/wiki/Anaconda/NewInstaller
http://ohjeezlinux.wordpress.com/2013/02/05/anaconda-retrospective/
kevin
5:23 p.m.
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 Hat and/or Fedora
developers.
Kevin Kofler
9:49 a.m.
On Tue, Mar 12, 2013 at 11:23 PM, Kevin Kofler <kevin.kofler(a)chello.at> 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 been told the new anaconda was actually developed on a branch,
but merging it back into mainline/rawhide took about two months
because the underlying platform anaconda has started to rely on has
changed too much while the branch was being developed.
This was actually one of the motivations for this proposal - to allow
agreeing on the "base design" == tier 2 == inter-package interfaces,
and enforcing that they are kept working. In the post-revamp model,
anaconda has the option of asking to add some of the functionality
anaconda relies on in the tier 2 test suite, thus avoiding the
breakage or at least detecting it early enough.
Mirek
11:02 a.m.
On Tue, 12 Mar 2013 23:23:35 +0100
Kevin Kofler <kevin.kofler(a)chello.at> 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, sure they can. But they don't have sufficient resources to do
that and _ALSO_ maintain the old code base.
Somehow all other upstreams manage, even where they happen to be Red
Hat and/or Fedora developers.
An installer isn't like those things.
So, to recap:
1) You can have old anaconda for f19, at the cost of no one being able
to work on the new one. Leading to f20 having the exact same issue.
or
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 explain it in more detail, so I think I will
leave it at that.
kevin
10:25 a.m.
On 03/13/2013 12:02 PM, Kevin Fenzi wrote:
<snip>
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 explain it in more detail, so I think I will
leave it at that.
kevin
Finally, a reasonable development approach. Please do get the installer
in maintainable shape and consistent from release to release.
--
Regards,
OldFart
3:25 a.m.
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 introducing changes.
* Define the interfaces that applications can rely on (and by
inference, the ones that they can't).
* Ensure that functionality implemented in Fedora doesn't
unintentionally regress, and provide a clear way to change or replace
earlier implementations.
To do this, we propose to specify three levels of stability we
attempt. These are defined at the level of interfaces (e.g. specific
library/command/file), not at the level of packages:
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
2: "Base design": A set of functionality that was implemented and
needs to be kept working in any composed tree, including rawhide; may
include specific commands.
Behavior that other parts of the distribution depends on.
Functionality accepted for this tier by FESCo using the planning
process, and some interfaces this functionality relies on.
3: "Internal API": we'll do our best not to change it within a release
lifetime; basically the existing Fedora compatibility and update
rules.
e.g. Python/Perl/Ruby X.Y version, most library interfaces, and
major aspects of UI.
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.
If this gate will avoid the frequent broken deps in rawhide, then I'm
all for it. The current situation where any package can be pushed to
rawhide at any time which breaks any deps, is what makes rawhide pretty
much useless to me. Of course there are many other things that can go
wrong besides, but if we could at least reliably install rawhide packages
without needing to be an expert in fixing broken RPM deps, then we'd be
heading in the right direction.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
9:03 p.m.
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 angles we took in discussing it in
person at FUDCon is that it has the potential to contribute to the more
general idea of making Fedora more flexible in terms of what we can
build and release. It has the effect of giving us a defined 'core' of
functionality on top of which we could build various things. It would
only be one piece of a larger puzzle here - things like better image
building tools and Formulas are part of the same puzzle - but it's an
element I was quite interested in.
Also, I recall the in-person discussions making it clearer that this
plan is pretty strongly dependent on automated testing. This has been
discussed somewhat in the follow-ups, but to make sure it's very clear,
my reading of the proposal is that it would require substantially more
sophisticated and reliable tests than we currently have in AutoQA, and
we'd need development resources - either RH paid, or volunteer - to
build AutoQA up to the point where it could support this plan without
causing unnecessary disruption.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:48 a.m.
On Wed, Mar 6, 2013 at 10:03 PM, Adam Williamson <awilliam(a)redhat.com>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 potential to contribute to the more
general idea of making Fedora more flexible in terms of what we can build
and release. It has the effect of giving us a defined 'core' of
functionality on top of which we could build various things. It would only
be one piece of a larger puzzle here - things like better image building
tools and Formulas are part of the same puzzle - but it's an element I was
quite interested in.
Also, I recall the in-person discussions making it clearer that this plan
is pretty strongly dependent on automated testing. This has been discussed
somewhat in the follow-ups, but to make sure it's very clear, my reading of
the proposal is that it would require substantially more sophisticated and
reliable tests than we currently have in AutoQA, and we'd need development
resources - either RH paid, or volunteer - to build AutoQA up to the point
where it could support this plan without causing unnecessary disruption.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.**org/mailman/listinfo/devel<https://admin...
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.
--
Mark Bidewell
http://www.linkedin.com/in/markbidewell
4:16 p.m.
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 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 proposal very rapidly mutated into a
wide-ranging, 'what do we want to change in Fedora?' discussion that
lasted for a few hours.) I don't think anyone was recording at that
point. I think some people wrote blog posts about it, though.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5:17 p.m.
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 proposal very rapidly mutated into a
wide-ranging, 'what do we want to change in Fedora?' discussion that
lasted for a few hours.) I don't think anyone was recording at that
point. I think some people wrote blog posts about it, though.
Unfortunately, this leaves people who haven't attended the FUDCon
disconnected from the discussions and you only get very distilled
impressions. Recording conversations like this is fairly important
Rahul
7:56 p.m.
On Thu, Mar 7, 2013 at 5:17 PM, Rahul Sundaram <metherid(a)gmail.com> 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 release cycle (not spot's fault,
> but the discussion of his proposal very rapidly mutated into a wide-ranging,
> 'what do we want to change in Fedora?' discussion that lasted for a few
> hours.) I don't think anyone was recording at that point. I think some
> people wrote blog posts about it, though.
Unfortunately, this leaves people who haven't attended the FUDCon
disconnected from the discussions and you only get very distilled
impressions. Recording conversations like this is fairly important
Notes were collected at the end and this thread began with I believe a
fair representation of the outcome of the discussion and it was signed
off on by the list of people included in the original post to which I
am happy to add my name as someone who was present for most of the
discussion. Of course it was fully expected there would be extensive
discussion here about the idea.
John
4099
days inactive
4108
days old
53 comments
23 participants
participants (23)
-
Adam Williamson -
Bill Nottingham -
Clyde E. Kunkel -
Colin Walters -
Daniel P. Berrange -
Dave Jones -
drago01 -
Ian Malone -
inode0 -
Jan Zelený -
Jaroslav Reznik -
Josh Boyer -
Kevin Fenzi -
Kevin Kofler -
Mark Bidewell -
Michael Scherer -
Miloslav Trmač -
Nicolas Mailhot -
Olav Vitters -
Przemek Klosowski -
Rahul Sundaram -
Seth Vidal -
Stephen Gallagher