Re: Revamping the non responsive maintainer process

[Vít Ondruch]

Dne 6.11.2012 16:04, Ralf Corsepius napsal(a):

On 11/06/2012 02:24 PM, Vít Ondruch wrote:

Dne 6.11.2012 14:17, Aleksandar Kurtakov napsal(a):

- Original Message -

From: "Vít Ondruch" 
To: devel@lists.fedoraproject.org
Sent: Tuesday, November 6, 2012 2:56:18 PM
Subject: Re: Revamping the non responsive maintainer process

So give me the permission [1] as well as the others who requested it
before me.

Apparently the current owner doesn't care. You can compare the
version
history in koji [2] and [3] and if he doesn't care about one package,
it
is reasonable to doubt that the other packages will be in better
state.

The problem here is that pkgdb requests are not auto approved after
some timeout period if the maintainer hasn't reacted.


That would be sweet if it would be auto approved.


Do you want a backdoor permitting all script kidz and overzealous, but 
unexperienced newcomers to automatically take over packages?


Come on, there are the same alarmist who think that Wikipedia will be 
hijacked and destroyed but have it happened any time?


You are still maintainer, you are still owner and you are notified by 
email about every change in your package, so you'll be able to catch 
such activity pretty soon and act accordingly.




I regret having to say so, but the unpleasant fact is, Fedora does 
have such "participants".


Such people are everywhere. May be they can trick the system, become 
proven packager and takeover you packages. Who knows. You can never be sure.




When I do not react upon requests, 


I appreciate you swiftly react upon request, but unfortunately that does 
not imply that every other packager will react as swiftly as you.


I usually either missed or forgot about the request or deliberately do 
not yet want to approve.
That said, what I feel is missing in Fedora's pkgdb web-forms is an 
option to "leave a comment to applicant" and an "some automated 
reminder mechanisms" to remind "approvers" about pending requests.


There is bugzilla, but it is definitely not the most flexible tool on 
the world.




Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Revamping the non responsive maintainer process

[Vít Ondruch]

Dne 6.11.2012 16:40, Marcela Mašláňová napsal(a):

On 11/06/2012 04:32 PM, "Jóhann B. Guðmundsson" wrote:

On 11/06/2012 01:07 PM, Marcela Mašláňová wrote:

Oh no, you are top posting again ;-)

Could you create fesco ticket for this package? I proposed usage of
the script in Johann's ticket
https://fedorahosted.org/fesco/ticket/967#comment:7 Imho it might be
better to give acl to more people, then only punish developers.


If that's the plan why not drop the ownership model ( a.k.a dictatorship
model ) all together so everyone can contribute to every package?

If the answer to the above is no we cant/wont do that then we need
proper cleanup process "to punish developer" as you put it failing to
understand that packagers/maintainers aren't' the only one in the
community dealing with packages ( QA,Releng,Infra etc )...

JBG


The "dictatorship" is there to safe us from reckless changes.


If you want to be sure, there should be some code review tool in the 
process, which would allow pear reviews of commits, e.g. if approved 
packager commits something into package he does not own/maintain, the 
commit would need to go through peer-review, but any other packager 
could be the peer.


Moreover every reckless change can be reverted.

Vit



If Fedora allow everyone to patch everything, then we have to check 
packagers more thoroughly than give them a few reviews usually of one 
language.


I safe my comments for tomorrows FESCo because we probably can't reach 
consensus.


Marcela


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Revamping the non responsive maintainer process

[Pierre-Yves Chibon]

On Wed, 2012-11-07 at 09:49 +0100, Vít Ondruch wrote:
> 
> You are still maintainer, you are still owner and you are notified by 
> email about every change in your package, so you'll be able to catch 
> such activity pretty soon and act accordingly.

To be the devil's advocate, you do get the email but most of the time
right after the commit the person will push an update which you're not
able to withdraw as you did not create it.
Plus sometime, people takes days off...

Yeah, changes can be reverted but epoch sucks!

I do like the idea of some kind of per-review. Either the official
maintainer approve the changes or say two other maintainers do.
But there should be at minimal some time between the change in the spec
and the build of the new package.

Pierre
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[Vít Ondruch]

Dne 7.11.2012 08:08, Dan Horák napsal(a):

Jesse Keating píše v Út 06. 11. 2012 v 10:48 -0800:

On 11/06/2012 03:35 AM, Vít Ondruch wrote:

And rel-engs actively prohibits staging as much as they can  [1], where
it should be encouraged IMO.

Vit


[1] https://fedorahosted.org/rel-eng/ticket/4580


Additional tags have a high cost to the infrastructure and every user of
said infrastructure.  It creates more newRepo tasks which take
significant time to complete, and since they are resource intensive only
a few can be done at once.  This means that newRepo tasks get delayed
farther and people waiting for buildroot updates have to wait longer,
and longer, and longer.  This is why extra tags/roots are used sparingly
for more intensive updates than what you're requesting here.

but there is a solution - learn koji use multiple repos, in cases like
this one you will have one repo that is tied to fX tag (large, but
changed only when "fedora" changes) and another to the side tag (this
will be very small one, can be changed more often), koji will then
generate a mock config with 2 repos and you are done


Dan



In combination with 
https://admin.fedoraproject.org/pkgdb/acls/name/createrepo_c it would be 
outstanding.



Vit
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Revamping the non responsive maintainer process

[Vít Ondruch]

Dne 7.11.2012 09:52, Vít Ondruch napsal(a):

Dne 6.11.2012 16:40, Marcela Mašláňová napsal(a):

On 11/06/2012 04:32 PM, "Jóhann B. Guðmundsson" wrote:

On 11/06/2012 01:07 PM, Marcela Mašláňová wrote:

Oh no, you are top posting again ;-)

Could you create fesco ticket for this package? I proposed usage of
the script in Johann's ticket
https://fedorahosted.org/fesco/ticket/967#comment:7 Imho it might be
better to give acl to more people, then only punish developers.


If that's the plan why not drop the ownership model ( a.k.a 
dictatorship

model ) all together so everyone can contribute to every package?

If the answer to the above is no we cant/wont do that then we need
proper cleanup process "to punish developer" as you put it failing to
understand that packagers/maintainers aren't' the only one in the
community dealing with packages ( QA,Releng,Infra etc )...

JBG


The "dictatorship" is there to safe us from reckless changes.


If you want to be sure, there should be some code review tool in the 
process, which would allow pear reviews


* of course it should be peer review ;)

of commits, e.g. if approved packager commits something into package 
he does not own/maintain, the commit would need to go through 
peer-review, but any other packager could be the peer.


Moreover every reckless change can be reverted.

Vit



If Fedora allow everyone to patch everything, then we have to check 
packagers more thoroughly than give them a few reviews usually of one 
language.


I safe my comments for tomorrows FESCo because we probably can't 
reach consensus.


Marcela




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Revamping the non responsive maintainer process

[Vít Ondruch]

Dne 7.11.2012 10:00, Pierre-Yves Chibon napsal(a):

On Wed, 2012-11-07 at 09:49 +0100, Vít Ondruch wrote:

You are still maintainer, you are still owner and you are notified by
email about every change in your package, so you'll be able to catch
such activity pretty soon and act accordingly.

To be the devil's advocate, you do get the email but most of the time
right after the commit the person will push an update which you're not
able to withdraw as you did not create it.


Yes, update in Bodhi. It takes 7 days to go through review. If it cannot 
be withdrawen by maintainer or lets say proven packager, then it can be 
improved.



Plus sometime, people takes days off...


Yes, and if you did mistake before you go to holidays, then what?

You can always find some drawbacks with any process, but it doesn't mean 
that we should not be more open and trust your peers.




Yeah, changes can be reverted but epoch sucks!

I do like the idea of some kind of per-review. Either the official
maintainer approve the changes or say two other maintainers do.
But there should be at minimal some time between the change in the spec
and the build of the new package.

Pierre


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Revamping the non responsive maintainer process

[Ralf Corsepius]

On 11/07/2012 09:49 AM, Vít Ondruch wrote:

Dne 6.11.2012 16:04, Ralf Corsepius napsal(a):

On 11/06/2012 02:24 PM, Vít Ondruch wrote:

Dne 6.11.2012 14:17, Aleksandar Kurtakov napsal(a):

- Original Message -

