Broken deps in the stable release are not acceptable

[Christoph Wickert]

Raleigh, we have a problem...

python-gammu, which is required by wammu, prevents users from updating
to the latest gammu release for several days now. It has already been
reported in Bugzilla, see
https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even more
interesting -
https://bugzilla.redhat.com/show_bug.cgi?id=425831

This leads me to some questions:

     1. Why is # 425831 still in status "New"? It has been reported on
        Dec 16th and the maintainer already responded to it.
     2. What's so difficult to coordinate 2 (3 with wammu) dependent
        packages? All are owned by the same packager. IMO this should be
        done in one single update in bodhi.
     3. Do we need better training  for our maintainers or more
        documentation in the wiki? The broken deps already appeared in
        EPEL before they were in F8, so the maintainer should have known
        that he's breaking something when he did the gammu update in
        Fedora. 
     4. When was the testing done? gammu-1.17.0-1.fc8 was built on Dec.
        22 11:22:28 MST [1] and hit the updates repo on Dec. 23 22:50:08
        [2]. This is less than 36 hours for testing.
     5. Why has gammu been pushed directly to updates and not to
        updates-testing? According to the changelog it was not a
        security update.

Note that I don't want to blame a single person here. I think this is
just an example that we really NEED to think about how to avoid such
situations in the future? I know there are people on vacation these
days, but there are enough people that offered help. Unfortunately they
are not allowed to by the ACLs.

Any thoughts?
Christoph

