[Buildbot-devel] GSoC Proposal (draft) : Consistent, Efficient Source Steps

[Pradeepkumar Gayam]

On Sun, Apr 3, 2011 at 10:46 PM, Dustin J. Mitchell <dustin at v.igoro.us>wrote:

> This looks good to me.  Others should feel free to chime in, too.
>
> On Sun, Apr 3, 2011 at 12:57 AM, Pradeepkumar Gayam <in3xes at gmail.com>
> wrote:
> >  Fresh
> > ~~~~~~
> > This should be pristine working directory, either completely fresh clone
> or
> > created by doing 'hg purge --all', but later one is not as fresh as the
> > first. Difference between this mode and previous mode should be defined
> > clearly. Or should this be replaced by clobber? Sometime users may want
> to make
> > a new clone even at the cost of network traffic. If not what is the
> difference
> > between this and clobber?
>
> This has been the sticky wicket (congrats to India, by the way) on
> this project to date.  As far as the proposal, I suggest two things:
> first, remove the questions from this section, and just say that there
> are unresolved questions about whether this mode is needed.  Second, I
> would like to see a sentence or two in the schedule describing your
> plan for getting *past* this issue in a definite time period.  One way
> to do that may be to collect some of the situations users need to
> address, and then give examples of how your implementation would
> address those situations.  Your summer project should make most of the
> situations *possible*, but only needs to implement situations that are
> already possible in the current version.
>
> This reminds me, there is an aspect of Source steps which I do not see
> addressed here -- fallback behaviors.  If an update fails, Buildbot
> will automatically fall back to a clobber.  Some version control
> systems cannot switch between branches, for example, and will fall
> back to a clobber without even trying to update when switching
> branches.
>
> > Timeline
> > ========
> >
> > Community bonding period
> > ~~~~~~~~~~~~~~~~~~~~~~~
> > Reading API documentation and code, get familiar with code.
> >
> > 1. Discussion and decision about various mode and properties of
> > various source step
> [1 week] Till May 30
> > 2. Reading about different version control systems and finding out
> > various common funtionalities                                    [1 - 1.5
> weeks] Till Jun 9
> > 3. Start writing code. Write source step for mercurial
>  [1 week] Till Jun 16
> > 4. Write source step for Git and SVN                                   [2
> weeks] Till Jun 30
> > 5. Code for CVS
> [1 week] Till July 7
> > 6. Write tests and fix issues (if any)                           [Till
> midterms]
> > -- Midterm evaluations
> > 6. Code for bzr
> [1 week] Till July 22
> > 7. Code for Darcs
> [1 week] Till July 29
> > 8. Code for P4
>  [1 week] Till Aug 5Th
> > 9. Write tests and fix issues (if any)                             [Till
> finals]
> > 10. Wind up and start submitting code to google
>
> I would like to see the community bonding period overlap with steps 1
> and 2, rather than being done in sequence.  Discussions naturally take
> a long time, particularly when emails bounce back and forth between
> IST and North American timezones, so it's best to leave lots of room
> for them.  Also, you should probably expand the time alotted step 3 --
> the first implementation will be the hardest, since you'll face
> unexpected difficulties.  For the next few version-control systems,
> those difficulties will, at least, be expected!
>
> Tests and debugging should happen for each VC as you implement it --
> so step 3 should be "Write source step for mercurial along with
> tests".  You can replace step 6 with "debug remaining issues and merge
> code to master," with the hope of getting code into master before the
> midterm evaluations.  Getting the code merged will require full
> documentation and code review by a few other members of the community,
> and as such may take a full week (although you can get started on bzr
> and Darcs while waiting for the reviews).
>
> As I said at the beginning, this looks good.  I'm looking forward to
> seeing the final proposal!
>

Sorry for the late replay. I was busy with exams. Now I am free.

Thanks for the feedback. I'll update the changes you suggested and drop it
in melage.

Thanks

- Pradeepkumar Gayam

>
> Dustin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20110407/1ead6ea2/attachment.html>