From: "Vít Ondruch" 
To: devel@lists.fedoraproject.org
Sent: Tuesday, November 6, 2012 2:56:18 PM
Subject: Re: Revamping the non responsive maintainer process

So give me the permission [1] as well as the others who requested it
before me.

Apparently the current owner doesn't care. You can compare the
version
history in koji [2] and [3] and if he doesn't care about one package,
it
is reasonable to doubt that the other packages will be in better
state.

The problem here is that pkgdb requests are not auto approved after
some timeout period if the maintainer hasn't reacted.


That would be sweet if it would be auto approved.


Do you want a backdoor permitting all script kidz and overzealous, but
unexperienced newcomers to automatically take over packages?


Come on, there are the same alarmist who think that Wikipedia will be
hijacked and destroyed but have it happened any time?


Well, you might not be aware about it, but at least de.wikipedia.org 
does have similiar problems as we are discussing here.



You are still maintainer, you are still owner and you are notified by
email about every change in your package, so you'll be able to catch
such activity pretty soon and act accordingly.


You get notified when the damage is done, e.g. when your spec file has 
been modified to your dissatisfaction and when the package already has 
entered rawhide.


All that's left to you unless these changes immediately break something, 
is to either silently swallow these changes or to revert them sometime 
later.



I usually either missed or forgot about the request or deliberately do
not yet want to approve.
That said, what I feel is missing in Fedora's pkgdb web-forms is an
option to "leave a comment to applicant" and an "some automated
reminder mechanisms" to remind "approvers" about pending requests.


There is bugzilla, but it is definitely not the most flexible tool on
the world.
Wrt. bugzilla, similar considerations apply: BZ-mails are sent out once 
and therefore are easy to forget/miss.



Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Revamping the non responsive maintainer process

[Pierre-Yves Chibon]

On Wed, 2012-11-07 at 10:12 +0100, Vít Ondruch wrote:
> Dne 7.11.2012 10:00, Pierre-Yves Chibon napsal(a):
> > On Wed, 2012-11-07 at 09:49 +0100, Vít Ondruch wrote:
> >> You are still maintainer, you are still owner and you are notified by
> >> email about every change in your package, so you'll be able to catch
> >> such activity pretty soon and act accordingly.
> > To be the devil's advocate, you do get the email but most of the time
> > right after the commit the person will push an update which you're not
> > able to withdraw as you did not create it.
> 
> Yes, update in Bodhi. It takes 7 days to go through review. If it cannot 
> be withdrawen by maintainer or lets say proven packager, then it can be 
> improved.
> 
> > Plus sometime, people takes days off...
> 
> Yes, and if you did mistake before you go to holidays, then what?

Id'think that's also why we have updates-testing

> You can always find some drawbacks with any process, but it doesn't mean 
> that we should not be more open and trust your peers.

Agreed. I was more playing the devil's advocate as I know the situation
has happened before.
People modified a spec thinking that was the way to go, the maintainer
who had the bigger picture was away and the changes had to be reverted
and the package got an epoch.

Pierre
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Revamping the non responsive maintainer process

[Vít Ondruch]

Dne 7.11.2012 10:21, Ralf Corsepius napsal(a):

On 11/07/2012 09:49 AM, Vít Ondruch wrote:

Dne 6.11.2012 16:04, Ralf Corsepius napsal(a):

On 11/06/2012 02:24 PM, Vít Ondruch wrote:

Dne 6.11.2012 14:17, Aleksandar Kurtakov napsal(a):

- Original Message -

From: "Vít Ondruch" 
To: devel@lists.fedoraproject.org
Sent: Tuesday, November 6, 2012 2:56:18 PM
Subject: Re: Revamping the non responsive maintainer process

So give me the permission [1] as well as the others who requested it
before me.

Apparently the current owner doesn't care. You can compare the
version
history in koji [2] and [3] and if he doesn't care about one 
package,

it
is reasonable to doubt that the other packages will be in better
state.

The problem here is that pkgdb requests are not auto approved after
some timeout period if the maintainer hasn't reacted.


That would be sweet if it would be auto approved.


Do you want a backdoor permitting all script kidz and overzealous, but
unexperienced newcomers to automatically take over packages?


Come on, there are the same alarmist who think that Wikipedia will be
hijacked and destroyed but have it happened any time?


Well, you might not be aware about it, but at least de.wikipedia.org 
does have similiar problems as we are discussing here.



You are still maintainer, you are still owner and you are notified by
email about every change in your package, so you'll be able to catch
such activity pretty soon and act accordingly.


You get notified when the damage is done


Definitely, we are not in age of Minority Report yet, but even Pre-crime 
had its issues.


, e.g. when your spec file has been modified to your dissatisfaction 
and when the package already has entered rawhide.


All that's left to you unless these changes immediately break 
something, is to either silently swallow these changes or to revert 
them sometime later.



I usually either missed or forgot about the request or deliberately do
not yet want to approve.
That said, what I feel is missing in Fedora's pkgdb web-forms is an
option to "leave a comment to applicant" and an "some automated
reminder mechanisms" to remind "approvers" about pending requests.


There is bugzilla, but it is definitely not the most flexible tool on
the world.
Wrt. bugzilla, similar considerations apply: BZ-mails are sent out 
once and therefore are easy to forget/miss.



Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] 2012-11-07 @ 17:00 UTC - F18 Beta Blocker Bug Review #7

[Kamil Paral]

# F18 Beta Blocker Review meeting #7
# Date: 2012-11-07
# Time: 17:00 UTC
# Location: #fedora-qa on irc.freenode.net

Note: The UTC time was changed. If your country switched from summer time to 
winter time the last weekend, your local time of the meeting should stay the 
same.

Keeping with what we've done for the last couple of weeks, we're
planning to stop around the 3 hour mark if we're not done by then and
resume on 2012-11-08.

We'll be running through the beta blockers and nice-to-haves. The
current list of blocker bugs is available at:
http://qa.fedoraproject.org/blockerbugs/current

We'll be reviewing the bugs to determine ...

1. Whether they meet the Beta release criteria [1] and should stay
 on the list
2. Whether they are getting the attention they need

[1] http://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria

For guidance on Blocker and Nice-to-have (NTH) bugs, please refer to
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_nth_bug_process

For the blocker review meeting protocol, see
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F-18 Branched report: 20121107 changes

[Fedora Branched Report]

Compose started at Wed Nov  7 09:15:33 UTC 2012

Broken deps for x86_64
--
[dhcp-forwarder]
dhcp-forwarder-upstart-0.10-1801.fc18.noarch requires /sbin/initctl
[dnf]
dnf-0.2.14-2.git4831982.fc18.noarch requires python-hawkey >= 0:0.3.0
[dustmite]
dustmite-1-5.20120304gitcde46e0.fc17.x86_64 requires 
libphobos-ldc.so.59()(64bit)
[func]
func-0.28-1.fc17.noarch requires smolt
[gcc-python-plugin]
gcc-python2-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18
gcc-python2-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18
gcc-python3-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18
gcc-python3-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18
[gdb-heap]
gdb-heap-0.5-9.fc18.x86_64 requires glibc(x86-64) = 0:2.15
[gnome-do-plugins]
gnome-do-plugins-banshee-0.8.4-10.fc18.x86_64 requires 
mono(Banshee.CollectionIndexer) = 0:2.4.0.0
[gnome-shell-theme-selene]
gnome-shell-theme-selene-3.4.0-5.fc18.noarch requires 
gnome-shell-extensions-user-theme
[ip-sentinel]
ip-sentinel-upstart-0.12-1303.fc18.noarch requires /sbin/initctl
[libsyncml]
1:libsyncml-0.4.6-4.fc17.i686 requires libsoup-2.2.so.8
1:libsyncml-0.4.6-4.fc17.x86_64 requires libsoup-2.2.so.8()(64bit)
[mapserver]
mapserver-perl-6.0.1-5.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2)
[milter-greylist]
milter-greylist-upstart-4.2.7-1701.fc18.noarch requires /sbin/initctl
[mod_pubcookie]
mod_pubcookie-3.3.4a-7.fc18.x86_64 requires httpd-mmn = 
0:20051115-x86-64
[openvrml]
libopenvrml-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0
libopenvrml-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0
libopenvrml-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0
libopenvrml-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
libopenvrml-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
libopenvrml-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0
libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0
libopenvrml-gl-0.18.9-3.fc18.i686 requires 
libboost_filesystem-mt.so.1.48.0
libopenvrml-gl-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
libopenvrml-gl-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
libopenvrml-gl-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
openvrml-java-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
openvrml-java-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
openvrml-java-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
openvrml-javascript-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
openvrml-javascript-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
openvrml-javascript-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
openvrml-nodes-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
openvrml-nodes-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
openvrml-nodes-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
openvrml-xembed-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
openvrml-xembed-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
openvrml-xembed-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
[perl-Hardware-Verilog-Parser]
perl-Hardware-Verilog-Parser-0.13-9.fc17.noarch requires 
perl(:MODULE_COMPAT_5.14.2)
[perl-OpenOffice-UNO]
perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires 
perl(:MODULE_COMPAT_5.14.2)
[presence]
presence-0.4.6-2.fc18.x86_64 requires libcogl.so.9()(64bit)
[pyfuzzy]
pyfuzzy-0.1.0-5.fc18.noarch requires antlr3-python
[reciteword]
reciteword-0.8.4-10.fc18.x86_64 requires esound
[resource-agents]
resource-agents-3.9.2-3.fc18.5.x86_64 requires libplumbgpl.so.2()(64bit)
resource-agents-3.9.2-3.fc18.5.x86_64 requires libplumb.so.2()(64bit)
[ruby-revolution]
ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires 
libedataserver-1.2.so.16()(64bit)
ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires 
libecal-1.2.so.12()(64bit)
ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires 
libebook-1.2.so.13()(64bit)
[rubygem-activeldap]
rubygem-activeldap-1.2.2-3.fc17.noarch requires 
rubygem(gettext_activerecord) >= 0:2.1.0
rubygem-activeldap-1.2.2-3.fc17.noarch requires ruby(abi) = 0:1.8
[rubygem-calendar_date_select]
rubygem-calendar_date

