<br><br><div class="gmail_quote">On Mon, Sep 19, 2011 at 8:13 PM, Marcel Wiesweg <span dir="ltr"><<a href="mailto:marcel.wiesweg@gmx.de">marcel.wiesweg@gmx.de</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Suggestions like these are fully justified in larger projects. If you look at<br>
the commit log of digikam, you'll see Gilles, me, and Francesco doing the<br>
majority of commits. Who is going to backport bug fixes? Who is going to<br>
maintain the branch? Who is going to test it?<br>
There is another point: A commit freeze forces developers to do bug fixing.<br>
Feature development is fun, bug fixing is tedious. So we need to force<br>
ourselves to do it.<br>
Third, with git, it is possible to have either local commits or even local or<br>
remote feature branches if a larger patch is to be developed.7</blockquote><div><br></div><div> </div><div>I've got your point and i know who is workings the most :)</div><div>someone told me about digikam and i hope that i will tell it to another students, but i can't go faster.</div>
<div>Also i'm sitting on bleeding-edge kde and it's crashing regularly so i can tell it's too far from gnome, but it has tons of features.</div><div>From this point of view, in future i want to do more bugfixing(so it's not tedious for me), but i lack experience.</div>
<div>Commiting can be done in both branches to avoid backporting them. Extra seconds for someone(to write an extra git command) can save someone from lots of work.</div><div> </div><div>Also having few things settled ok from very beginning can make the project grow faster.</div>
<div><br></div></div><br clear="all"><div><br></div>-- <br>Veaceslav<br>