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

Dustin J. Mitchell dustin at v.igoro.us
Sun Apr 3 17:16:46 UTC 2011

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

> 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!


More information about the devel mailing list