Unblocking packages: new review needed?

[M . M .]

I have requested Release Engineering to unblock some packages,
which previously had been blocked on some branches:
https://fedorahosted.org/rel-eng/ticket/5387
I have been told that those packages must be reviewed again in order to be
unblocked.
I'm not 100% sure of what to do. Do I have to open a new review request on
Bugzilla for each package "from scratch" (i.e., exactly as if they were
completely new)?
Are there any further steps I must take?
Thank you in advance.
M.M.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Self-introduction

[Ben Cotton]

Greetings!

I'd like to introduce myself to the group before I get to work packaging
the Release Notes. I've been a contributor to the Documentation Group for
several years, including serving as the team lead for Fedora 17 and 18.

Eventually, there are a few other packages I'd like to maintain, but that
will require some extra time. My non-Fedora activities working as a de
facto project manager for a scientific computing service at Purdue
University and pursuing an MS in IT Project Management.

-- 
Ben Cotton
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Unblocking packages: new review needed?

[tim.laurid...@gmail.com]

Sound very strange, it is not some kind orphan package, there have been out
of Fedora and has to re-enter.
It it an active maintained package in F17, there just have not worked with
latest version for gnome-shell, because they change the way themes works in
every release.
It a waste of reviewers time to have to review such a package again IMHO.

Tim


On Wed, Nov 7, 2012 at 2:57 PM, M.M.  wrote:

> I have requested Release Engineering to unblock some packages,
> which previously had been blocked on some branches:
> https://fedorahosted.org/rel-eng/ticket/5387
> I have been told that those packages must be reviewed again in order to be
> unblocked.
> I'm not 100% sure of what to do. Do I have to open a new review request
> on Bugzilla for each package "from scratch" (i.e., exactly as if they were
> completely new)?
> Are there any further steps I must take?
> Thank you in advance.
> M.M.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Anything changed on rawhide builders recently? Can't build ladvd

[Tomasz Torcz]

Hi,

  Today I tried to build ladvd 1.0.4 package for rawhide, but it failed with
some strange message 
http://koji.fedoraproject.org/koji/getfile?taskID=4662562&name=build.log&offset=-4000
 ,
which is pasted below.  So I rolled back to 1.0.2 and it failed to build, too.
It was building fine previously.
  Then I tried to build for F18, it was built succesfuly (although it packaging 
ultimately
failed because of unrelated reason).

  So the question is: what's broken with rawhide builders?


  The message on rawhide builder is:
#v+
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -Wall -Werror -Wformat 
-Wformat-security -D_FORTIFY_SOURCE=2 -fno-delete-null-pointer-checks 
-fstack-protector -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom 
-fasynchronous-unwind-tables -c child.c  -fPIC -DPIC -o .libs/child.o
In file included from cli.c:20:0:
common.h:152:8: error: redefinition of 'struct sysinfo'
In file included from /usr/include/linux/kernel.h:4:0,
 from /usr/include/linux/sysctl.h:25,
 from /usr/include/sys/sysctl.h:43,
 from common.h:50,
 from cli.c:20:
/usr/include/linux/sysinfo.h:7:8: note: originally defined here
make[2]: *** [cli.lo] Error 1
make[2]: *** Waiting for unfinished jobs
In file included from child.c:20:0:
common.h:152:8: error: redefinition of 'struct sysinfo'
In file included from /usr/include/linux/kernel.h:4:0,
 from /usr/include/linux/sysctl.h:25,
 from /usr/include/sys/sysctl.h:43,
 from common.h:50,
 from child.c:20:
/usr/include/linux/sysinfo.h:7:8: note: originally defined here
make[2]: *** [child.lo] Error 1
In file included from util.c:20:0:
common.h:152:8: error: redefinition of 'struct sysinfo'
In file included from /usr/include/linux/kernel.h:4:0,
 from /usr/include/linux/sysctl.h:25,
 from /usr/include/sys/sysctl.h:43,
 from common.h:50,
 from util.c:20:
/usr/include/linux/sysinfo.h:7:8: note: originally defined here
In file included from master.c:20:0:
common.h:152:8: error: redefinition of 'struct sysinfo'
In file included from /usr/include/linux/kernel.h:4:0,
 from /usr/include/linux/sysctl.h:25,
 from /usr/include/sys/sysctl.h:43,
 from common.h:50,
 from master.c:20:
/usr/include/linux/sysinfo.h:7:8: note: originally defined here
make[2]: Leaving directory `/builddir/build/BUILD/ladvd-1.0.4/src'
make[2]: *** [master.lo] Error 1
make[2]: *** [util.lo] Error 1
make[1]: *** [all] Error 2
make[1]: Leaving directory `/builddir/build/BUILD/ladvd-1.0.4/src'
make: *** [all-recursive] Error 1
#v-

-- 
Tomasz Torcz   RIP is irrevelant. Spoofing is futile.
xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Unblocking packages: new review needed?

[Alec Leamas]

On 2012-11-07 15:47, tim.laurid...@gmail.com wrote:
Sound very strange, it is not some kind orphan package, there have 
been out of Fedora and has to re-enter.
It it an active maintained package in F17, there just have not worked 
with latest version for gnome-shell, because they change the way 
themes works in every release.

It a waste of reviewers time to have to review such a package again IMHO.

Tim


On Wed, Nov 7, 2012 at 2:57 PM, M.M. > wrote:


I have requested Release Engineering to unblock some packages,
which previously had been blocked on some branches:
https://fedorahosted.org/rel-eng/ticket/5387
I have been told that those packages must be reviewed again in
order to be unblocked.
I'm not 100% sure of what to do. Do I have to open a new review
request on Bugzilla for each package "from scratch" (i.e., exactly
as if they were completely new)?
Are there any further steps I must take?
Thank you in advance.
M.M.

--
devel mailing list
devel@lists.fedoraproject.org 
https://admin.fedoraproject.org/mailman/listinfo/devel





No top-posting in fedora-devel :)

Besides that, I can just agree with Tim. The oldest package was reviewed 
less than a year ago, the two others last summer. Requiring a new review 
is, well, somewhat formal.


That said, it should be easy to review these to resolve this issue. If 
you just make some new review requests, linking to the previous review 
I'll guess this could be handled without to much problems.


--alec
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Revamping the non responsive maintainer process

[Björn Persson]

Vít Ondruch wrote:
> Come on, there are the same alarmist who think that Wikipedia will be
> hijacked and destroyed but have it happened any time?

Edit wars often break out on Wikipedia. That's not something I would 
like to see in Fedora.
http://en.wikipedia.org/wiki/Wikipedia:Lamest_edit_wars