[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=28966
[2] https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4743

[Seth Vidal]

On Fri, 2007-12-28 at 19:19 +0100, Christoph Wickert wrote:
>  Raleigh, we have a problem...
>  
>  python-gammu, which is required by wammu, prevents users from updating
>  to the latest gammu release for several days now. It has already been
>  reported in Bugzilla, see
>  https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even more
>  interesting -
>  https://bugzilla.redhat.com/show_bug.cgi?id=425831
>  
>  This leads me to some questions:
>  
>       1. Why is # 425831 still in status "New"? It has been reported on
>          Dec 16th and the maintainer already responded to it. 
It's the holidays and people are doing non-fedora things?

I mean it's from dec 16th to the 28th. It's 12 days, I grant you, but if
the person(s) is(are) in college then there's a good chance they may be
away from their normal work habits or network connections.

-sv

[Christoph Wickert]

Am Freitag, den 28.12.2007, 14:07 -0500 schrieb seth vidal:
>  On Fri, 2007-12-28 at 19:19 +0100, Christoph Wickert wrote:
>  > Raleigh, we have a problem...
>  > 
>  > python-gammu, which is required by wammu, prevents users from updating
>  > to the latest gammu release for several days now. It has already been
>  > reported in Bugzilla, see
>  > https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even more
>  > interesting -
>  > https://bugzilla.redhat.com/show_bug.cgi?id=425831
>  > 
>  > This leads me to some questions:
>  > 
>  >      1. Why is # 425831 still in status "New"? It has been reported on
>  >         Dec 16th and the maintainer already responded to it.
>  
>  It's the holidays and people are doing non-fedora things?
>  
>  I mean it's from dec 16th to the 28th. It's 12 days, I grant you, but if
>  the person(s) is(are) in college then there's a good chance they may be
>  away from their normal work habits or network connections. 
That's why I wrote "I know there are people on vacation these days", but
IMO a packager should change a bug's status to assigned if he knows
about the problem and he promised to fix it.

If someone is 'offline' for a while, other people should be allowed to
touch his packages.
>  
>  -sv 
Christoph

[Xavier Lamien]

2007/12/28, Christoph Wickert <christoph.wickert(a)nurfuerspam.de&gt;:
>  Raleigh, we have a problem...
>
>  python-gammu, which is required by wammu, prevents users from updating
>  to the latest gammu release for several days now. It has already been
>  reported in Bugzilla, see
>  https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even more
>  interesting -
>  https://bugzilla.redhat.com/show_bug.cgi?id=425831 


I fallen on an broken deps on kernel-xen-devel during the update of my F-8
release, why don't talk about too ?
Its not the first time we have this kind of trouble.

I Agree this should not happen but, ask first why there is a broken deps on
some packages and why this happen.

This leads me to some questions:
>       1. Why is # 425831 still in status "New"? It has been reported on
>          Dec 16th and the maintainer already responded to it.
>       2. What's so difficult to coordinate 2 (3 with wammu) dependent
>          packages? All are owned by the same packager. IMO this should be
>          done in one single update in bodhi. 

It's not difficult, it's not my first update of gammu collection/dependence
package, and it's not the first time a upadte depended  release.

     3. Do we need better training  for our maintainers or more
>          documentation in the wiki? The broken deps already appeared
> in
>          EPEL before they were in F8, so the maintainer should have known
>          that he's breaking something when he did the gammu update in
>          Fedora. 

I think we should set up and automate  or web_api to request repo tag for
package we wanted to build against fresh released one
to build other into koji/mock from repo


     4. When was the testing done? gammu-1.17.0-1.fc8 was built on Dec.
>          22 11:22:28 MST [1] and hit the updates repo on Dec. 23
> 22:50:08
>          [2]. This is less than 36 hours for testing. 

For that, we could make a bodhi policy. Cause no rules say all package Must
go to testing-update before move to stable one.


     5. Why has gammu been pushed directly to updates and not to
>          updates-testing? According to the changelog it was not a
>          security update. 

Why does only security update  should go to stable ?

Note that I don't want to blame a single person here. I think this is
>  just an example that we really NEED to think about how to avoid such
>  situations in the future? I know there are people on vacation these
>  days, but there are enough people that offered help. Unfortunately they
>  are not allowed to by the ACLs. 

I'm not here to blame anyone too but this thread should up many time ago.
on differente pacakge that broken yum udpate in the past, not only this one.



Any thoughts?
>  Christoph
>
>  [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=28966
>  [2] https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4743
>
>
>  

-- 
Xavier.t Lamien
--
French Fedora Ambassador
Fedora/EPEL Contributor      | http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB

[Daniel P. Berrange]

On Fri, Dec 28, 2007 at 03:25:13PM -0400, Xavier Lamien wrote:
>  2007/12/28, Christoph Wickert
> <christoph.wickert(a)nurfuerspam.de&gt;:
>  >
>  > Raleigh, we have a problem...
>  >
>  > python-gammu, which is required by wammu, prevents users from updating
>  > to the latest gammu release for several days now. It has already been
>  > reported in Bugzilla, see
>  > https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even more
>  > interesting -
>  > https://bugzilla.redhat.com/show_bug.cgi?id=425831
>  
>  
>  I fallen on an broken deps on kernel-xen-devel during the update of my F-8
>  release, why don't talk about too ?
>  Its not the first time we have this kind of trouble. 
This is the first time I've heard about broken deps with kernel-xen-devel - if
I'd known I would have ensured it got fixed. Please file a BZ if you hit this 
kind of problem because if no one reports it it'll never get fixed.

>  I Agree this should not happen but, ask first why there is a broken
> deps on
>  some packages and why this happen. 
It is no great mystery. People are fallible & make packaging mistakes sometimes. 

The various automated scripts for sanity checking Fedora repos don't always 
catch every broken thing because they too are written by people who are fallible.
People testing new releases are the final sanity check & we rely on them to report
the problems they find in BZ otherwise they lie may undiscovered by the package
maintainer forever...

Dan
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Thorsten Leemhuis]

On 28.12.2007 20:34, Daniel P. Berrange wrote:
>  On Fri, Dec 28, 2007 at 03:25:13PM -0400, Xavier Lamien wrote:
> > 2007/12/28, Christoph Wickert <christoph.wickert(a)nurfuerspam.de&gt;:
> >> Raleigh, we have a problem...
> >>
> >> python-gammu, which is required by wammu, prevents users from updating
> >> to the latest gammu release for several days now. It has already been
> >> reported in Bugzilla, see
> >> https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even more
> >> interesting -
> >> https://bugzilla.redhat.com/show_bug.cgi?id=425831 
Well, the EPEL report (the second one) has not much in common with the
Fedora report. Just coincidence afaics.

> > I Agree this should not happen but, ask first why there is a
> broken deps on
> > some packages and why this happen.
>  It is no great mystery. People are fallible & make packaging mistakes sometimes. 
Agreed, but...

>  The various automated scripts for sanity checking Fedora repos
> don't always 
>  catch every broken thing because they too are written by people who are fallible. 
...there are afaik no scripts that would have detected such a problem,
and that's not good (tm), lead to this specific problem and IMHO should
be fixed. A simple diff between the old and the new provides send to the
gammu owner my mail might have told him "hmm, maybe other packages
depend on that .so file; I should check this with repoquery before I
push this to stable"; that might have helped to solve the problem in time.

The second big problem: why wasn't this reported earlier? Does nobody
use updates-testing? Or did non of the updates-testing users report the
problem? Part of this problem maybe: where is the best place to report
such issue these days: bodhi comment or bug entry in bugzilla?

Cu
knurd

[Kevin Kofler]

Thorsten Leemhuis <fedora <at> leemhuis.info> writes:
>  The second big problem: why wasn't this reported earlier? Does
> nobody
>  use updates-testing? Or did non of the updates-testing users report the
>  problem? 
Because the update never went to testing, it was pushed directly to stable.

        Kevin Kofler

[Christoph Wickert]

Am Freitag, den 28.12.2007, 21:23 +0100 schrieb Thorsten Leemhuis:
>  On 28.12.2007 20:34, Daniel P. Berrange wrote:
>  > On Fri, Dec 28, 2007 at 03:25:13PM -0400, Xavier Lamien wrote:
>  >> 2007/12/28, Christoph Wickert <christoph.wickert(a)nurfuerspam.de&gt;:
>  >>> Raleigh, we have a problem...
>  >>>
>  >>> python-gammu, which is required by wammu, prevents users from updating
>  >>> to the latest gammu release for several days now. It has already been
>  >>> reported in Bugzilla, see
>  >>> https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even more
>  >>> interesting -
>  >>> https://bugzilla.redhat.com/show_bug.cgi?id=425831
>  
>  Well, the EPEL report (the second one) has not much in common with the
>  Fedora report. Just coincidence afaics. 
You are correct, I did not look carefully enough. But IMO it's the same
problem, no matter if it is libGammu.so.1 or libGammu.so.2.

>  >> I Agree this should not happen but, ask first why there is a
> broken deps on
>  >> some packages and why this happen.
>  > It is no great mystery. People are fallible & make packaging mistakes sometimes.
>
>  
>  Agreed, but...
>  
>  > The various automated scripts for sanity checking Fedora repos don't always 
>  > catch every broken thing because they too are written by people who are fallible.
>  
>  ...there are afaik no scripts that would have detected such a problem,
>  and that's not good (tm), lead to this specific problem and IMHO should
>  be fixed. A simple diff between the old and the new provides send to the
>  gammu owner my mail might have told him "hmm, maybe other packages
>  depend on that .so file; I should check this with repoquery before I
>  push this to stable"; that might have helped to solve the problem in time.
>  
>  The second big problem: why wasn't this reported earlier? Does nobody
>  use updates-testing? Or did non of the updates-testing users report the
>  problem? 
As Kevin and me already wrote this update went directly to stable

>  Part of this problem maybe: where is the best place to report
>  such issue these days: bodhi comment or bug entry in bugzilla? 
Not sure what is better, but in this case there has been both: two
comments in bodhi and two comments in the bugzilla bugs.
>  
>  Cu
>  knurd
>   
Christoph

[Kevin Kofler]

Xavier Lamien <laxathom <at> fedoraproject.org> writes:
>  Why does only security update  should go to stable ?  
It's not a hard rule, but normally updates which aren't security fixes or 
critical bugfixes should go to testing first so problems like this one can be 
caught.

        Kevin Kofler

[Christoph Wickert]

Am Freitag, den 28.12.2007, 15:25 -0400 schrieb Xavier Lamien:
>  
>  
>  2007/12/28, Christoph Wickert <christoph.wickert(a)nurfuerspam.de&gt;:
>          Raleigh, we have a problem...
>          
>          python-gammu, which is required by wammu, prevents users from
>          updating
>          to the latest gammu release for several days now. It has
>          already been
>          reported in Bugzilla, see
>          https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even
>          more
>          interesting -
>          https://bugzilla.redhat.com/show_bug.cgi?id=425831
>  
>  
>  I fallen on an broken deps on kernel-xen-devel during the update of my
>  F-8 release, why don't talk about too ? 
Because I never was affected by this one and did not even hear of it
before. IMHO a devel package is not that important as an application.
Most users could simply remove the package without loosing
functionality, this is different with wammu.
BTW: Are you talking about an upgrade from F7 to F8 or about an update
during the release?

>  Its not the first time we have this kind of trouble. 
Yes, and this is the reason why I wrote my mail. We NEED to look for
ways that this CANNOT happen, because it really is a showstopper that
frightens people to use Fedora. At least I have heard people complaining
about this over and over again, for example at fedoraforum.de

>  
>  I Agree this should not happen but, ask first why there is a broken
>  deps on some packages and why this happen. 
I guess most of the time it happens because of a lack of communication
and coordination. But if all packages are owned by the same person this
reason IMO is not valid.
>  
>          This leads me to some questions:
>          
>               1. Why is # 425831 still in status "New"? It has been
>          reported on Dec 16th and the maintainer already responded to
>          it.
>               2. What's so difficult to coordinate 2 (3 with wammu)
>          dependent packages? All are owned by the same packager. IMO
>          this should be done in one single update in bodhi.
>  
>  It's not difficult, it's not my first update of gammu
>  collection/dependence package, and it's not the first time a upadte
>  depended  release. 
Then you should have known what happens... ;)
Once again: I'm not here to blame someone.
>  
>               3. Do we need better training  for our maintainers or
>          more 
>                  documentation in the wiki? The broken deps already
>          appeared in  EPEL before they were in F8, so the maintainer
>          should have known that he's breaking something when he did the
>          gammu update in Fedora.
>  
>  I think we should set up and automate  or web_api to request repo tag
>  for package we wanted to build against fresh released one
>  to build other into koji/mock from repo 
I agree that the current situation is not optimal for the packagers
because the required packages have to be added to buildroot manually by
rel-eng. But AFAIK we do have the possibility of chain-builds now.

