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 > [email protected] > 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@freenode
_______________________________________________ rekonq mailing list [email protected] https://mail.kde.org/mailman/listinfo/rekonq