Also, mistakes on Wikipedia are unlikely to cause widespread breakage of 
users' work environments or insert backdoors into lots of computers all 
over the world.

Björn Persson

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: New release cycle proposal (was Rolling release model philosophy (was ...))

[Reindl Harald]

Am 06.11.2012 19:48, schrieb Peter Lemenkov:
> Hello All.
> 
> 2012/11/6 Matthieu Gautier :
>> For example, if we start from Fedora20 at beginning of 2014:
>> - Fedora20(jan 2014) is a stable release. (Fedora18 eol, actual way of
>> doing)
>> - Fedora21Preview(jul 2014) is an "unstable" release. (Fedora 19 eol)
>> - Fedora21(jan 2015) is a stable release. (Fedora21Preview eol, new way
>> of doing)
>> - Fedora22Preview(jul 2015)
>> - Fedora22(jan 2016) (Fedora22Preview and Fedora20 eol)
>> - Fedora23Preview(jul 2016)
>> - Fedora23(jan 2017) (Fedora23Preview and Fedora21 eol)
> 
> So you not a maintainer but you still suggesting that we, maintainers,
> should do 2 times more job by supporting several simultaneous Fedora
> versions instead of 3 right now for more than two years. And that's
> all just because you think it's a good idea to spend my personal time
> on the rreleases I'm not using anymore

it would be enough to push LARGE changes like UsrMove / systemd / grub2
only every SECOND release as we current have and the following release
should bring only smaller changes and PLOISH the features of the last
release

this way you would even have LESS work and pressure and the distribution
would become more stable and bugfree at all becasue currently sometimes
people do simply now know where to start and how to finish because the
next BIG change is starting and a half year is very short



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Anything changed on rawhide builders recently? Can't build ladvd

[Josh Boyer]

On Wed, Nov 7, 2012 at 10:05 AM, Tomasz Torcz  wrote:
> Hi,
>
>   Today I tried to build ladvd 1.0.4 package for rawhide, but it failed with
> some strange message 
> http://koji.fedoraproject.org/koji/getfile?taskID=4662562&name=build.log&offset=-4000
>  ,
> which is pasted below.  So I rolled back to 1.0.2 and it failed to build, too.
> It was building fine previously.
>   Then I tried to build for F18, it was built succesfuly (although it 
> packaging ultimately
> failed because of unrelated reason).
>
>   So the question is: what's broken with rawhide builders?

The kernel-headers package is newer and includes the UAPI split done by
David Howells.

>   The message on rawhide builder is:
> #v+
> libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -Wall -Werror -Wformat 
> -Wformat-security -D_FORTIFY_SOURCE=2 -fno-delete-null-pointer-checks 
> -fstack-protector -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
> -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom 
> -fasynchronous-unwind-tables -c child.c  -fPIC -DPIC -o .libs/child.o
> In file included from cli.c:20:0:
> common.h:152:8: error: redefinition of 'struct sysinfo'
> In file included from /usr/include/linux/kernel.h:4:0,
>  from /usr/include/linux/sysctl.h:25,
>  from /usr/include/sys/sysctl.h:43,
>  from common.h:50,
>  from cli.c:20:
> /usr/include/linux/sysinfo.h:7:8: note: originally defined here
> make[2]: *** [cli.lo] Error 1

So it seems ladvd has carried a redefinition of struct sysinfo basically
forever.  They could have very well named it ladvd_sysinfo or something
and that might work as a temporary patch, but I think there is a bigger
issue going on here.

It seems that /usr/include/sys/sysctl.h has been doing a bit of ifdefery
to prevent inclusion of certain header files from the kernel.  That
header file is provided by glibc.  In it, you can see things like:

#include 
/* Prevent more kernel headers than necessary to be included.  */
#ifndef _LINUX_KERNEL_H
# define _LINUX_KERNEL_H1
# define __undef_LINUX_KERNEL_H
#endif

...

#include 

#ifdef __undef_LINUX_KERNEL_H
# undef _LINUX_KERNEL_H
# undef __undef_LINUX_KERNEL_H
#endif

That works with kernel-headers from <= the 3.6 kernel, but the UAPI
rework has redefined the header guards for a number of files, including
.  That file is now specifically guarded by:

#ifndef _UAPI_LINUX_KERNEL_H
#define _UAPI_LINUX_KERNEL_H

which means the tests glibc is doing above are failing.

David, any thoughts on what the general solution to that would be?

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Unblocking packages: new review needed?

[tim.laurid...@gmail.com]

On Wed, Nov 7, 2012 at 10:07 AM, Alec Leamas  wrote:

> No top-posting in fedora-devel :)
>
>
Sorry :)


> Besides that, I can just agree with Tim. The oldest package was reviewed
> less than a year ago, the two others last summer. Requiring a new review
> is, well, somewhat formal.
>
> That said, it should be easy to review these to resolve this issue.  If
> you just make some new review requests, linking to the previous review I'll
> guess this could be handled without to much problems.
>

I don't see anywhere in http://fedoraproject.org/wiki/Package_Review_Process

That a new review is needed,

"Reviews are currently done for totally new packages, package
renames,
and packages merged from the old Fedora Core repository."

I don't see this case, fits any of the cases.

Tim
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[Jesse Keating]

On 11/07/2012 01:02 AM, Vít Ondruch wrote:

Dne 7.11.2012 08:08, Dan Horák napsal(a):

Jesse Keating píše v Út 06. 11. 2012 v 10:48 -0800:

On 11/06/2012 03:35 AM, Vít Ondruch wrote:

And rel-engs actively prohibits staging as much as they can  [1], where
it should be encouraged IMO.

Vit


[1] https://fedorahosted.org/rel-eng/ticket/4580


Additional tags have a high cost to the infrastructure and every user of
said infrastructure.  It creates more newRepo tasks which take
significant time to complete, and since they are resource intensive only
a few can be done at once.  This means that newRepo tasks get delayed
farther and people waiting for buildroot updates have to wait longer,
and longer, and longer.  This is why extra tags/roots are used sparingly
for more intensive updates than what you're requesting here.

but there is a solution - learn koji use multiple repos, in cases like
this one you will have one repo that is tied to fX tag (large, but
changed only when "fedora" changes) and another to the side tag (this
will be very small one, can be changed more often), koji will then
generate a mock config with 2 repos and you are done


Dan



In combination with
https://admin.fedoraproject.org/pkgdb/acls/name/createrepo_c it would be
outstanding.


Vit


If the solution was so simple, don't you think it would have been solved 
long ago?  The majority of time isn't spent in the createrepo task, it's 
in the database queries to figure out through inheritance what all 
builds should be in that createrepo run.  That's what puts stress on the 
entire system.


--
Help me fight child abuse: http://tinyurl.com/jlkcourage

- jlk
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Unblocking packages: new review needed?

[Alec Leamas]

On 2012-11-07 16:53, tim.laurid...@gmail.com wrote:



On Wed, Nov 7, 2012 at 10:07 AM, Alec Leamas > wrote:


No top-posting in fedora-devel :)


Sorry :)

Besides that, I can just agree with Tim. The oldest package was
reviewed less than a year ago, the two others last summer.
Requiring a new review is, well, somewhat formal.

That said, it should be easy to review these to resolve this
issue.  If you just make some new review requests, linking to the
previous review I'll guess this could be handled without to much
problems.


I don't see anywhere in 
http://fedoraproject.org/wiki/Package_Review_Process


That a new review is needed,

"Reviews are currently done for totally new packages, package renames 
, 
and packages merged from the old Fedora Core repository."


I don't see this case, fits any of the cases.

Tim



It might be that you are right, dunno, this is just so weird. My point 
is just that three simple reviews might be less work than to discuss 
this until there is a Proper Solution.



--alec
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Unblocking packages: new review needed?

[Kevin Fenzi]

On Wed, 07 Nov 2012 16:59:19 +0100
Alec Leamas  wrote:

> It might be that you are right, dunno, this is just so weird. My
> point is just that three simple reviews might be less work than to
> discuss this until there is a Proper Solution.

The guideline is: 

If the package is "Retired" in pkgdb, in general it needs a re-review.
(Sometimes exceptions are made right after the per cycle mass
retirement for things that were mistakenly retired, etc). 

If it's "Orphaned" you can just take ownership and go on. 