>  
>               4. When was the testing done? gammu-1.17.0-1.fc8 was
>          built on Dec. 22 11:22:28 MST [1] and hit the updates repo on
>          Dec. 23 22:50:08 [2]. This is less than 36 hours for testing.
>  
>  For that, we could make a bodhi policy. Cause no rules say all package
>  Must go to testing-update before move to stable one. 
You are right. I thought we already had policy for that but the wiki
says:
"If you feel that community testing is unnecessary for your update, you
can choose to push it straight to the stable fedora-updates repository
instead."

IMO this is wrong, it should only be allowed for security updates.

>  
>               5. Why has gammu been pushed directly to updates and not
>          to
>                  updates-testing? According to the changelog it was not
>          a 
>                  security update.
>  
>  Why does only security update  should go to stable ? 
Because problems like this case most likely would have been realized in
testing before they annoy a large number of users. Pushing updates
directly to stable renders updates-testing useless.

>  
>          Note that I don't want to blame a single person here. I think
>          this is just an example that we really NEED to think about how
>          to avoid such situations in the future? I know there are
>          people on vacation these days, but there are enough people
>          that offered help. Unfortunately they are not allowed to by
>          the ACLs.
>  
>  I'm not here to blame anyone too but this thread should up many time
>  ago. on differente pacakge that broken yum udpate in the past, not
>  only this one. 
Let's not talk about the past, let's talk about how to avoid this in the
future. There are several ways we could try to accomplish this: Some are
more strict policies, others are more technical, but most important I
think we should get rid of the "don't touch other peoples
packages"-attitude. If someone fixed that within one or two days I
wouldn't have written my previous mail.

