[scribus-dev] patches are ready...

[Cedric Gémy]

I somewhat understand that the patch need to be fixed and avoid as much as
possible to cause new bugs.

I would say :
- trust the community as much as possible. If we people to be responsible,
let them be.
- 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
- 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.

cheers
cedric



2012/9/28 Craig Bradney <cbradney at scribus.info>

> 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
>
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>



-- 
Cédric Gémy
-----------------------------------------------------------------
Formationlibre.org
FlossManualsFrancophone
Association Francophone des Graphistes Libres
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20121001/a7f36ce1/attachment.html>