I'll look at fixing the wiki 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Unblocking packages: new review needed?

[Pierre-Yves Chibon]

On Wed, 2012-11-07 at 16:59 +0100, Alec Leamas wrote:
> On 2012-11-07 16:53, tim.laurid...@gmail.com wrote:

> > On Wed, Nov 7, 2012 at 10:07 AM, Alec Leamas  >  
> > Besides that, I can just agree with Tim. The oldest package
> > was reviewed less than a year ago, the two others last
> > summer. Requiring a new review is, well, somewhat formal.
> > 
> > That said, it should be easy to review these to resolve this
> > issue.  If you just make some new review requests, linking
> > to the previous review I'll guess this could be handled
> > without to much problems.

> > I don't see anywhere
> > in http://fedoraproject.org/wiki/Package_Review_Process
> > 
> > That a new review is needed,

> It might be that you are right, dunno, this is just so weird. My point
> is just that three simple reviews might be less work than to discuss
> this until there is a Proper Solution. 

This is what you are looking for:
http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Deprecated_Package

especially:
Deprecated packages require re-review if they are deprecated for more
than two weeks or if there is no previous review of the package. Submit
a review request (a new bugzilla ticket) and have the package approved
by a reviewer as if it were new to Fedora. See the package review
process for more information. 

Pierre
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Schedule for Wednesday's FESCo Meeting (2012-11-07)

[Tomas Mraz]

Following is the list of topics that will be discussed in the FESCo 
meeting Wednesday at 18:00UTC (1:00pm EST) in #fedora-meeting on
irc.freenode.net.

Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #960 F18 schedule + the holidays
.fesco 960
https://fedorahosted.org/fesco/ticket/960

- this will be discussed together with the proposal:
#topic #968 Move F18 release to no more than March 2013
.fesco 968
https://fedorahosted.org/fesco/ticket/968

= New business =

#topic #966 Fedora 19 Schedule proposal (DRAFT!)
.fesco 966
https://fedorahosted.org/fesco/ticket/966

#topic #967 Proposal for automated Fedora packaging cleanup policy.
.fesco 967
https://fedorahosted.org/fesco/ticket/967

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Anything changed on rawhide builders recently? Can't build ladvd

[David Howells]

Tomasz Torcz  wrote:

> In file included from cli.c:20:0:
> common.h:152:8: error: redefinition of 'struct sysinfo'
> In file included from /usr/include/linux/kernel.h:4:0,
>  from /usr/include/linux/sysctl.h:25,
>  from /usr/include/sys/sysctl.h:43,
>  from common.h:50,
>  from cli.c:20:
> /usr/include/linux/sysinfo.h:7:8: note: originally defined here

The attached patch to the kernel should fix this.  The problem is that many of
the userspace API files all got their guards renamed inside of the kernel when
they got split out into separate files (rather than being renamed).

A better way to do this might be to make the header installation discard the
"_UAPI" prefix that got added.

David
---
commit 24d4756373d825c43c5f5c3cf1fc6737943abf53
Author: David Howells 
Date:   Wed Nov 7 16:40:14 2012 +

UAPI: The guards on linux/types.h and linxu/kernel.h are used by glibc

The guards on linux/types.h and linux/kernel.h are used by glibc, and so
shouldn't have been changed for the UAPI variants of those headers.  Change
those guards back and alter the ones on the KAPI variants instead.

Interestingly, sys/sysctl.h shows checks on linux/list.h and 
linux/compiler.h,
even though those headers aren't exported.

Signed-off-by: David Howells 

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index a123b13..e0e6839 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_KERNEL_H
-#define _LINUX_KERNEL_H
+#ifndef _KAPI_LINUX_KERNEL_H
+#define _KAPI_LINUX_KERNEL_H
 
 
 #include 
diff --git a/include/linux/types.h b/include/linux/types.h
index 1cc0e4b..1e99075 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_TYPES_H
-#define _LINUX_TYPES_H
+#ifndef _KAPI_LINUX_TYPES_H
+#define _KAPI_LINUX_TYPES_H
 
 #define __EXPORTED_HEADERS__
 #include 
@@ -212,4 +212,4 @@ struct callback_head {
 #define rcu_head callback_head
 
 #endif /*  __ASSEMBLY__ */
-#endif /* _LINUX_TYPES_H */
+#endif /* _KAPI_LINUX_TYPES_H */
diff --git a/include/uapi/linux/kernel.h b/include/uapi/linux/kernel.h
index 321e399..642d1e9 100644
--- a/include/uapi/linux/kernel.h
+++ b/include/uapi/linux/kernel.h
@@ -1,5 +1,5 @@
-#ifndef _UAPI_LINUX_KERNEL_H
-#define _UAPI_LINUX_KERNEL_H
+#ifndef _LINUX_KERNEL_H
+#define _LINUX_KERNEL_H
 
 #include 
 
@@ -10,4 +10,4 @@
 #define __ALIGN_KERNEL_MASK(x, mask)   (((x) + (mask)) & ~(mask))
 
 
-#endif /* _UAPI_LINUX_KERNEL_H */
+#endif /* _LINUX_KERNEL_H */
diff --git a/include/uapi/linux/types.h b/include/uapi/linux/types.h
index acf0979..a9b87a8 100644
--- a/include/uapi/linux/types.h
+++ b/include/uapi/linux/types.h
@@ -1,5 +1,5 @@
-#ifndef _UAPI_LINUX_TYPES_H
-#define _UAPI_LINUX_TYPES_H
+#ifndef _LINUX_TYPES_H
+#define _LINUX_TYPES_H
 
 #include 
 
@@ -53,4 +53,4 @@ typedef __u32 __bitwise __wsum;
 #define __aligned_le64 __le64 __attribute__((aligned(8)))
 
 #endif /*  __ASSEMBLY__ */
-#endif /* _UAPI_LINUX_TYPES_H */
+#endif /* _LINUX_TYPES_H */

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Anything changed on rawhide builders recently? Can't build ladvd

[David Howells]

David Howells  wrote:

> A better way to do this might be to make the header installation discard the
> "_UAPI" prefix that got added.

As the attached patch.

David
---
commit 75a88e14a97d239a47cbd0fc55fc23416007d733
Author: David Howells 
Date:   Wed Nov 7 17:14:14 2012 +

UAPI: Strip the _UAPI prefix from header guards during header installation

Strip the _UAPI prefix from header guards during header installation so that
any userspace dependencies aren't affected.  glibc, for example, checks for
linux/types.h, linux/kernel.h, linux/compiler.h and linux/list.h - though 
the
last two aren't actually exported.

Signed-off-by: David Howells 

diff --git a/scripts/headers_install.pl b/scripts/headers_install.pl
index 239d22d..6c353ae 100644
--- a/scripts/headers_install.pl
+++ b/scripts/headers_install.pl
@@ -42,6 +42,9 @@ foreach my $filename (@files) {
$line =~ s/(^|\s)(inline)\b/$1__$2__/g;
$line =~ s/(^|\s)(asm)\b(\s|[(]|$)/$1__$2__$3/g;
$line =~ s/(^|\s|[(])(volatile)\b(\s|[(]|$)/$1__$2__$3/g;
+   $line =~ s/#ifndef _UAPI/#ifndef /;
+   $line =~ s/#define _UAPI/#define /;
+   $line =~ s!#endif /[*] _UAPI!#endif /* !;
printf {$out} "%s", $line;
}
close $out;
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[Bill Nottingham]

Sandro Mani (manisan...@gmail.com) said: 
> >- It's been suggested before, but could we practically keep N and N-1
> >   packages in rawhide repos? Then 'yum downgrade' becomes much more
> >   handy. Repodata size and mirror size might shoot that down though.

The compose process currently can pull either the latest package, or
*all* packages in its inheritance. Pulling just one more would be More Code.
(Not saying the code couldn't be written, but it's not a 'simple' fix.)

Also, repo size, repodata size, etc. You get the drill.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora ARM weekly status meeting 2012-11-07

[Paul Whalen]

Good day all,

This weeks Fedora ARM status meeting will take place today (Wednesday Nov 7th) 
in #fedora-meeting-1 on Freenode.
Times in various time zones (please let us know if these do not work):

PDT: 1pm
MDT: 2pm
CDT: 3pm
EDT: 4pm
UTC: 8pm
BST: 9pm
CST: 10pm

Current items on the agenda:

1) F18/19 build status - problem packages?

2) F18 Beta Release Criteria

3) selinux - boot issue with kernel-3.6.4-1+ when in enforcing

4) FUDCon Lawrence - who's attending, planning ARM activities