Christoph
>  
>   
>  
>          Any thoughts?
>          Christoph
>          
>          [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=28966
>          [2]
>          https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4743
>

[Kevin Kofler]

Christoph Wickert <christoph.wickert <at> nurfuerspam.de> writes:
>  You are right. I thought we already had policy for that but the wiki
>  says:
>  "If you feel that community testing is unnecessary for your update, you
>  can choose to push it straight to the stable fedora-updates repository
>  instead."
>  
>  IMO this is wrong, it should only be allowed for security updates. 
It should also stay allowed for critical regression fixes at the very least. 
Unfortunately, sometimes updates slip through testing despite causing serious 
issues. For example, an SDL update caused _any_ build against SDL-devel to fail 
(because SDL-config.h was corrupted by a trivial typo in the specfile which was 
missed during testing). We really want the fix to such regressions to go to 
stable as quickly as possible, not to have to go to testing first.

In this case though, there wasn't really any reason to bypass testing, was 
there?

        Kevin Kofler

[Christoph Wickert]

Am Samstag, den 29.12.2007, 01:09 +0000 schrieb Kevin Kofler:
>  Christoph Wickert <christoph.wickert <at> nurfuerspam.de>
> writes:
>  > You are right. I thought we already had policy for that but the wiki
>  > says:
>  > "If you feel that community testing is unnecessary for your update, you
>  > can choose to push it straight to the stable fedora-updates repository
>  > instead."
>  > 
>  > IMO this is wrong, it should only be allowed for security updates.
>  
>  It should also stay allowed for critical regression fixes at the very least. 
>  Unfortunately, sometimes updates slip through testing despite causing serious 
>  issues. For example, an SDL update caused _any_ build against SDL-devel to fail 
>  (because SDL-config.h was corrupted by a trivial typo in the specfile which was 
>  missed during testing). We really want the fix to such regressions to go to 
>  stable as quickly as possible, not to have to go to testing first. 
I completely agree with you. Maybe we could say that updates are allowed
to bypass testing if they fix
a) serious bugs
b) bugs marked as "urgent"
c) broken deps

For c) I think only plain rebuilds should be allowed. If the broken deps
are fixed by updating to a newer version the new package should be
tested again, at least for one or two days.

Christoph

[Rahul Sundaram]

