I somewhat understand that the patch need to be fixed and avoid as much as possible to cause new bugs. <br><br>I would say :<br>- trust the community as much as possible. If we people to be responsible, let them be.<br>- a dev version is a dev version and we cannot avoid all bugs that may cause something new, and even testing can help solving. The deal is : how many people use 150svn and how many build patches ? How help could we get from one or other choice<br>
- what means complete : I guess it's difficult to say that something is complete and i would allow users to say in which way a basic implementation could go on. <br><br>cheers<br>cedric<br><br><br><br><div class="gmail_quote">
2012/9/28 Craig Bradney <span dir="ltr"><<a href="mailto:cbradney@scribus.info" target="_blank">cbradney@scribus.info</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 9/28/12 5:18 PM, a.l.e wrote:<br>
> hi craig,<br>
>>  From my recollection of almost if not all patches they were buggy and incomplete. If any have now<br>
>> been fully tested and fixed then please highlight the bugs and final patch files.<br>
>><br>
><br>
> i would say that every patch added to the bug tracker deserves to be rejected or accepted in an<br>
> explicit and timely manner.<br>
><br>
> this morning we had a short discussion about this topic on irc and i'd like to make the following<br>
> proposal to make it more self-explanatory, what the status of a patch is:<br>
><br>
> - for trivial patches like <a href="http://bugs.scribus.net/view.php?id=11101" target="_blank">http://bugs.scribus.net/view.php?id=11101</a> ( [PATCH] fix for resizing<br>
> image frame) the way cezary did looks good enough.<br>
> - for more complex features like <a href="http://bugs.scribus.net/view.php?id=11032" target="_blank">http://bugs.scribus.net/view.php?id=11032</a> ( Patch with<br>
> marks/footnotes feature):<br>
>   - there should be a ticket for the feature itself<br>
>   - each patch should be uploaded in its own ticket, marked as child of the feature request / bug<br>
> report<br>
>   - if the patch is rejected, the ticket gets closed and the contributors is asked to create a new<br>
> ticket with a new patch<br>
>   - if the patch has been made from a git branch, the ticket should mention the name of the branch<br>
> and who has tested it<br>
><br>
> this way it should get easier to track, which patches are waiting to be processed (basically: every<br>
> open ticket that has PATCH in the subject should be processed ASAP).<br>
><br>
><br>
> i still would welcome having more than two persons committing code to the trunk, but if you were<br>
> puzzled about which patches were ready, i think that such mesures can already help make the<br>
> situation a bit better.<br>
><br>
> what do you think?<br>
><br>
<br>
</div></div>Right now, I'd reject all patches, requesting updates.<br>
<br>
All patches were submitted in the past for review, not for committing. They need to be tested by<br>
those who have time for testing.<br>
<br>
Only if and when the work is finished should a bug be raised with a commit request with the testers<br>
approving the commit saying a) existing functionality is not broken and b) the new functionality is<br>
complete and tested.<br>
<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888">Craig<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
scribus-dev mailing list<br>
<a href="mailto:scribus-dev@lists.scribus.net">scribus-dev@lists.scribus.net</a><br>
<a href="http://lists.scribus.net/mailman/listinfo/scribus-dev" target="_blank">http://lists.scribus.net/mailman/listinfo/scribus-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Cédric Gémy<br>-----------------------------------------------------------------<br>Formationlibre.org<br>FlossManualsFrancophone<br>Association Francophone des Graphistes Libres<br>
<br>