5) Your topic here

If you have any other items you would like to discuss that are not mentioned, 
please feel free to send an email to the list or bring it up at the end of the 
meeting.

Paul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora ARM weekly status meeting 2012-11-07

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/07/2012 01:51 PM, Paul Whalen wrote:
> Good day all,
> 
> This weeks Fedora ARM status meeting will take place today (Wednesday Nov
> 7th) in #fedora-meeting-1 on Freenode. Times in various time zones (please
> let us know if these do not work):
> 
> PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm
> 
> Current items on the agenda:
> 
> 1) F18/19 build status - problem packages?
> 
> 2) F18 Beta Release Criteria
> 
> 3) selinux - boot issue with kernel-3.6.4-1+ when in enforcing
> 
> 4) FUDCon Lawrence - who's attending, planning ARM activities
> 
> 5) Your topic here
> 
> If you have any other items you would like to discuss that are not
> mentioned, please feel free to send an email to the list or bring it up at
> the end of the meeting.
> 
> Paul
> 
What was the SELinux issue?  rpm -q selinux-policy

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCavS8ACgkQrlYvE4MpobPdEQCfZMBUp7d7RK4plOL6w8YvpRnw
g20AoL98naX5s475eHGzNj01yfzbvaSm
=vI05
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[Jaroslav Reznik]

Today at FESCo meeting [1] it was decided to slip Fedora 18
Beta release by *two* weeks to give the Installer team,
the new upgrade tool and Secure Boot time to finish and 
polish these features to meet our release quality standards.

As a result, Fedora 18 Beta will be pushed out by two weeks,
the development is re-opened, with tentative Change Deadline
on Nov 13. Fedora 18 Beta release is now Nov 27. Anyone with
objections to enter Beta freeze on Nov 13 can file a ticket 
with FESCo on the Nov 12/13 and it will be discussed in the 
ticket or on special meeting.

Final Change deadline is rescheduled to Dec 18 with final
Fedora 18 release on 2013 Jan 08 [2].

The Go/No-Go meeting on Thursday, Nov 08 is cancelled.

Please, work on your blocker bugs and help testing the 
Fedora 18, so we will be able to release in the beginning 
of January.

[1] 
http://meetbot.fedoraproject.org/fedora-meeting/2012-11-07/fesco.2012-11-07-18.00.log.html
[2] https://fedoraproject.org/wiki/Releases/18/Schedule

Thanks
Jaroslav
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora ARM weekly status meeting minutes 2012-11-07

[Paul Whalen]

Good day all,

Thanks to those who were able to join us for the weekly status meeting today. 
For those that were unable, the minutes are posted below:

Minutes: 
http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-07/fedora-meeting-1.2012-11-07-21.00.html
Minutes (text): 
http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-07/fedora-meeting-1.2012-11-07-21.00.txt
Log: 
http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-07/fedora-meeting-1.2012-11-07-21.00.log.html

Paul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Review swaps for Audio spin

[Brendan Jones]

Hi all

I have a number of outstanding reviews that we are hoping to inlcude on 
the audio spin media. All are fairly trivial so shouldn't take too much 
time.


giada - an audio looper for jack
https://bugzilla.redhat.com/show_bug.cgi?id=866156

python-mididings - a MIDI router and processor in python/python3
https://bugzilla.redhat.com/show_bug.cgi?id=866183

drumkv1 - an LV2 / standalone sampler
https://bugzilla.redhat.com/show_bug.cgi?id=870184

thanks

Brendan


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[Dodji Seketeli]

"Nicolas Mailhot"  a écrit:

> Le Lun 5 novembre 2012 10:45, Dodji Seketeli a écrit :
>
>> Just having a dedicated Rawhide Swat Team of die hard volunteers who
>> could spot issues early, file more bugs, gently push for fixes in
>> Rawhide and last but not least build a kind of "esprit de corps" among
>> those who suffer Rawhide breakages for the greater good would be a great
>> start, IMHO.
>
> There is already a pool of rawhide users.

I know, I am one those.  And I feel alone.  Us poor Rawhide users could
"Unite", communicate, heck, commiserate!  At least on a psychological
standpoint, that'd be a progress, IMHO.

> Rawhide bugs are already reported.

I haven't said that no Rawhide bugs were reported.


You know what, I got some Rawhide bugs fixed by maintainers who don't
seem to be running Rawhide themselves.  And I find that a good step
already.  Just having a little bit more of that could be "nice".

I see this Fedora business as a best-effort, love-ridden task.  I don't
think the kind of problem we are talking about can be solved by a
magical formula; so I am inclined to accept any improvement, even tiny
little ones.  :-)

> The problem is not here,

I respectfully disagree.  A part of the problem could be addressed by
having a more organized and visible group of Rawhiders who can help each
other, grow the group by inspiring more Fedora Hackers to join, help
follow the status of particular bugs that are filled, etc ...

> the problem is maintainers that deliberately
> ignore bugs with rawhide in them (usual excuse and motto are "Rawhide eats
> babies", "I'll test when Rawhide is more stable", no empathy for other
> maintainers that can not test because your problem is breaking their test
> process).

I obviously agree with you that this is a problem.  Of course.  One
could say that the root cause of the problem is that these maintainers
don't have enough time to advance both their short term agendas (hack on
the features they are aiming for), and the medium to long term agenda of
the Greater Community.  We can argue about this endlessly.  And we can
also start getting those who are already Rawhiders to unite, try to help
themselves and promote their view as something good for the general
interest of our community at large.

> All the systemd problems were reported in Rawhide way before they hit
> branched. If they did hit branched it's not because reporting was lacking,
> but because there was a lack of social pressure not to let Rawhide rot
> (with easily predictable consequences).

I don't know if *all* of systemd problems were reported, and am not
going to argue about it.  But I know that the systemd issues that
temporarily prevented me to boot Rawhide at some point got resolved
(indirectly at least) in Rawhide.

I think there is room to be optimistic without requiring every single
Fedora developer to run Rawhide.  If at some point we could have one
developer per group working on critical packages (e.g, one developer of
the kernel group, one of GNOME, one for base os stuff, one for the virt
subsystem, etc) to be in the Rawhide Swat Team, it would be just
*great*.  Of course, those of us who want to run Rawhide w/o hacking on
critical packages are welcome too, and they can be hugely helpful.

And I like to believe that we could achieve that by mean of love.  :)

Cheers.

-- 
Dodji
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[Dodji Seketeli]

Kevin Fenzi  a écrit:

> On Mon, 05 Nov 2012 10:45:00 +0100
> Dodji Seketeli  wrote:
>
> ...snip...
>
>> Could we have a rawhide-list for this?  I know fighting proliferation
>> of mailing list is a good thing, but practically speaking, being able
>> to quickly scan a mailing list before doing a yum update can help a
>> Rawhider evaluate in advance the odds of his risking to be unable to
>> reboot his machine or not.  :-)
>
> I thought about that, but I don't think another list is something do so
> lightly. How about rawhide folks add a [rawhide] to their email
> subjects here to make them easy to filter out/see. 

Right.  That would work for me too.

> I'd personally love to see more signal here in this list. 

Go Rawhiders!  :)

-- 
Dodji
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: small tip regarding git branch bash prompt in F18/Rawhide

[Adam Williamson]

On Wed, 2012-08-22 at 16:12 -0700, Adam Williamson wrote:
> Hey folks - just in case you haven't all figured this out yet, if 
> you're using the neat little trick of putting a few lines in your 
> ~/.bashrc so that when you're in a directory containing a git repo, the 
> prompt will display what branch you're in, it'll stop working when you 
> update to the latest git - 1.7.12 - in F18 or Rawhide. To fix it, you 
> need to change:
> 
> source /etc/bash_completion.d/git
> 
> to:
> 
> source /usr/share/doc/git-1.7.12/contrib/completion/git-prompt.sh
> 
> because upstream split the prompt stuff out from the bash_completion 
> script. Perhaps the git packagers could consider providing git-prompt.sh 
> in a more permanent location, so we don't have to poke .bashrc every 
> time the git version changes? Thanks!

