[Bug 168719] Review Request: gdal

Fri Jun 2 20:09:15 UTC 2006

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: gdal

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

------- Additional Comments From che666 at gmail.com  2006-06-02 16:01 EST -------
(In reply to comment #24)
> In reply to comment #22)
> 
> > > Jerks "stopping by and dropping a Review bomb" don't help anybody. They should
> > > be sanctioned.
> > > 
> > > If Fedora doesn't have a policy on this, it should be implemented.
> > > 
> > #21
> > well then instead of posting in tons of review requests id suggest to work on
> > getting a policy out that doesent hurt progress.
> 
> > i dont see it as review bomb.
> I do. Just have a look at the timeline of Silke's responses. There are many
> months inbetween any response of hers. Have a look at how many times she had
> been asked to respond, ... nothing much since ...
> Finally, this is not the first incident of this type with Silke - IIRC, the same
> has happened in Fedora.US. - So, I am not negative, I am drawing conclusions
> based on former contacts with her.

Yes i can see that. i can also see your point of view. but in the end the really
important stuff is to change things in general. so there must be a good solution
 about this.

> 
> As it seems to me, her opinion is, she can "stop by", "drop her spec" and let
> others polish it - She should learn she's in error.
> 
> > why not deal with it rather in a manner as with orphaned packages -> orphaned
> > review request. someone else can take over and can continue to work on the
> > existing base.
> I am opposed to doing this, because this would encourage people to perform
> "drive-by review request bombs". Instead, people should to understand that if
> they submit a package for review, it's their baby they are dropping and they'll
> be expected to take care about it in future.
> 
> If that's not acceptable to them, they 'd better stay away from FE.
>  
> > i want progress not wheel reinvention by having someone else starting from
> > scratch and having all the stuff repeated over and over.
> Well, I am not opposed in somebody else adopting Silke's package. But it won't
> be me - I am not her coding-monkey. 

no one wants to push you into the role of the maintainer. seriously wasnt my
intention.

> 
> > gdal is an important key component for various interesting things.
> Exactly, that's why I want to see this "damn thing" nailed down.

same here.

> 
> Actually, I want
> * Silke to wake up and start cooperating
>  or 
> * some volunteer to take over her package
>  or
> * somebody closing this RR, giving others the liberty of resubmitting a new one.

like above id still say that there should be some rules nailed down.

> 
> > also e.g. in the case of initng ...
> initng and my other very friend elektra are completely different cases. IMO,
> these packages are a million miles away off from being ready for public use.

but theres fedora specific work to be done. the initng daemon is ready in the
next release probably because all buildwarnings been fixed and it also works on
x86_64 pretty well already.

the scripts have to be tweaked in a fedora special way at times so theres a good
point to start off the work.
i can see your point of view that this is development work... but thats life...
with a project like replacing the init system you cant just go there alone and
fix it up in a day. i think that the bugzilla thread helped alot in getting a
dedicated place to get the right things together to fix all open issues that
arise or are brought up in this and future release to block it from inclusion
into extras.
thats the point of a review. i use initng on 2 fedora boxes personally. a
thinkpad r51 and a x86_64 desktop box.
having the thread really fired up lots of work that might not have happened
without it. i wouldnt have looked at it either and also submitted a few small
patches upstream already.
> 
> In case of gdal the situation different: This simply is a case of a submitter
> being non-responsive for reasons I can only speculate on. 

yeah but in both cases my conclusion is the same. there needs to be a pinned
down rules what is supposed to happen and not. e.g. in this case asking for
someone to takeover i think is a better thing. like on the mailinglist.

elektra is again completly different because initng offers undoubtfully features
 certain interest groups are missing yet and theres no comparable other stab at
it currently.

elektra though is something that requires changes in alot other packages to be
useful.... unless... someone goes and makes bindings to all scripting languages
with swig. then people could just use it for some projects if they fill its
nice. its there anyways. some people are interested in it enough to maintain a
package.
I am also not yet sure though if it would be my taste

> 
> > hope you dont take the response as offensive.. its not meant to be.
> Understood.
> 
> 

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.