Christoph Wickert wrote:
>  Am Samstag, den 29.12.2007, 01:09 +0000 schrieb Kevin Kofler:
> > Christoph Wickert <christoph.wickert <at> nurfuerspam.de> writes:
> >> You are right. I thought we already had policy for that but the wiki
> >> says:
> >> "If you feel that community testing is unnecessary for your update, you
> >> can choose to push it straight to the stable fedora-updates repository
> >> instead."
> >>
> >> IMO this is wrong, it should only be allowed for security updates.
> > It should also stay allowed for critical regression fixes at the very least. 
> > Unfortunately, sometimes updates slip through testing despite causing serious 
> > issues. For example, an SDL update caused _any_ build against SDL-devel to fail 
> > (because SDL-config.h was corrupted by a trivial typo in the specfile which was 
> > missed during testing). We really want the fix to such regressions to go to 
> > stable as quickly as possible, not to have to go to testing first.
>  
>  I completely agree with you. Maybe we could say that updates are allowed
>  to bypass testing if they fix
>  a) serious bugs
>  b) bugs marked as "urgent"
>  c) broken deps 
b) isn't a good criteria since anybody can mark any bug as urgent. If 
the priority field in bugzilla is restricted to package maintainers and 
triagers, I would agree with you.

Rahul

[Christopher Aillon]

On 12/29/2007 02:32 AM, Rahul Sundaram wrote:
>  Christoph Wickert wrote:
> > I completely agree with you. Maybe we could say that updates are allowed
> > to bypass testing if they fix
> > a) serious bugs
> > b) bugs marked as "urgent"
> > c) broken deps
>  
>  b) isn't a good criteria since anybody can mark any bug as urgent. If 
>  the priority field in bugzilla is restricted to package maintainers and 
>  triagers, I would agree with you. 
The same maintainer who marks "push right to stable" can tweak the field 
before they submit the update and you won't have solved anything.

[Rahul Sundaram]

Christopher Aillon wrote:
>  On 12/29/2007 02:32 AM, Rahul Sundaram wrote:
> > Christoph Wickert wrote:
> >> I completely agree with you. Maybe we could say that updates are allowed
> >> to bypass testing if they fix
> >> a) serious bugs
> >> b) bugs marked as "urgent"
> >> c) broken deps
> >
> > b) isn't a good criteria since anybody can mark any bug as urgent. If 
> > the priority field in bugzilla is restricted to package maintainers 
> > and triagers, I would agree with you.
>  
>  The same maintainer who marks "push right to stable" can tweak the field 
>  before they submit the update and you won't have solved anything. 
Even if it had a strict set of rules and maintainers are going to abuse 
the system, they can mark any update as a critical security update and 
push it through too but then it is much more easier to point out who is 
responsible compared to users just marking a random bug as a high 
priority one.

At any rate, I think we should just disable the priority field or limit 
it's access if we want to rely on it for anything at all.

Rahul

[Christopher Aillon]

On 12/29/2007 04:17 PM, Rahul Sundaram wrote:
>  Christopher Aillon wrote:
> > On 12/29/2007 02:32 AM, Rahul Sundaram wrote:
> >> Christoph Wickert wrote:
> >>> I completely agree with you. Maybe we could say that updates are 
> >>> allowed
> >>> to bypass testing if they fix
> >>> a) serious bugs
> >>> b) bugs marked as "urgent"
> >>> c) broken deps
> >>
> >> b) isn't a good criteria since anybody can mark any bug as urgent. If 
> >> the priority field in bugzilla is restricted to package maintainers 
> >> and triagers, I would agree with you.
> >
> > The same maintainer who marks "push right to stable" can tweak the 
> > field before they submit the update and you won't have solved anything.
>  
>  Even if it had a strict set of rules and maintainers are going to abuse 
>  the system, 
Hey dude, I wasn't the one agreeing with a set of rules, that was you. 
I'm just saying it's unwise to agree with a set of rules that can still 
be worked around easily.

>  they can mark any update as a critical security update and 
>  push it through too but then it is much more easier to point out who is 
>  responsible compared to users just marking a random bug as a high 
>  priority one. 
I just noticed that nobody sent out a FESCo Meeting Summary for 
2007-09-27[1].  There, we approved 
http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft 
so the Fedora Security Response team would have to approve it before it 
gets released as a security advisory.

[1] At least there's a log at 
http://bpepple.fedorapeople.org/fesco/FESCo-2007-09-27.html

Nobody's implemented that yet, though... Luke?  This would be quite nice 
to get done... :-)

[Rahul Sundaram]

Christopher Aillon wrote:
>  Hey dude, I wasn't the one agreeing with a set of rules, that was
> you. 
>  I'm just saying it's unwise to agree with a set of rules that can still 
>  be worked around easily. 
We are talking about related but different issues. I am talking about 
guidelines to support maintainers looking for guidance on maintaining 
their packages and not to prevent maintainers from abusing the system. I 
would atleast initially trust maintainers to just not do that.

