[rekonq] Re: Keeping the bug tracker in sync

[Andrea Diamantini]

On Friday 21 January 2011 16:18:52 Felix Rohrbach wrote:
> 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.

Yeah! We are here for fun, after all :)

> > > 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.

Another think me and pano started to use is the TARGET feature. This way you 
can show users when the feature will be implemented.
We currently have these targets: the old 0.6, 0.7, 1.0. Plugins.
I prefer using targets over setting bug dependance (eg: settings 0.7-RELEASE 
meta bug and let it depend on the bugs you wanna fix for 0.7)

> > > 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.

Yeah! I probably misunderstood a bit your statement, then. Keeping bug tracker 
in sync is obviously a must for a fantastic project as rekonq is :)

> > > 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?

You can ask God or KDE sysadmins. It's up to you. :D

> Regards,
> Felix
> 
> _______________________________________________
> rekonq mailing list
> rekonq at kde.org
> https://mail.kde.org/mailman/listinfo/rekonq

-- 
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq at freenode
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/rekonq/attachments/20110122/95ff239c/attachment-0001.htm