On 03/25/2013 01:27 PM, Gonzalo Odiard wrote:
While I agree in theory with all this,
we can improve our actual situation if we look at our resources,
time and people.
* Time: we don't have a schedule, then feature discussion can't start.
We can improve if we have a clear path and start to
Hey Daniel,
thanks for the write-up!
It is true that patch review, especially of non-bugfix patches is slow
and can be sometimes frustrating for all parties involved, the reviewer,
the maintainer and the submitter.
To improve that situation, I think we have to put some lights on all
those
On Mon, Mar 25, 2013 at 7:37 AM, Simon Schampijer si...@schampijer.de wrote:
Hey Daniel,
thanks for the write-up!
It is true that patch review, especially of non-bugfix patches is slow and
can be sometimes frustrating for all parties involved, the reviewer, the
maintainer and the submitter.
While I agree in theory with all this,
we can improve our actual situation if we look at our resources,
time and people.
* Time: we don't have a schedule, then feature discussion can't start.
We can improve if we have a clear path and start to define what features
will be included in the next
On 25 March 2013 13:27, Gonzalo Odiard gonz...@laptop.org wrote:
While I agree in theory with all this,
we can improve our actual situation if we look at our resources,
time and people.
* Time: we don't have a schedule, then feature discussion can't start.
We can improve if we have a clear
Hello,
I think patch reviews are taking too long. It's probably a well known
issue but I will give a couple of examples as a proof.
Online services patches, unreviewed for more than one month
http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041808.html
Unreviewed for more than one
On Sun, Mar 24, 2013 at 3:30 PM, Daniel Narvaez dwnarv...@gmail.com wrote:
Hello,
I think patch reviews are taking too long. It's probably a well known
issue but I will give a couple of examples as a proof.
Online services patches, unreviewed for more than one month
7 matches
Mail list logo