Rahul

[Brian Pepple]

On Sat, 2007-12-29 at 18:43 +0100, Christopher Aillon wrote:
>  I just noticed that nobody sent out a FESCo Meeting Summary for 
>  2007-09-27[1].  There, we approved 
>  http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft 
>  so the Fedora Security Response team would have to approve it before it 
>  gets released as a security advisory.
>  
>  [1] At least there's a log at 
>  http://bpepple.fedorapeople.org/fesco/FESCo-2007-09-27.html 
Also, a meeting summary:
http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070927

Later,
/B
-- 
Brian Pepple <bpepple(a)fedoraproject.org&gt;

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E

[Luke Macken]

On Sat, Dec 29, 2007 at 06:43:54PM +0100, Christopher Aillon wrote:
>  On 12/29/2007 04:17 PM, Rahul Sundaram wrote:
> > Christopher Aillon wrote:
> >> On 12/29/2007 02:32 AM, Rahul Sundaram wrote:
> >>> Christoph Wickert wrote:
> >>>> I completely agree with you. Maybe we could say that updates are 
> >>>> allowed
> >>>> to bypass testing if they fix
> >>>> a) serious bugs
> >>>> b) bugs marked as "urgent"
> >>>> c) broken deps
> >>>
> >>> b) isn't a good criteria since anybody can mark any bug as urgent. If 
> >>> the priority field in bugzilla is restricted to package maintainers and 
> >>> triagers, I would agree with you.
> >>
> >> The same maintainer who marks "push right to stable" can tweak the
> field 
> >> before they submit the update and you won't have solved anything.
> >
> > Even if it had a strict set of rules and maintainers are going to abuse 
> > the system,
>
>  Hey dude, I wasn't the one agreeing with a set of rules, that was you. I'm 
>  just saying it's unwise to agree with a set of rules that can still be 
>  worked around easily.
>
> > they can mark any update as a critical security update and push it through 
> > too but then it is much more easier to point out who is responsible 
> > compared to users just marking a random bug as a high priority one.
>
>  I just noticed that nobody sent out a FESCo Meeting Summary for 
>  2007-09-27[1].  There, we approved 
>  http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft so 
>  the Fedora Security Response team would have to approve it before it gets 
>  released as a security advisory.
>
>  [1] At least there's a log at 
>  http://bpepple.fedorapeople.org/fesco/FESCo-2007-09-27.html
>
>  Nobody's implemented that yet, though... Luke?  This would be quite nice to 
>  get done... :-) 
The code has been written and will make its way out with the next bodhi upgrade.

luke

[Xavier Lamien]

2008/1/1, Luke Macken <lmacken(a)redhat.com&gt;:
>  On Sat, Dec 29, 2007 at 06:43:54PM +0100, Christopher Aillon wrote:
>  > On 12/29/2007 04:17 PM, Rahul Sundaram wrote:
>  >> Christopher Aillon wrote:
>  >>> On 12/29/2007 02:32 AM, Rahul Sundaram wrote:
>  >>>> Christoph Wickert wrote:
>  >>>>> I completely agree with you. Maybe we could say that updates are
>  >>>>> allowed
>  >>>>> to bypass testing if they fix
>  >>>>> a) serious bugs
>  >>>>> b) bugs marked as "urgent"
>  >>>>> c) broken deps
>  >>>>
>  >>>> b) isn't a good criteria since anybody can mark any bug as urgent.
> If
>  >>>> the priority field in bugzilla is restricted to package maintainers
>  and
>  >>>> triagers, I would agree with you.
>  >>>
>  >>> The same maintainer who marks "push right to stable" can tweak
> the
>  field
>  >>> before they submit the update and you won't have solved anything.
>  >>
>  >> Even if it had a strict set of rules and maintainers are going to abuse
>  >> the system,
>  >
>  > Hey dude, I wasn't the one agreeing with a set of rules, that was you.
>  I'm
>  > just saying it's unwise to agree with a set of rules that can still be
>  > worked around easily.
>  >
>  >> they can mark any update as a critical security update and push it
>  through
>  >> too but then it is much more easier to point out who is responsible
>  >> compared to users just marking a random bug as a high priority one.
>  >
>  > I just noticed that nobody sent out a FESCo Meeting Summary for
>  > 2007-09-27[1].  There, we approved
>  > http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraftso
>  > the Fedora Security Response team would have to approve it before it
>  gets
>  > released as a security advisory.
>  >
>  > [1] At least there's a log at
>  > http://bpepple.fedorapeople.org/fesco/FESCo-2007-09-27.html
>  >
>  > Nobody's implemented that yet, though... Luke?  This would be quite nice
>  to
>  > get done... :-)
>
>  The code has been written and will make its way out with the next bodhi
>  upgrade. 

