4:23 a.m.
Since packages belonging to maintainer that have not changed their
password have been removed, I keep being notified about a broken
dependency in package "insight", depending on "iwidgets".
"iwidgets" has been deprecated and thus, as long as this situation
remains, "insight" will be broken.
Consequently, I orphaned "insight" because it is not maintainable
anymore.
Even since I orphaned it, I receive lots of reports about broken
dependencies for rawhide and F17.
Please someone: do something to stop this spamming. I do not want to be
constrained to blacklist the buildsys :-(
Thanks to whoever can take an action.
Cheers,
Patrick
6:01 a.m.
On Mon, 20 Feb 2012 11:23:53 +0100, PM (Patrick) wrote:
Since packages belonging to maintainer that have not changed their
password have been removed, I keep being notified about a broken
dependency in package "insight", depending on "iwidgets".
"iwidgets" has been deprecated and thus, as long as this situation
remains, "insight" will be broken.
Consequently, I orphaned "insight" because it is not maintainable
anymore.
Even since I orphaned it, I receive lots of reports about broken
dependencies for rawhide and F17.
Please someone: do something to stop this spamming. I do not want to be
constrained to blacklist the buildsys :-(
Thanks to whoever can take an action.
*You* could have avoided this by _retiring_ "insight" properly:
http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
You could take "insight" back to retire it.
The reason you receive the Rawhide build report mails is that you're
a member of the insight-owner@ mail alias.
--
Fedora release 17 (Beefy Miracle) - Linux 3.3.0-0.rc3.git7.2.fc17.x86_64
loadavg: 0.14 0.25 0.19
9:56 a.m.
On Mon, 2012-02-20 at 13:01 +0100, Michael Schwendt wrote:
*You* could have avoided this by _retiring_ "insight"
properly:
http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
*** This is not a normal end of life: this is an assassination ***
There's a maintainer (krege) who's OK to take ownership of iwidgets, but
he can't because the package has been deprecated (despite the
requirement from 3 packages that are still alive!) instead of being
simply orphaned.
10:04 a.m.
On Mon, Feb 20, 2012 at 16:56:28 +0100,
Patrick Monnerat <pm(a)datasphere.ch> wrote:
On Mon, 2012-02-20 at 13:01 +0100, Michael Schwendt wrote:
> *You* could have avoided this by _retiring_ "insight" properly:
> http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
*** This is not a normal end of life: this is an assassination ***
There's a maintainer (krege) who's OK to take ownership of iwidgets, but
he can't because the package has been deprecated (despite the
requirement from 3 packages that are still alive!) instead of being
simply orphaned.
Note that the list of packages being removed and their dependencies was
posted at least a month before it happened (probably more, but I don't
remember for sure). Packagers really need to read the devel list so
that stuff like this doesn't catch them by surprise.
The package can still be brought back, but now requires a review. But
since there are at least two people interested in this happening, getting
the review done shouldn't be too big of a deal.
12:09 p.m.
Bruno Wolff III wrote:
The package can still be brought back, but now requires a review.
This is really silly, why can't we just unretire the 2 or 3 packages which
were noticed the day they were retired and got an interested maintainer now?
(iwidgets was one of them, but I've seen mails about 1 or 2 others here.)
The reason a rereview is required for retired packages is because packages
tend to bitrot if orphaned for a long time, but this is NOT the situation
here. This is just completely pointless red tape making things a PITA for NO
reason whatsoever.
Kevin Kofler
12:27 p.m.
On 02/20/2012 11:39 PM, Kevin Kofler wrote:
Bruno Wolff III wrote:
> The package can still be brought back, but now requires a review.
This is really silly, why can't we just unretire the 2 or 3 packages which
were noticed the day they were retired and got an interested maintainer now?
(iwidgets was one of them, but I've seen mails about 1 or 2 others here.)
The reason a rereview is required for retired packages is because packages
tend to bitrot if orphaned for a long time, but this is NOT the situation
here. This is just completely pointless red tape making things a PITA for NO
reason whatsoever.
File a ticket with FESCo with your proposed change in the policy.
Rahul
10:55 a.m.
Rahul Sundaram wrote:
File a ticket with FESCo with your proposed change in the policy.
Why does it need a policy change at all to apply a 1-2 day grace period?
(More days have passed now, but that's just because we all lost a lot more
time discussing this than it would have taken an admin to just hit the
"unretire" button.) This should just be common sense! It's really stupid
that we need to have every little detail written down in the letter of the
policy these days because everything is being enforced in a totally
inflexible and pedantic way (sometimes automatically by the software, see
Bodhi).
Kevin Kofler
11:08 a.m.
On Tue, Feb 21, 2012 at 17:55:01 +0100,
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Rahul Sundaram wrote:
> File a ticket with FESCo with your proposed change in the policy.
Why does it need a policy change at all to apply a 1-2 day grace period?
(More days have passed now, but that's just because we all lost a lot more
time discussing this than it would have taken an admin to just hit the
"unretire" button.) This should just be common sense! It's really stupid
that we need to have every little detail written down in the letter of the
policy these days because everything is being enforced in a totally
inflexible and pedantic way (sometimes automatically by the software, see
Bodhi).
Note that there already is a grace period. The policy used to be that a
review was needed after a package was orphaned. There was discussion about
that something on the order of a year ago and various time limits were
discussed. Eventually a consensus appeared to be reached as using when the
package is blocked from repos as the trigger for needing a review to bring
it back.
Note that the people involved here had over a month to deal with this and
didn't. Packagers are expected to read the devel list and they should
have noticed that their packages were going to be affected well in
advance of the deadline.
Do a new review shouldn't really be all that burdensome unless they find
something signicant broken. There are two people involved so that don't
have to find an outside person who has time to do the review.
11:26 a.m.
Bruno Wolff III wrote:
Note that there already is a grace period. The policy used to be that
a
review was needed after a package was orphaned.
No. The policy used to be that a review was needed if the package was 1.
orphaned AND 2. not updated for 3 months. And there was basically no
enforcement of that policy because there was pretty much no way to enforce
it (for packages which were not retired yet), which is why it got changed.
(For already retired packages, you had to prove the 3 months rule to get it
unretired without a rereview, which was applicable only in rare exceptional
cases.)
Note that the people involved here had over a month to deal with this
and
didn't. Packagers are expected to read the devel list and they should
have noticed that their packages were going to be affected well in
advance of the deadline.
Half of the distro was affected by the indiscriminate mass orphaning done
this time. There was no way to know which packages would still have been
affected at the end.
And packagers of dependent packages weren't directly notified of the
impending retiring. Reading devel is not (and should not be) a requirement
(only devel-announce is).
In all the previous mass-retiring rounds, the process was executed as
follows:
1. The orphaned packages NO other package in the distro depends on were
retired.
2. For the others, the maintainer of the dependent package was directly
contacted (in a personal mail discussing only the exact situation affecting
him/her) and asked whether to pick up the dependency or retire his/her
package.
3. The packages which didn't get picked up in 2. were retired.
I don't see at all why it hasn't been done that way this time. (Maybe
because there were too many affected packages to e-mail everyone personally?
If so, that's yet another sign that this retiring round was way too
destructive and that we need to be a lot less aggressive in dropping
packages!)
Do a new review shouldn't really be all that burdensome unless
they find
something signicant broken. There are two people involved so that don't
have to find an outside person who has time to do the review.
It's all a waste of everyone's time when it'd just take one person to
apologize for the miscommunication and click on one f***ing button.
Policies are made to serve humans. Unfortunately, here in Fedora, I get the
opposite impression! :-(
Kevin Kofler
11:45 a.m.
On Tue, Feb 21, 2012 at 18:26:36 +0100,
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Half of the distro was affected by the indiscriminate mass orphaning done
this time. There was no way to know which packages would still have been
affected at the end.
Packages that were affected via rpm dependencies were listed as part of the
announcement. I looked through the list for packages I cared about and
in one case let the asterisk packers know about a dependency of asterisk
that was on the list that I didn't want to maintain and they picked it up.
11:49 a.m.
Bruno Wolff III wrote:
Packages that were affected via rpm dependencies were listed as part
of
the announcement. I looked through the list for packages I cared about and
in one case let the asterisk packers know about a dependency of asterisk
that was on the list that I didn't want to maintain and they picked it up.
That list was several screens long. I don't think it's fair to blame
packagers for having missed their package in it, and only noticed once the
"broken dependencies" whines started trickling in.
Kevin Kofler
12:07 p.m.
On 02/21/2012 10:25 PM, Kevin Kofler wrote:
Rahul Sundaram wrote:
> File a ticket with FESCo with your proposed change in the policy.
Why does it need a policy change at all to apply a 1-2 day grace period?
Any change in policy requires you to file a ticket with FESCo. If you
just want to rant instead, feel free.
Rahul
5:25 p.m.
Rahul Sundaram wrote:
On 02/21/2012 10:25 PM, Kevin Kofler wrote:
> Rahul Sundaram wrote:
>> File a ticket with FESCo with your proposed change in the policy.
>
> Why does it need a policy change at all to apply a 1-2 day grace period?
Any change in policy requires you to file a ticket with FESCo. If you
just want to rant instead, feel free.
My point is that this does not require any change in policy, just an admin
applying common sense rather than following the letter of the policy to the
absurd. It's unfortunate that here, the humans are serving the policy rather
than the opposite!
Do we really need a policy saying "Use common sense. In case of conflicts,
this supersedes all other policies."? Why isn't this obvious? :-/
Kevin Kofler
5:41 p.m.
On Wed, 2012-02-22 at 00:25 +0100, Kevin Kofler wrote:
Do we really need a policy saying "Use common sense. In case of
conflicts,
this supersedes all other policies."?
Absolutely not.
Why isn't this obvious? :-/
Because common sense is anything but common, and often not sense.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
7:48 p.m.
On Wed, Feb 22, 2012 at 12:25:59AM +0100, Kevin Kofler wrote:
Rahul Sundaram wrote:
> On 02/21/2012 10:25 PM, Kevin Kofler wrote:
>> Rahul Sundaram wrote:
>>> File a ticket with FESCo with your proposed change in the policy.
>>
>> Why does it need a policy change at all to apply a 1-2 day grace period?
>
> Any change in policy requires you to file a ticket with FESCo. If you
> just want to rant instead, feel free.
My point is that this does not require any change in policy, just an admin
applying common sense rather than following the letter of the policy to the
absurd. It's unfortunate that here, the humans are serving the policy rather
than the opposite!
Do we really need a policy saying "Use common sense. In case of conflicts,
this supersedes all other policies."? Why isn't this obvious? :-/
Just a historical note since I remember some of the discussion about this:
it was thought that by the time a package has been retired it has already
undergone a long period where it was uncared for. This could be said to
still be the case for the packages which were retired because they FTBFS for
several releases.
The orphan packages are more varied. Originally, there were packages that
had been orphaned for many releases. I believe that now we're cleaning up
all orphaned packages at each release branching so this may not be as much
the case. There could still be packages that were orphaned for up to
6 months, missing out on all of a new releases pre-alpha period of
development. Not sure that this is that much of a concern, though.
Another thought that I remember being put out for discussion at the time
(although I do not know if it informed the final decision) was that packages
deserve periodic re-reviews anyhow. So if they had hit a point where they
had been retired, it was a nice, well-demarcated time to require that of
them.
Once again, these are just historical reasons for this, current FESCo is
certainly free to decide whether these reasons are still relevant or are
outdated.
-Toshio
10:19 a.m.
On Tue, 21 Feb 2012 17:48:37 -0800, TK (Toshio) wrote:
The orphan packages are more varied. Originally, there were packages
that
had been orphaned for many releases. I believe that now we're cleaning up
all orphaned packages at each release branching so this may not be as much
the case. There could still be packages that were orphaned for up to
6 months, missing out on all of a new releases pre-alpha period of
development. Not sure that this is that much of a concern, though.
And nevertheless, this thread is also about an orphan within F-17:
# yum install insight
[...]
--> Finished Dependency Resolution
Error: Package: insight-6.8.1-5.fc17.x86_64 (fedora)
Requires: iwidgets
The missing requirement had built successfully for the Fedora_17_Mass_Rebuild
http://koji.fedoraproject.org/koji/buildinfo?buildID=286344
If no volunteers show up and adapt this package and its build
requirements, it will remain broken. Or somebody cleans up F-17 once more
prior to its final release and _retires_ packages like this one.
Is it too easy to create orphans so late in the process?
Is it too easy to create orphans without telling anyone about it?
--
Fedora release 17 (Beefy Miracle) - Linux 3.3.0-0.rc3.git7.2.fc17.x86_64
loadavg: 0.55 0.25 0.20
10:34 a.m.
Michael Schwendt wrote:
And nevertheless, this thread is also about an orphan within F-17:
# yum install insight
[...]
--> Finished Dependency Resolution
Error: Package: insight-6.8.1-5.fc17.x86_64 (fedora)
Requires: iwidgets
The missing requirement had built successfully for the
Fedora_17_Mass_Rebuild
http://koji.fedoraproject.org/koji/buildinfo?buildID=286344
This is exactly why retiring it was broken and now you're making it a PITA
to fix that. It's required for another package and it works, it should not
have been retired.
If no volunteers show up and adapt this package and its build
requirements, it will remain broken. Or somebody cleans up F-17 once more
prior to its final release and _retires_ packages like this one.
Or, you know, people just UNRETIRE the dependency? The reason insight is
orphaned in the first place is because of the indiscriminate retiring of its
dependency (see the mailing list thread announcing the orphaning), the
maintainer already stated he'll pick it up again if iwidgets is resurrected.
Looks like a simple solution for a simple problem, and it's being made into
a PITA because of religious pedantic application of a policy.
IMHO, we should instruct our administrators to act in the best interest of
the project no matter whether it matches the letter of the policies or not.
Is it too easy to create orphans so late in the process?
It's too easy to remove working packages from the distribution. Insight
would NOT be orphaned if it hadn't been for that. See above.
Is it too easy to create orphans without telling anyone about it?
He did tell. See the thread he posted about it.
Kevin Kofler
2:22 p.m.
On Wed, 22 Feb 2012 17:34:23 +0100, KK (Kevin) wrote:
The reason insight is
orphaned in the first place is because of the indiscriminate retiring of its
dependency (see the mailing list thread announcing the orphaning), the
maintainer already stated he'll pick it up again if iwidgets is resurrected.
Looks like a simple solution for a simple problem,
Who wants to take "iwidgets"? And why doesn't the "insight"
maintainer
contribute a quick review?
Looks like a simple solution for a simple problem. ;)
> Is it too easy to create orphans so late in the process?
It's too easy to remove working packages from the distribution. Insight
would NOT be orphaned if it hadn't been for that. See above.
> Is it too easy to create orphans without telling anyone about it?
He did tell. See the thread he posted about it.
The "iwidgets" maintainer is marked as "inactive" in FAS. Has he
announced
leaving the project? Or has he left silently without notifying anyone?
The person's personal Wiki page is unchanged. What has happened to him?
How long has iwidgets been orphaned before pruning of FAS?
--
I've seen the visibly annoyed post about "insight", but it is
"iwidgets"
that has been dropped due to lack of maintainer.
5:39 p.m.
Rahul Sundaram wrote:
On 02/21/2012 10:25 PM, Kevin Kofler wrote:
> Rahul Sundaram wrote:
>> File a ticket with FESCo with your proposed change in the policy.
>
> Why does it need a policy change at all to apply a 1-2 day grace period?
Any change in policy requires you to file a ticket with FESCo. If you
just want to rant instead, feel free.
So to make you happy, let's fight bureaucracy through bureaucracy:
https://fedorahosted.org/fesco/ticket/808
:-/
We need more decisions taken through thought processes, lenience and
helpfulness and fewer decisions taken through inflexible bureaucracy and
rigid policies.
Kevin Kofler
5:59 p.m.
On Wed, 22 Feb 2012 00:39:10 +0100
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Rahul Sundaram wrote:
> On 02/21/2012 10:25 PM, Kevin Kofler wrote:
>> Rahul Sundaram wrote:
>>> File a ticket with FESCo with your proposed change in the policy.
>>
>> Why does it need a policy change at all to apply a 1-2 day grace
>> period?
>
> Any change in policy requires you to file a ticket with FESCo. If
> you just want to rant instead, feel free.
So to make you happy, let's fight bureaucracy through bureaucracy:
https://fedorahosted.org/fesco/ticket/808
:-/
We need more decisions taken through thought processes, lenience and
helpfulness and fewer decisions taken through inflexible bureaucracy
and rigid policies.
I answered in the ticket, but perhaps I'll ask here too...
Was there any actual request by someone who wanted to maintain this
package ? 2 days after orphaning? where?
In any case, I'm happy to help out... if the prospective new maintainer
wants I would be happy to review the package. Just submit it and cc me.
kevin
10:43 a.m.
Kevin Fenzi wrote:
Was there any actual request by someone who wanted to maintain this
package ? 2 days after orphaning? where?
In any case, I'm happy to help out... if the prospective new maintainer
wants I would be happy to review the package. Just submit it and cc me.
So it looks like we failed to CC the public list on the discussions, darn…
This was discussed in a mail exchange with the Insight maintainer, krege
(the maintainer who picked up the rest of the itcl stack just before the
mass-retiring) and Bill Nottingham (the admin who did the mass-retiring, who
we CCed on the whole exchange). Krege agreed to picking up iwidgets if it
got unretired, but we didn't get any answer from notting, not even a "no",
just no reaction at all.
Krege's offer to pick up iwidgets was on Feb 8, the mass-retiring was on Feb
6.
Kevin Kofler
10:46 a.m.
On Wed, 22 Feb 2012 17:43:23 +0100
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Kevin Fenzi wrote:
> Was there any actual request by someone who wanted to maintain this
> package ? 2 days after orphaning? where?
>
> In any case, I'm happy to help out... if the prospective new
> maintainer wants I would be happy to review the package. Just
> submit it and cc me.
So it looks like we failed to CC the public list on the discussions,
darn…
Ah, that explains my puzzlement. :(
This was discussed in a mail exchange with the Insight maintainer,
krege (the maintainer who picked up the rest of the itcl stack just
before the mass-retiring) and Bill Nottingham (the admin who did the
mass-retiring, who we CCed on the whole exchange). Krege agreed to
picking up iwidgets if it got unretired, but we didn't get any answer
from notting, not even a "no", just no reaction at all.
Krege's offer to pick up iwidgets was on Feb 8, the mass-retiring was
on Feb 6.
Yeah, first I see is this thread, which was 2 weeks after.
Anyhow, happy to help out... point me to the review and I'll be happy
to review it and get it revived.
kevin
4:30 p.m.
Kevin Kofler (kevin.kofler(a)chello.at) said:
So it looks like we failed to CC the public list on the discussions,
darn…
This was discussed in a mail exchange with the Insight maintainer, krege
(the maintainer who picked up the rest of the itcl stack just before the
mass-retiring) and Bill Nottingham (the admin who did the mass-retiring, who
we CCed on the whole exchange). Krege agreed to picking up iwidgets if it
got unretired, but we didn't get any answer from notting, not even a "no",
just no reaction at all.
Sorry, I should have at least replied with a pointer to the unretire
process. But just CC'ing me and expecting me to manually handle exceptions
is no process at all - it doesn't scale, and it encourages the playing of
favorites. Even if you think exceptions are warranted, file a ticket - that
way it can be tracked. In any case, that thread quickly devolved into
discussions of just how obsolete insight may or may not be, without any
real statement of strong desire to keep it.
However, what you state is 'common sense' is merely manual load. If you've
got a way that we can track when packages were orphaned that's easily
auditable and scriptable, we can adjust the process to have some sort of grace
period. Since we don't have that data easily, that's why the policy is the
way it is.
Bill
1:14 p.m.
On Mon, 20 Feb 2012 19:09 +0100, KK (Kevin) wrote:
Bruno Wolff III wrote:
> The package can still be brought back, but now requires a review.
This is really silly, why can't we just unretire the 2 or 3 packages which
were noticed the day they were retired and got an interested maintainer now?
(iwidgets was one of them, but I've seen mails about 1 or 2 others here.)
The reason a rereview is required for retired packages is because packages
tend to bitrot if orphaned for a long time, but this is NOT the situation
here. This is just completely pointless red tape making things a PITA for NO
reason whatsoever.
Silly or not, apparently there are at least two package maintainers
who could join and return the package easily, especially since one is
the previous maintainer. And who maintains the "3 packages that are alive"?
The same maintainers or additional ones?
--
Fedora release 17 (Beefy Miracle) - Linux 3.3.0-0.rc3.git7.2.fc17.x86_64
loadavg: 1.68 1.03 0.48
4455
days inactive
4457
days old
24 comments
10 participants
participants (10)
-
Adam Williamson -
Bill Nottingham -
Bruno Wolff III -
Kevin Fenzi -
Kevin Kofler -
Michael Schwendt -
Patrick Monnerat -
Przemek Klosowski -
Rahul Sundaram -
Toshio Kuratomi