[scribus-dev] patches are ready...

[Craig Bradney]

On 9/28/12 5:18 PM, a.l.e wrote:
> hi craig,
>>  From my recollection of almost if not all patches they were buggy and incomplete. If any have now
>> been fully tested and fixed then please highlight the bugs and final patch files.
>>
> 
> i would say that every patch added to the bug tracker deserves to be rejected or accepted in an
> explicit and timely manner.
> 
> this morning we had a short discussion about this topic on irc and i'd like to make the following
> proposal to make it more self-explanatory, what the status of a patch is:
> 
> - for trivial patches like http://bugs.scribus.net/view.php?id=11101 ( [PATCH] fix for resizing
> image frame) the way cezary did looks good enough.
> - for more complex features like http://bugs.scribus.net/view.php?id=11032 ( Patch with
> marks/footnotes feature):
>   - there should be a ticket for the feature itself
>   - each patch should be uploaded in its own ticket, marked as child of the feature request / bug
> report
>   - if the patch is rejected, the ticket gets closed and the contributors is asked to create a new
> ticket with a new patch
>   - if the patch has been made from a git branch, the ticket should mention the name of the branch
> and who has tested it
> 
> this way it should get easier to track, which patches are waiting to be processed (basically: every
> open ticket that has PATCH in the subject should be processed ASAP).
> 
> 
> i still would welcome having more than two persons committing code to the trunk, but if you were
> puzzled about which patches were ready, i think that such mesures can already help make the
> situation a bit better.
> 
> what do you think?
> 

Right now, I'd reject all patches, requesting updates.

All patches were submitted in the past for review, not for committing. They need to be tested by
those who have time for testing.

Only if and when the work is finished should a bug be raised with a commit request with the testers
approving the commit saying a) existing functionality is not broken and b) the new functionality is
complete and tested.

Thanks
Craig