!nice, Thx Luke

luke
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  


-- 
Xavier.t Lamien
--
French Fedora Ambassador
Fedora/EPEL Contributor      | http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB

[Daniel P. Berrange]

On Sat, Dec 29, 2007 at 02:27:53AM +0100, Christoph Wickert wrote:
>  
>  Am Samstag, den 29.12.2007, 01:09 +0000 schrieb Kevin Kofler:
>  > Christoph Wickert <christoph.wickert <at> nurfuerspam.de> writes:
>  > > You are right. I thought we already had policy for that but the wiki
>  > > says:
>  > > "If you feel that community testing is unnecessary for your update, you
>  > > can choose to push it straight to the stable fedora-updates repository
>  > > instead."
>  > > 
>  > > IMO this is wrong, it should only be allowed for security updates.
>  > 
>  > It should also stay allowed for critical regression fixes at the very least. 
>  > Unfortunately, sometimes updates slip through testing despite causing serious 
>  > issues. For example, an SDL update caused _any_ build against SDL-devel to fail 
>  > (because SDL-config.h was corrupted by a trivial typo in the specfile which was 
>  > missed during testing). We really want the fix to such regressions to go to 
>  > stable as quickly as possible, not to have to go to testing first.
>  
>  I completely agree with you. Maybe we could say that updates are allowed
>  to bypass testing if they fix
>  a) serious bugs
>  b) bugs marked as "urgent"
>  c) broken deps
>  
>  For c) I think only plain rebuilds should be allowed. If the broken deps
>  are fixed by updating to a newer version the new package should be
>  tested again, at least for one or two days. 
For fixing broken deps its reasonable to bypassing testing, since the
assuption is the current package is already un-installable.  Bugs marked
'urgent' is a complete waste of time - everyone thinks their own bug
is urgent / important. If someone enters a BZ and marks it urgent I'll
typically put it at the bottom of my TODO list because it usually isn't
urgent at all ;-P   Similarly 'serious bug' is kind of hard to define as
a formal policy - you need to enumerate a reasonable set of scenarios
which are considered serious. 'broken deps' is one good example of a
serious bug.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[drago01]

On Dec 29, 2007 2:48 AM, Daniel P. Berrange <berrange(a)redhat.com&gt; wrote:

>  For fixing broken deps its reasonable to bypassing testing, since
> the
>  assuption is the current package is already un-installable.  Bugs marked
>  'urgent' is a complete waste of time - everyone thinks their own bug
>  is urgent / important. If someone enters a BZ and marks it urgent I'll
>  typically put it at the bottom of my TODO list because it usually isn't
>  urgent at all ;-P   Similarly 'serious bug' is kind of hard to define as
>  a formal policy - you need to enumerate a reasonable set of scenarios
>  which are considered serious. 'broken deps' is one good example of a
>  serious bug. 
data corruption, app is "unuseable" ... etc.

but I think the best solution is "trust the maintainer" .. he should
be able to judge if the update is urgent or not ... if not he should
not be a maintainer at all.

[Rahul Sundaram]

drago01 wrote:
>  On Dec 29, 2007 2:48 AM, Daniel P. Berrange
> <berrange(a)redhat.com&gt; wrote:
>  
> > For fixing broken deps its reasonable to bypassing testing, since the
> > assuption is the current package is already un-installable.  Bugs marked
> > 'urgent' is a complete waste of time - everyone thinks their own bug
> > is urgent / important. If someone enters a BZ and marks it urgent I'll
> > typically put it at the bottom of my TODO list because it usually isn't
> > urgent at all ;-P   Similarly 'serious bug' is kind of hard to define as
> > a formal policy - you need to enumerate a reasonable set of scenarios
> > which are considered serious. 'broken deps' is one good example of a
> > serious bug.
>  
>  data corruption, app is "unuseable" ... etc.
>  
>  but I think the best solution is "trust the maintainer" .. he should
>  be able to judge if the update is urgent or not ... if not he should
>  not be a maintainer at all. 
It is still useful to give a set of usual scenarios where the bug is 
considered urgent as guidance for maintainers in need of it.

Rahul

[Michael Schwendt]

On Sat, 29 Dec 2007 01:09:06 +0000 (UTC), Kevin Kofler wrote:

