Re: GSOC idea: build in scripts and cleanups

[Robert David <robert.david.public@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 2329 bytes --]

Dne pondělí 04 dubna 2011 20:09:00 Junio C Hamano napsal(a):
> Robert David <robert.david.public@gmail.com> writes:
> > 1) Pre-coding time
> > 2) 1-3 week
> > 3) 4-5 week
> > 4) 6-7 week
> > 5) 8-11 week
> > Extend the C code to the state it should be.
> > Adopt other git commands to work with the new interface correctly.
> > Test extensively.
> > Update documentation where needed.
> > 
> > 6) 12 week
> > Write more documentation, to document what was done and how.
> > Correct bugs and test.
> 
> I am afraid to say that the above schedule is too ambitious and does not
> leave any time for reviews and re-rolls.  Please keep in mind that
> historically patch series by more experienced contributors of substantial
> size (comparable or even smaller scale than the topic you are proposing)
> all typically took three or four review-reroll cycles, if not less, and we
> don't automatically get extra review bandwidth just because GSoC is going
> on.

Thanks, this is what I wanted to hear. 
I wrote the proposal from my point of view. I'm prepared to change the size of 
the task and schedule on mentors and developers comments.
I'm also trying to understand your development cycle, to get that more 
precise. But I want also say that I'm prepared for a lot of work. I have the 
time in this period.

If I understand correctly, you mean to divide this task in more terms? And do 
less more precise. Test more, etc.

Robert 

> 
> I am starting to suspect that it might make sense to say "as far as GSoC
> participation is concerned, we would call a topic "merged upstream" when
> it hits 'next', even if it is not ready for 'master' at the end of the
> term".
> 
> What do regular reviewers and potential mentors think?  Perhaps we have
> more stringent quality requirements than other open source projects that
> take "commit first, review and fix as necessary" cycle, and they may
> declare success when "commit first" happens.  If that is the case, 'next',
> whose definition is "without glaring design and implementation bugs and
> fit enough for dogfooding, but needs extra polish", might be a better
> success criteria to be fair for our students.
> 
> I am not in the mentor pool and I would rather not to be to stay neutral,
> so I'll leave it up to the mentors.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 230 bytes --]