3:14 p.m.
I would like to initiate the non-responsive maintainer policy [1]
against Damien Durand (CC'ed). Damien has not touched most of his
packages [2] for the last one year. Significantly, Pessulus was not
updated from 2.23.x to 2.24.x, while libgtksourceviewmm has also
missed a few upstream releases. An effort was made to contact by
filing a bug against 'gnubiff': https://bugzilla.redhat.com/464012
However there has been no response till now.
Here is another bug pending response for a long time:
https://bugzilla.redhat.com/257721
Happy hacking,
Debarshi
[1] https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMai...
[2] https://admin.fedoraproject.org/pkgdb/users/packages/splinux
4:48 p.m.
Le Sun, 9 Nov 2008 02:44:55 +0530,
"Debarshi Ray" <debarshi.ray(a)gmail.com> a écrit :
I would like to initiate the non-responsive maintainer policy [1]
against Damien Durand (CC'ed). Damien has not touched most of his
packages [2] for the last one year. Significantly, Pessulus was not
updated from 2.23.x to 2.24.x, while libgtksourceviewmm has also
missed a few upstream releases. An effort was made to contact by
filing a bug against 'gnubiff': https://bugzilla.redhat.com/464012
However there has been no response till now.
It's useless, he has change his
email some time ago. As he cames
sporadically on the french fedora channel, I could contact him : he
completely give up his contribution for fedora (he was a great geek,
he decided to came back to the real live, you know :-)); but he has
some laziness to orphan his packages (our pressure seems to be
ineficient).
So go ahead in this process, i'm supporting you.
Here is another bug pending response for a long time:
https://bugzilla.redhat.com/257721
Happy hacking,
Debarshi
[1]
https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMai...
[2] https://admin.fedoraproject.org/pkgdb/users/packages/splinux
Pablo
8:22 a.m.
Sorry, I missed your mail in the mess that is my inbox.
It's useless, he has change his email some time ago. As he cames
sporadically on the french fedora channel, I could contact him : he
Okay, fine. I am planning to freshen up the 'pessulus' and 'gnubiff'
packages during FOSS.in, which is coming up next week.
Rakesh (CC'ed) had expressed his wish to take up gtksourceviewmm, so
hopefully that will also be taken care of.
completely give up his contribution for fedora (he was a great geek,
he decided to came back to the real live, you know :-));
That is very unfortunate. Would you want to look after some of the
packages Damien had?
Happy hacking,
Debarshi
4:57 p.m.
Le Mon, 17 Nov 2008 19:52:15 +0530,
"Debarshi Ray" <debarshi.ray(a)gmail.com> a écrit :
Sorry, I missed your mail in the mess that is my inbox.
No prob' :-)
> It's useless, he has change his email some time ago. As he cames
> sporadically on the french fedora channel, I could contact him : he
Okay, fine. I am planning to freshen up the 'pessulus' and 'gnubiff'
packages during FOSS.in, which is coming up next week.
Rakesh (CC'ed) had expressed his wish to take up gtksourceviewmm, so
hopefully that will also be taken care of.
> completely give up his contribution for fedora (he was a great geek,
> he decided to came back to the real live, you know :-));
That is very unfortunate. Would you want to look after some of the
packages Damien had?
Yes, "gnome-specimen" and "macchanger"
look interesting, i'll take
them. For information, firestarter and musicbox seem to have no more
upstream, they should follow the EOL policy, no ?
Happy hacking,
Debarshi
1:41 a.m.
2008/11/18 Martin-Gomez Pablo <pablo.martin-gomez(a)laposte.net>:
Le Mon, 17 Nov 2008 19:52:15 +0530,
"Debarshi Ray" <debarshi.ray(a)gmail.com> a écrit :
[..]
> Rakesh (CC'ed) had expressed his wish to take up
gtksourceviewmm, so
> hopefully that will also be taken care of.
>
FI, Vivek (bonii) will be handling this one.
--
rakesh
8:23 a.m.
I just started Gnubiff 2.2.10 builds for F-9, F-10 and devel.
Happy hacking,
Debarshi
9:40 a.m.
I would like to initiate the non-responsive maintainer policy [1]
against Damien Durand (CC'ed).
Some more bugs assigned to him that need attention:
https://bugzilla.redhat.com/465114: FTBFS gnome-specimen-0.3-2.fc10
https://bugzilla.redhat.com/465075: FTBFS gdmap-0.7.5-6.fc6
Cheers,
Debarshi
10:37 a.m.
2009/1/11 Debarshi Ray <debarshi.ray(a)gmail.com>:
> I would like to initiate the non-responsive maintainer policy
[1]
> against Damien Durand (CC'ed).
Some more bugs assigned to him that need attention:
https://bugzilla.redhat.com/465114: FTBFS gnome-specimen-0.3-2.fc10
I checked this one and it is probably fixed already, though F9 build
is absent but I checked that F9 build also.
http://koji.fedoraproject.org/koji/taskinfo?taskID=1044981
And it is fine.
https://bugzilla.redhat.com/465075: FTBFS gdmap-0.7.5-6.fc6
Will look into this, it needs some love I guess.
--
rakesh
1:23 p.m.
2009/1/11 Rakesh Pandit <rakesh.pandit(a)gmail.com>:
2009/1/11 Debarshi Ray <debarshi.ray(a)gmail.com>:
>> I would like to initiate the non-responsive maintainer policy [1]
>> against Damien Durand (CC'ed).
>
> Some more bugs assigned to him that need attention:
> https://bugzilla.redhat.com/465114: FTBFS gnome-specimen-0.3-2.fc10
I checked this one and it is probably fixed already, though F9 build
is absent but I checked that F9 build also.
http://koji.fedoraproject.org/koji/taskinfo?taskID=1044981
And it is fine.
Wello this one is already fixed and I have build for F-9 and closed.
> https://bugzilla.redhat.com/465075: FTBFS gdmap-0.7.5-6.fc6
While fixing this one I encountered a problem of 2 more folks fixing
it simultaneously. Which resulted in unnecessary commits and bump.
The basic problem is without assigning bug why we committing the fix ?
This has resulted in confusion. Lets assign bugs at least before
acting on them and that will help in collaboration.
--
rakesh
4:37 a.m.
On Mon, 12 Jan 2009 00:53:37 +0530, Rakesh wrote:
>> https://bugzilla.redhat.com/465075: FTBFS gdmap-0.7.5-6.fc6
>
While fixing this one I encountered a problem of 2 more folks fixing
it simultaneously. Which resulted in unnecessary commits and bump.
The basic problem is without assigning bug why we committing the fix ?
This has resulted in confusion. Lets assign bugs at least before
acting on them and that will help in collaboration.
The problem is you. Nobody else has committed anything at the same
time. In gdmap/devel, take a look at
cvs diff -r1.9 -r1.10 gdmap.spec | less
which shows that you've reverted several old commits dating
back to Feb 2008. You've also decreased %release which resulted
in tag conflicts. To avoid all this, you ought to have started
with a fresh working-copy.
5:04 a.m.
2009/1/12 Michael Schwendt <mschwendt(a)gmail.com>:
[..]
The problem is you. Nobody else has committed anything at the same
time. In gdmap/devel, take a look at
cvs diff -r1.9 -r1.10 gdmap.spec | less
which shows that you've reverted several old commits dating
back to Feb 2008. You've also decreased %release which resulted
in tag conflicts. To avoid all this, you ought to have started
with a fresh working-copy.
Yeah my mistake
But what prevents one to assigning bugs to himself before fixing it
and doing the build after commits? Not even importing the source for
which fix was done ? why half work ?
--
rakesh
5:39 a.m.
On Mon, 12 Jan 2009 16:34:45 +0530, Rakesh wrote:
But what prevents one to assigning bugs to himself before fixing it
and doing the build after commits? Not even importing the source for
which fix was done ? why half work ?
Can't answer that and don't want to guess. ;)
Let me point out the following, though:
This would be less of an issue, if the package had a maintainer instead of
a non-responsive one.
The FTBFS issue was reported on 2008-02-22 for a package with a Fedora 6
tag. The incomplete commit to fix it was done seven months later. The
ticket - https://bugzilla.redhat.com/434529 - was closed prior to
waiting for the build results. Nobody has verified this, nobody
has reopened it. Yes, one can see the source tarball was missing.
The FTBFS issue was reported _another_ time for the same package id
on 2008-10-01 in a _new_ ticket: https://bugzilla.redhat.com/465075
That's the one you refer to.
Still, cvs commits can be completely unrelated to any open bugzilla
tickets. That's why it is important to be careful when committing changes
and not to ignore cvs' warnings about working-copies of files being older
than files in the cvs repository. It is really bad to not examine the
diffs painstakingly, but simply force changes into the repository.
6:19 a.m.
2009/1/12 Michael Schwendt <mschwendt(a)gmail.com>:
On Mon, 12 Jan 2009 16:34:45 +0530, Rakesh wrote:
> But what prevents one to assigning bugs to himself before fixing it
> and doing the build after commits? Not even importing the source for
> which fix was done ? why half work ?
Can't answer that and don't want to guess. ;)
Let me point out the following, though:
This would be less of an issue, if the package had a maintainer instead of
a non-responsive one.
I request FISco member attention here. The non-responsive maintainer
policy was initiated long ago here.
--
rakesh
2:37 a.m.
On Mon, 12 Jan 2009 17:49:14 +0530, Rakesh wrote:
> On Mon, 12 Jan 2009 16:34:45 +0530, Rakesh wrote:
>
>> But what prevents one to assigning bugs to himself before fixing it
>> and doing the build after commits? Not even importing the source for
>> which fix was done ? why half work ?
>
> Can't answer that and don't want to guess. ;)
>
>
> Let me point out the following, though:
>
> This would be less of an issue, if the package had a maintainer instead of
> a non-responsive one.
>
I request FISco member attention here. The non-responsive maintainer
policy was initiated long ago here.
It might be that the Wiki explains how to contact FESCo.
Meanwhile it would be nice if you reverted the changes in cvs.
Some of them are confusing, such as the GPL+ -> GPLv2 change,
which is not explained in the spec/changelog, or the duplicate
directory inclusion.
2:59 a.m.
2009/1/13 Michael Schwendt <mschwendt(a)gmail.com>:
[..]
>
> I request FISco member attention here. The non-responsive maintainer
> policy was initiated long ago here.
It might be that the Wiki explains how to contact FESCo.
Well this thread already is part of process.
Meanwhile it would be nice if you reverted the changes in cvs.
Some of them are confusing, such as the GPL+ -> GPLv2 change,
which is not explained in the spec/changelog, or the duplicate
directory inclusion.
* Sun Jan 11 2009 Rakesh Pandit <rakesh(a)fedoraproject.org> - 0.8.1-1
- Updated to 0.8.1, fixed .desktop file and license tag.
- Fixed Unowned directories.
It is mentioned. I don't see a point in reverting, but feel free to
revert if you think it is worth.
--
rakesh
3:21 a.m.
On Tue, 13 Jan 2009 14:29:17 +0530, Rakesh wrote:
[..]
>>
>> I request FISco member attention here. The non-responsive maintainer
>> policy was initiated long ago here.
>
> It might be that the Wiki explains how to contact FESCo.
>
Well this thread already is part of process.
> Meanwhile it would be nice if you reverted the changes in cvs.
> Some of them are confusing, such as the GPL+ -> GPLv2 change,
> which is not explained in the spec/changelog, or the duplicate
> directory inclusion.
>
* Sun Jan 11 2009 Rakesh Pandit <rakesh(a)fedoraproject.org> - 0.8.1-1
- Updated to 0.8.1, fixed .desktop file and license tag.
- Fixed Unowned directories.
It is mentioned. I don't see a point in reverting, but feel free to
revert if you think it is worth.
I won't touch spec files which are overwritten randomly.
The changelog entry is poor, because it's incomplete. It says "fixed
license tag" without giving a rationale. It doesn't explain what was wrong
about the previous license tag. And it doesn't mention what the tag was
changed to. You simply discarded (= overwrote) the old comment that
explained the previous license tag.
According to https://fedoraproject.org/wiki/Licensing#Good_Licenses
the previous tag was correct.
%dir %{_datadir}/%{name}
%{_datadir}/%{name}/
The %dir entry is superfluous.
3:43 a.m.
"""
But what prevents one to assigning bugs to himself before fixing it
and doing the build after commits? Not even importing the source for
which fix was done ? why half work ?
Can't answer that and don't want to guess. ;)
""""
This was shit which made me slip.
Well when one (here me) slips on someone's shit, s/he is bound to be a
culprit of making the place bad and making more mistakes.
Reverting.
--
rakesh
5:18 a.m.
On Tue, 13 Jan 2009 15:13:17 +0530, Rakesh wrote:
"""
> But what prevents one to assigning bugs to himself before fixing it
> and doing the build after commits? Not even importing the source for
> which fix was done ? why half work ?
""""
This was shit which made me slip.
Well, at least the files in cvs were tagged properly.
You somehow managed to ignore that and started with a lower %release:
symbolic names:
gdmap-0_8_1-3_fc11: 1.12
gdmap-0_8_1-1_fc11: 1.10
^-- these are your tags
gdmap-0_8_1-2_fc11: 1.9
F-10-split: 1.8
gdmap-0_8_1-1_fc10: 1.8
gdmap-0_7_5-8_fc10: 1.7
F-9-split: 1.5
gdmap-0_7_5-7_fc9: 1.5
Well when one (here me) slips on someone's shit, s/he is bound to
be a
culprit of making the place bad and making more mistakes.
Reverting.
The thing that bugs me is that you try to blame other people in
justification of your own mistakes. In the original post, and also in the
private messages. Okay, Matt forgot to commit the source, most likely
while committing fixes for other build failures. So what? If the package
had a maintainer, he would notice the build failure and fix this small
mistake. The pkg is orphaned, however.
Current status of gdmap in cvs now is that on three branches, %version and
%release values in the spec have been decreased and are lower than latest
tag. Whoever will touch the pkg next will probably run into this trap and
then need to examine the tags. And the desktop file patch is missing, too.
I mean, if you want to take over maintainership of gdmap, just apply
for ownership in pkgdb and fix the package finally. If you don't want
ownership, changes ought to be only minor.
6:06 a.m.
2009/1/13 Michael Schwendt <mschwendt(a)gmail.com>:
On Tue, 13 Jan 2009 15:13:17 +0530, Rakesh wrote:
[..]
The thing that bugs me is that you try to blame other people in
justification of your own mistakes. In the original post, and also in the
private messages. Okay, Matt forgot to commit the source, most likely
while committing fixes for other build failures. So what? If the package
had a maintainer, he would notice the build failure and fix this small
mistake. The pkg is orphaned, however.
Well I have already agreed of using old working copy and not checking
diffs painstakingly. Between your commit in devel also ignored source
import and build. You had updated to new version and didn't bothered
to update the source and support your statement with a false argument
that "if it had a maintainer". Package should not be left it that
state.
Current status of gdmap in cvs now is that on three branches,
%version and
%release values in the spec have been decreased and are lower than latest
tag. Whoever will touch the pkg next will probably run into this trap and
then need to examine the tags. And the desktop file patch is missing, too.
I am getting back the dead file and doing the fix. Give me some breath.
--
rakesh
6:50 a.m.
On Tue, 13 Jan 2009 17:36:59 +0530, Rakesh wrote:
> On Tue, 13 Jan 2009 15:13:17 +0530, Rakesh wrote:
>
[..]
>
> The thing that bugs me is that you try to blame other people in
> justification of your own mistakes. In the original post, and also in the
> private messages. Okay, Matt forgot to commit the source, most likely
> while committing fixes for other build failures. So what? If the package
> had a maintainer, he would notice the build failure and fix this small
> mistake. The pkg is orphaned, however.
>
Well I have already agreed of using old working copy and not checking
diffs painstakingly. Between your commit in devel also ignored source
import and build. You had updated to new version and didn't bothered
to update the source and support your statement with a false argument
that "if it had a maintainer". Package should not be left it that
state.
You are mistaken. I am completely innocent here.
It was not me who did the version upgrade. Check your facts, please.
The only thing I did was to commit a spec file fix in devel for an
unowned directory and leave it to the old or new package maintainer to
decide whether and when to rebuild in Rawhide. Typically, maintainers
[even some who have been non-responsive for a few weeks] take the
chance and apply other updates [such as new version upgrades - hint;) ].
And even if I had noticed the missing tarball upload, it would not have
been my obligation to fix it. Rather I would have tried to find out the
reason for it.
10:57 p.m.
On Tue, Jan 13, 2009 at 3:59 AM, Rakesh Pandit <rakesh.pandit(a)gmail.com> wrote:
2009/1/13 Michael Schwendt <mschwendt(a)gmail.com>:
[..]
>>
>> I request FISco member attention here. The non-responsive maintainer
>> policy was initiated long ago here.
>
> It might be that the Wiki explains how to contact FESCo.
As the new FESCo chair, my preferred form of contact in the trac
instance at https://fedorahosted.org/fesco, but any method works
(though if it need follow-up, it will ultimately end up there even if
I file it myself).
Well this thread already is part of process.
That's true. Looking at the two FTBFS bugs, I don't see the required
pings in there. Debarshi, did your mails bounce? If so, that's enough
to short-circuit the process. If not, I'd like to give him awhile to
respond as outlined in the policy (yes, I realize that the bugs are
very old and a response is unlikely).
12:45 a.m.
Debarshi, did your mails bounce? If so, that's enough
to short-circuit the process. If not, I'd like to give him awhile to
respond as outlined in the policy (yes, I realize that the bugs are
very old and a response is unlikely).
Actually I do not remember whether they bounced or not. I have CC'ed
him again in this email so lets see what happens. I also find that
Michael Schwendt had emailed him regarding gdmap on an independent
thread without any response.
Cheers,
Debarshi
12:55 a.m.
As the new FESCo chair, my preferred form of contact in the trac
instance at https://fedorahosted.org/fesco,
https://fedorahosted.org/fesco/ticket/17
Cheers,
Debarshi
5:33 a.m.
Am Sonntag, den 09.11.2008, 02:44 +0530 schrieb Debarshi Ray:
I would like to initiate the non-responsive maintainer policy [1]
against Damien Durand (CC'ed).
...
Here is another bug pending response for a long time:
https://bugzilla.redhat.com/257721
And yet another one:
https://bugzilla.redhat.com/show_bug.cgi?id=449890
I have asked Damien for a reaction on December 19th 2008, but nothing
happened.
Christoph
5632
days inactive
5699
days old
24 comments
6 participants
participants (6)
-
Christoph Wickert -
Debarshi Ray -
Jon Stanley -
Michael Schwendt -
pablo.martin-gomez -
Rakesh Pandit