>  Christoph Wickert <christoph.wickert <at> nurfuerspam.de>
> writes:
>  > You are right. I thought we already had policy for that but the wiki
>  > says:
>  > "If you feel that community testing is unnecessary for your update, you
>  > can choose to push it straight to the stable fedora-updates repository
>  > instead."
>  > 
>  > IMO this is wrong, it should only be allowed for security updates.
>  
>  It should also stay allowed for critical regression fixes at the very least. 
>  Unfortunately, sometimes updates slip through testing despite causing serious 
>  issues. For example, an SDL update caused _any_ build against SDL-devel to fail 
>  (because SDL-config.h was corrupted by a trivial typo in the specfile which was 
>  missed during testing). 
Wow! That's one brilliant way to phrase it.
Not. ;) It didn't "slip through testing" as you call it. It wasn't
tested
at all. Neither "in testing" nor "before pushing it into testing".

[Patrice Dumas]

On Sat, Dec 29, 2007 at 01:55:08AM +0100, Christoph Wickert wrote:
>  > 
>  > For that, we could make a bodhi policy. Cause no rules say all package
>  > Must go to testing-update before move to stable one.
>  
>  You are right. I thought we already had policy for that but the wiki
>  says:
>  "If you feel that community testing is unnecessary for your update, you
>  can choose to push it straight to the stable fedora-updates repository
>  instead."
>  
>  IMO this is wrong, it should only be allowed for security updates. 
I disagree. In my case nobody ever noticed the regressions in testing
even for my packages that are widely used. And for the packages that 
correspond with a niche of users, of course I never got any feedback 
in bodhi.

Given that it seems that there isn't a lot of people using testing it
seems to me that for niche software it would be better to go straight to
stable.

--
Pat

[Hans de Goede]

Patrice Dumas wrote:
>  On Sat, Dec 29, 2007 at 01:55:08AM +0100, Christoph Wickert wrote:
> >> For that, we could make a bodhi policy. Cause no rules say all package
> >> Must go to testing-update before move to stable one.
> > You are right. I thought we already had policy for that but the wiki
> > says:
> > "If you feel that community testing is unnecessary for your update, you
> > can choose to push it straight to the stable fedora-updates repository
> > instead."
> >
> > IMO this is wrong, it should only be allowed for security updates.
>  
>  I disagree. In my case nobody ever noticed the regressions in testing
>  even for my packages that are widely used. And for the packages that 
>  correspond with a niche of users, of course I never got any feedback 
>  in bodhi.
>  
>  Given that it seems that there isn't a lot of people using testing it
>  seems to me that for niche software it would be better to go straight to
>  stable.
>  
+1

Not to mention updates which aren't updates but new packages.

Regards,

Hans

[Lubomir Kundrak]

On Fri, 2007-12-28 at 19:19 +0100, Christoph Wickert wrote:
>  Raleigh, we have a problem...
>  
>  python-gammu, which is required by wammu, prevents users from updating
>  to the latest gammu release for several days now. 
What strikes me here is that we don't have a tooling that would avoid
this. Maybe ti wouldn't be so hard to hook some scripts to bodhi that
won't let a package out if it causes a dependency to be unsatisfiable or
it itself have an unmet dependency.

-- 
Lubomir Kundrak (Red Hat Security Response Team)

[Jesse Keating]

On Fri, 28 Dec 2007 21:06:10 +0100
Lubomir Kundrak <lkundrak(a)redhat.com&gt; wrote:

>  What strikes me here is that we don't have a tooling that would
> avoid
>  this. Maybe ti wouldn't be so hard to hook some scripts to bodhi that
>  won't let a package out if it causes a dependency to be unsatisfiable
>  or it itself have an unmet dependency. 

The problem continues to be the time it takes to calculate that,
particularly when you have to generate multilib sets to ensure you
don't break anything in the multilib set.  Luke has been working off
and on on doing depchecking at some points of a bodhi push cycle, but
it's a tough problem to solve.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Ignacio Vazquez-Abrams]

On Fri, 2007-12-28 at 21:06 +0100, Lubomir Kundrak wrote:
>  On Fri, 2007-12-28 at 19:19 +0100, Christoph Wickert wrote:
>  > Raleigh, we have a problem...
>  > 
>  > python-gammu, which is required by wammu, prevents users from updating
>  > to the latest gammu release for several days now.
>  
>  What strikes me here is that we don't have a tooling that would avoid
>  this. Maybe ti wouldn't be so hard to hook some scripts to bodhi that
>  won't let a package out if it causes a dependency to be unsatisfiable or
>  it itself have an unmet dependency. 
The high-level architecture is in place. All it needs is someone
familiar with bodhi and repodata to write the code.

https://fedorahosted.org/bodhi/ticket/79

-- 
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com&gt;

PLEASE don't CC me; I'm already subscribed