Heads up, everyone, it got moved again (from the last location
in /etc/profile.d). Stay sharp at all times! Look both ways before
crossing the street!

Now you have to do:

source /usr/share/git-core/contrib/completion/git-prompt.sh
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

headsup: ghc-7.4.2 and haskell-platform-2012.4 coming soon to rawhide

[Jens Petersen]

Hi,

The Haskell SIG will soon be updating ghc to 7.4.2 and the just released
haskell-platform-2012.4.0.0.  At the same time there will be a big bunch
of pending version updates for various Haskell packages.  As usual this
will require rebuilding all the packages.

Apart from bugfixes, a nice feature of ghc-7.4.2 is ARM support for ghci
and hence template-haskell - apart from shared-library support
this will almost bring ARM ghc up to Tier 1 level support.

The plan is to backport haskell-platform-2012.4 later to Fedora 18 updates,
and maybe also haskell-platform-2012.2 to Fedora 17.  Of course these
would be done in separate Koji tags.

Jens
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[Bojan Smojver]

Jaroslav Reznik  redhat.com> writes:

> Final Change deadline is rescheduled to Dec 18 with final
> Fedora 18 release on 2013 Jan 08 [2].

I know everyone is going to hate me for saying this, but wouldn't it make sense
to just forget about F-18 and go for F-19 instead? After all, F-19 feature
submission deadline will probably be only a few weeks after F-18 release (as it
stands now, unless it slips again).

--
Bojan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[ニール・ゴンパ]

Oh my goodness. This is the highest amount of slippage I've seen in quite
some time. What is wrong with Fedora? The slippage is getting worse each
and every single release. I love Fedora and all, but this is absolutely
ridiculous...


On Wed, Nov 7, 2012 at 7:52 PM, Bojan Smojver  wrote:

> Jaroslav Reznik  redhat.com> writes:
>
> > Final Change deadline is rescheduled to Dec 18 with final
> > Fedora 18 release on 2013 Jan 08 [2].
>
> I know everyone is going to hate me for saying this, but wouldn't it make
> sense
> to just forget about F-18 and go for F-19 instead? After all, F-19 feature
> submission deadline will probably be only a few weeks after F-18 release
> (as it
> stands now, unless it slips again).
>
> --
> Bojan
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[The Quen]

I dont think anything is "wrong" with Fedora, but I do think we need to have 
reasonable expectations for systems that are put together with lots of moving 
parts.
Delays are not rediculous, they are just the nature of complex systems.

Nobody is forcing anyone to hurt furry animals while the release is getting 
together. Its a little sad and dissapointing, but thats about it.

I'm happy the QA team has enough sway to ensure that a release is sweet, and 
not rough-edged.
I think people remember the rough edges way longer than the 'it just worked' 
stuff.
:)


On 8/11/12 12:37 PM, Conan Kudo (ニール・ゴンパ) wrote:
> Oh my goodness. This is the highest amount of slippage I've seen in quite 
> some time. What is wrong with Fedora? The slippage is getting worse each and 
> every single release. I love Fedora and all, but this is absolutely 
> ridiculous...
>
>
> On Wed, Nov 7, 2012 at 7:52 PM, Bojan Smojver  > wrote:
>
> Jaroslav Reznik  redhat.com > writes:
>
> > Final Change deadline is rescheduled to Dec 18 with final
> > Fedora 18 release on 2013 Jan 08 [2].
>
> I know everyone is going to hate me for saying this, but wouldn't it make 
> sense
> to just forget about F-18 and go for F-19 instead? After all, F-19 feature
> submission deadline will probably be only a few weeks after F-18 release 
> (as it
> stands now, unless it slips again).
>
> --
> Bojan
>
> --
> devel mailing list
> devel@lists.fedoraproject.org 
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
>
>
>

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[Adam Williamson]

On Wed, 2012-11-07 at 21:07 -0600, Conan Kudo (ニール・ゴンパ) wrote:
> Oh my goodness. This is the highest amount of slippage I've seen in
> quite some time. What is wrong with Fedora? 

The new anaconda UI and related features are more or less entirely the
cause of the slip. Secure boot support is also not done yet (waiting on
the signature for shim to get sorted out by legal), though I don't know
whether FESCo yet absolutely decided that has to be in for Beta.

> The slippage is getting worse each and every single release. I love
> Fedora and all, but this is absolutely ridiculous...

It isn't, if you look at the facts, the slips for the last few releases
have been fairly similar and there's no pattern of them getting longer.
This release is special because of the major anaconda change, which it's
turning out after the fact could have been organized better (hindsight
is 20/20).

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Attention, dependency fighters

[Adam Williamson]

In case anyone noticed minimal install got rather bigger between Alpha
and Beta - I did too. And I finally got around to figuring out why and
filing a bug:

https://bugzilla.redhat.com/show_bug.cgi?id=874378

long story short, it's firewalld. Its deps are pretty heavy for
something that's supposed to be in minimal. I'm sure twoerner would
welcome help in pruning the deps if it's possible. it should at least be
possible for it not to depend on both pygobject2 and pygobject3, one
would think :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Attention, dependency fighters

[Matthew Miller]

On Wed, Nov 07, 2012 at 07:56:30PM -0800, Adam Williamson wrote:
> long story short, it's firewalld. Its deps are pretty heavy for
> something that's supposed to be in minimal. I'm sure twoerner would
> welcome help in pruning the deps if it's possible. it should at least be
> possible for it not to depend on both pygobject2 and pygobject3, one
> would think :)


Maybe we could have a release criterion which states that the minimal
install doesn't have anything which pulls in the X libraries (or Wayland)?

That's not a _completely_ arbitrary line in the sand. Probably the issue
here is just a matter of what goes in what subpackage.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: "network" service fails to set wireless parameters.

[Dan Williams]

