[rekonq] NO MERGING ISSUES

[Paweł Prażak]

On Sat, Apr 18, 2009 at 2:58 AM, Andrea Diamantini <adjam7 at gmail.com> wrote:

> I wanna start this mail thanking all you again for your fantastic work
> and help to rekonq project.
> Questions about the no merging issues during these holidays are basically
> two
> I'm seeing in your clones.
> Clones are actually rekonq forks and as this always helps features and
> ideas
> to be implemented lets discerning quite hard.
>
> So here are some small rules to follow to help at best rekonq dev:
>
> 1.
> NO large commits. as avaddon just explained in one post some days ago (i
> read
> all just this morning), we have one fantastic rule:
>
> ONE feature <= ONE commit.


Yes this is very good to have small easy to understand commits, that's what
I'm trying to learn myself to make coding together nice and smooth
experience, but sometimes this isn't simple, when one bug is triggered by
another or stuff like that.


> So all we can push one feature with one or more commits, but one commit has
> to
> be about just 1 feature.
>
>
> 2.
> NO features non approved in master. For example I saw a beautiful side
> panel
> implementation. But rekonq will never have a side panel. That's because
> side
> panels are usability evils and I'd like rekonq to be "easy".


"Never say never", actually now it have ;P Maybe they are usability
nightmare for you but not for everyone.
I think side panel is basic feature, all browsers have one and I think it
should be implemented in modular way.
I was thinking about moving all side panel code to shared library, so users
who don't want to use it won't have to pay for it.

3.
> NO unuseful re-implementations. I really spent one hour to review pawel
> Download class refactoring, that was able just to introduce just one bug
> (issue #?) and no more features. Why do we feel the needing of doing such
> things?? And just to be honest, that class is copied from kget code.


I don't fully understand what do you mean by "copied from kget code" because
I've never seen kget's code.
Only because you don't understand why some changes were made doesn't mean
they are useless.
All refactoring was done in the sake of maintainability and some new
features were added in process.
As well as making download actually work instead of "work sort off" and
crash on background download.

"Download class refactoring, that was able just to introduce just one bug
(issue #?) and no more features." - what commit introduced which bug?


I used side panel and download class just as examples about my ideas. You
> are
> obviously free to do as you like, but please, do it in separate branches
> and
> push masters nearer.
>
> --
> Andrea Diamantini
> MAIL: adjam7_AT_gmail_DOT_com
> WEB: http://www.adjam.org
> IRC: adjam_AT_freenode
> PGP/GPG : 91A712C1
> Fingerprint: 571E DFF4 19EF A597 2CCD A811 6CB6 3538 91A7 12C1
>
> tadarattadara tattà tatatatatà tadarattadara tattà tattattattattà..
> (me, taking a shower...)
> _______________________________________________
> rekonq mailing list
> rekonq at kde.org
> https://mail.kde.org/mailman/listinfo/rekonq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/rekonq/attachments/20090418/89deb584/attachment.htm