[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Non-responsive maintainer process for Damien Durand



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]