On Tue, 2012-11-06 at 23:16 +0100, Björn Persson wrote:
> Dan Williams wrote:
> > On Tue, 2012-11-06 at 21:47 +0100, Björn Persson wrote:
> > > I have a Wifi card that is supposed to be managed by the "network"
> > > service. The interface's IP addresses, prefixes, routes and all that
> > > get assigned correctly on boot, but the wireless parameters – mode,
> > > ESSID and channel – do not get assigned. I have to set those
> > > manually with the iwconfig command.
> > > 
> > > I've had this card working before, but I've hacked the ifcfg file
> > > since then. (I've had lots of networking problems since I installed
> > > Fedora 17, so I've been editing the configuration a lot.) It's
> > > possible that I've missed something, so before I file a bug report
> > > I wanted to ask: Does anyone see anything wrong with the ifcfg file
> > > below?
> > 
> > Is NetworkManager enabled?  Run "systemctl status
> > NetworkManager.service" to find out; it looks like this connection is
> > supposed to be managed by NetworkManager.
> 
> Network Manager is enabled and running, but it manages only one of my 
> three physical interfaces. I tried letting it manage this one, but then 
> the interface sometimes got its address on boot, and sometimes not. 
> Apparently there was some race condition. After I set NM_CONTROLLED=no 
> it behaves consistently, only the wireless parameters don't get set.

Could be because your wifi adapter is a recent one, and thus uses the
preferred upstream nl80211 kernel configuration API.  The iwconfig tool,
which is what the initscripts (and thus the old network service) use,
speaks the WEXT kernel configuration API which doesn't work well for
newer devices.  Things are getting moved to nl80211.  In addition, the
wext api of "operation 1, then operation 2, then operation 3" simply
doesn't work well for newer devices, and never worked very well for old
ones, and it's possible that the driver for your wifi device doesn't
like the sequence that the initscripts use.  Which is why WEXT was a bad
API in the first place.  Using wpa_supplicant is the preferred mechanism
for controlling wifi devices these days.

That all said, I'm curious why NM isn't reliable in your case.  Logging
from /var/log/messages usually elucidates any problems.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[Gilboa Davara]

On Thu, Nov 8, 2012 at 5:55 AM, Adam Williamson  wrote:
>
> On Wed, 2012-11-07 at 21:07 -0600, Conan Kudo (ニール・ゴンパ) wrote:
> > Oh my goodness. This is the highest amount of slippage I've seen in
> > quite some time. What is wrong with Fedora?
>
> The new anaconda UI and related features are more or less entirely the
> cause of the slip. Secure boot support is also not done yet (waiting on
> the signature for shim to get sorted out by legal), though I don't know
> whether FESCo yet absolutely decided that has to be in for Beta.
>
> > The slippage is getting worse each and every single release. I love
> > Fedora and all, but this is absolutely ridiculous...
>
> It isn't, if you look at the facts, the slips for the last few releases
> have been fairly similar and there's no pattern of them getting longer.
> This release is special because of the major anaconda change, which it's
> turning out after the fact could have been organized better (hindsight
> is 20/20).
>

Has anyone (FESCo) considered pushing Anaconda rewrite to F19 and ship
F18 w/ the old Anaconda?
I just tried the latest TC and while Anaconda did give me a working
F18 installation, the experience is still rather raw (Can't say the I
met major bugs, though).

... With all the testing resources pushing toward Anaconda, its very
likely that breakage in (many) other components may go unnoticed.

- Gilboa
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[Kevin Kofler]

Conan Kudo (ニール・ゴンパ) wrote:
> Oh my goodness. This is the highest amount of slippage I've seen in quite
> some time. What is wrong with Fedora? The slippage is getting worse each
> and every single release. I love Fedora and all, but this is absolutely
> ridiculous...

One factor is that QA has become stricter (and testing has improved). E.g., 
in the past, the KDE spin didn't even have to work at all! The criteria for 
the GNOME ("Desktop") spin have also become much tighter. Of course 
delivering something that actually works takes time. I don't believe going 
back to just shipping what's there on release day even if it has major 
defects is a good idea.

Another factor is that the Anaconda developers are doing more and more risky 
changes, we had the storage rewrite recently, and now in F18 there's the UI 
rewrite (which also touches the storage code yet again, along with much 
other backend code, it's not a UI-only change).

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[Kevin Kofler]

Adam Williamson wrote:
> The new anaconda UI and related features are more or less entirely the
> cause of the slip.

This shows that those changes should not have been done, or at least not in 
this way.

> Secure boot support is also not done yet (waiting on the signature for
> shim to get sorted out by legal), though I don't know whether FESCo yet
> absolutely decided that has to be in for Beta.

And Restricted Boot support just needs to go away!

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Review Swap: ownCloud Server

[Kevin Kofler]

Kevin Fenzi wrote:
> Note that there is negative time to achieve this f18 feature, that has
> moved to target f19. ;)

IMHO, given how this is a new package which isn't going to break anything 
else, this is a perfect candidate for a late feature exception.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Review Swap: ownCloud Server

[Matthew Miller]

On Thu, Nov 08, 2012 at 06:50:02AM +0100, Kevin Kofler wrote:
> > Note that there is negative time to achieve this f18 feature, that has
> > moved to target f19. ;)
> IMHO, given how this is a new package which isn't going to break anything 
> else, this is a perfect candidate for a late feature exception.

And given the extra time with the newly-slipped schedule, it could even be
tested reasonably well before release.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[Matthew Garrett]

On Thu, Nov 08, 2012 at 06:31:20AM +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > The new anaconda UI and related features are more or less entirely the
> > cause of the slip.
> 
> This shows that those changes should not have been done, or at least not in 
> this way.

It turns out that software development is hard. It's especially hard 
when you have a hugely complicated system with no central management and 
no real incentive for most of the skilled workers to cooperate on 
sections of the project that influence each other. It's nigh-near 
impossible when you have the same set of people tasked to simultaneously 
stabalise an upcoming release and do the development work for the 
forthcoming release. The miracle isn't that Anaconda is taking longer 
than desirable. It's that it's as close to finished as it is.

> > Secure boot support is also not done yet (waiting on the signature for
> > shim to get sorted out by legal), though I don't know whether FESCo yet
> > absolutely decided that has to be in for Beta.
> 
> And Restricted Boot support just needs to go away!

Sure, who wants new computers.
-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[M. Edward (Ed) Borasky]

I've now done half a dozen F18 multi-boot installs and I must say it's
a miracle I haven't over-written something I wanted to keep. The thing
that would make it usable for me would be very simple - just put the
partition names on the labeling so I know what's going to end up
where! The rest of the installer is fine but the partitioner needs
either a user interface redesign or extensive documentation.

On Wed, Nov 7, 2012 at 9:31 PM, Kevin Kofler  wrote:
> Adam Williamson wrote:
>> The new anaconda UI and related features are more or less entirely the
>> cause of the slip.
>
> This shows that those changes should not have been done, or at least not in
> this way.
>
>> Secure boot support is also not done yet (waiting on the signature for
>> shim to get sorted out by legal), though I don't know whether FESCo yet
>> absolutely decided that has to be in for Beta.
>
> And Restricted Boot support just needs to go away!
>
> Kevin Kofler
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel



-- 
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: 
http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/

How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[Adam Williamson]

On Thu, 2012-11-08 at 07:04 +0200, Gilboa Davara wrote:
> On Thu, Nov 8, 2012 at 5:55 AM, Adam Williamson  wrote:
> >
> > On Wed, 2012-11-07 at 21:07 -0600, Conan Kudo (ニール・ゴンパ) wrote:
> > > Oh my goodness. This is the highest amount of slippage I've seen in
> > > quite some time. What is wrong with Fedora?
> >
> > The new anaconda UI and related features are more or less entirely the
> > cause of the slip. Secure boot support is also not done yet (waiting on
> > the signature for shim to get sorted out by legal), though I don't know
> > whether FESCo yet absolutely decided that has to be in for Beta.
> >
> > > The slippage is getting worse each and every single release. I love
> > > Fedora and all, but this is absolutely ridiculous...
> >
> > It isn't, if you look at the facts, the slips for the last few releases
> > have been fairly similar and there's no pattern of them getting longer.
> > This release is special because of the major anaconda change, which it's
> > turning out after the fact could have been organized better (hindsight
> > is 20/20).
> >
> 
> Has anyone (FESCo) considered pushing Anaconda rewrite to F19 and ship
> F18 w/ the old Anaconda?

Yes. Several times. The last one just last week. We probably don't need
to go over that again.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[Adam Williamson]

On Thu, 2012-11-08 at 06:31 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > The new anaconda UI and related features are more or less entirely the
> > cause of the slip.
> 
> This shows that those changes should not have been done, or at least not in 
> this way.

I think it's widely agreed by now that they could have been done better,
the question is now exactly how we can improve the process.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[Peter Robinson]

On 8 Nov 2012 07:30, "Kevin Kofler"  wrote:
>
> Conan Kudo (ニール・ゴンパ) wrote:
> > Oh my goodness. This is the highest amount of slippage I've seen in
quite
> > some time. What is wrong with Fedora? The slippage is getting worse each
> > and every single release. I love Fedora and all, but this is absolutely
> > ridiculous...
>
> One factor is that QA has become stricter (and testing has improved).
E.g.,
> in the past, the KDE spin didn't even have to work at all! The criteria
for
> the GNOME ("Desktop") spin have also become much tighter. Of course
> delivering something that actually works takes time. I don't believe going
> back to just shipping what's there on release day even if it has major
> defects is a good idea.
>
> Another factor is that the Anaconda developers are doing more and more
risky
> changes, we had the storage rewrite recently, and now in F18 there's the
UI
> rewrite (which also touches the storage code yet again, along with much
> other backend code, it's not a UI-only change).

The storage rewrite happened back in the f12/13 timeframe. Hardly recent.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[Peter Robinson]

On 8 Nov 2012 07:35, "Kevin Kofler"  wrote:
>
> Adam Williamson wrote:
> > The new anaconda UI and related features are more or less entirely the
> > cause of the slip.
>
> This shows that those changes should not have been done, or at least not
in
> this way.

Hindsight is a fabulous thing, I suspect the anaconda developers would
agree with you looking back. Its a large body of code dependent on a lots
of pieces.

> > Secure boot support is also not done yet (waiting on the signature for
> > shim to get sorted out by legal), though I don't know whether FESCo yet
> > absolutely decided that has to be in for Beta.
>
> And Restricted Boot support just needs to go away!

And with it will go Fedora's ability to support a lot of new hardware
moving forward and I don't believe that's good for anyone. The developers
have done a lot of work to make it easily handle a vast amount of use cases
and I think its great the work they've done. The hardware is coming so its
pointless for us to stick our heads in the sand.

Besides this thread is a about beta slip. Not pros and cons of already
approved feature.

Peter

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel