[rekonq] Re: Keeping the bug tracker in sync
Felix Rohrbach
fxrh at gmx.de
Fri Jan 21 16:18:52 CET 2011
Hi Andrea,
Am Freitag, 21. Januar 2011, 00:45:53 schrieb Andrea Diamantini:
> I'm here from the beginning and I really can say this is NOT true. Yes,
> maybe some reports are not discussed a lot or lived in the bug tracker
> until next bugfixing period (that is going to be in 10 days).
> I can also say that a lot of the people here started contributing opening a
> bug report.
> Obvious, if you think we are here ready to implement all your wishes for
> you...
Ok, maybe it was just bad timing. Anyway, please notice that there are exactly
zero wishes from me for rekonq on bugs.kde.org, Actually, I implement features
that I want to have by myself.
> > 1. If it's something that will take some time to fix, but we can
> > reproduce the bug and we think it's important, it would be nice to say
> > that we are working on it. We could use the flags UNCONFIRMED, NEW and
> > ASSIGNED TO for that, too.
> >
> > 2. If there are any problems while fixing the bug and you stop working on
> > it (e.g. some webkit dependencies or design problems), name them in the
> > report. The reporter may not understand them, but he sees that there is
> > some work, and other developers looking at the bug don't have to discover
> > the problems, too.
>
> These are good ideas.
>
So what do you say about using these flags (UNCONFIRMED for new bugs, NEW for
bugs we think about fixing and which we can reproduce and ASSIGNED TO to show
someone is working on this)? I can care about them if I get admin rights.
> > 3. If you don't want to implement some idea, or if you want to have it
> > another way, please write that, too. The user does not need to wait any
> > longer, he may give some reasons why this feature is needed, but even
> > more important: Developers searching the bug tracker for things to work
> > on won't spam review board with patches you don't want to merge. If you
> > deny the request then, you have two angry guys: The reporter and the
> > patch creator ;-)
>
> I don't think this is the right way to think about. Bugzilla is not the
> center of our development and we don't implement things just because
> someone asked it.
> rekonq project started to create a lightweight browser with an easy and
> clean design. Period. We are not cloning konqueror or firefox.
> Just following people hints, you are going to implement feature A and the
> ability to let feature A optional and redesign feature A to follow firefox
> implementation and the option to change it to behave as chrome.
> And obviously you are going to reimplement ALL konqueror features.
> So please, when you are going to implement something that is not for your
> pleasure, ask in mailing list, before. That's the place.
I don't want you to integrate every feature someone likes to have. I just
would prefer if you would close wishes or bug reports that you don't want to
have (or let that someone else do that). Also, I don't want to shift
development completely to our bug tracker. Discussions should happen on the
mailing list, but the bug tracker should get the result, too. Of course, I can
ask on the mailing list before implementing a feature, but that takes time
and, with growing developer count, would spam the mailing list. If we write
the results to the bug tracker, we keep the related things together.
> > What do you guys think about this? I would volunteer to keep the bug
> > tracker up to date (like after a mailing list/IRC discussion), but there
> > are things everyone has to do (like reporting about problems while
> > fixing), so I need your support for that.
>
> That's good!
> You may probably need admin bits for that.
Who can give me these?
Regards,
Felix
More information about the rekonq
mailing list