[Buildbot-devel] repository + Source steps

[Tobias Oberstein]

Hi Dustin,

Thx for attribution, for your comments and for bringing the whole topic up anyway.

Since this is my first post on this list, let me also thank all the BuildBot
developers for creating this nice tool and making it available to others!

> [*] And, I should note, in general everyone thinks that their twist is
> so self-evident that "everyone does it this way" and it should just be
> the default behavior.  Not so!

Couldn't agree more;) There are different scenarios, different workflows each
valid on their own in a particular situation.

I think BuildBot should take a neutral position w.r.t. approaches, and merely
be flexible and allow for choice. This is anyway a real strength of it today.

Let me use this post to describe my scenario/workflow. If others do describe
theirs, maybe we can collect thus reqs on a "story level". Some reference to
judge changes.

So here is _a_ scenario:

A1
Multiple developers, having multiple repos, working on multiple projects.

A2
We use Git and a distributed workflow. That is each developer works on his own
Git repos, others pull. No "shared" repos.

A3
Developers develop on their local machines, and push stuff to their server
hosted "public" (bare Git) repos to let others pull. There is one Git host G,
hosting the "public" repos of all developers.

A4
Developers each have multiple Git repos on G, each repo of a developer resides
below his Unix home, and each repo contains multiple branches. Developers may
create new repos or move existing ones as they like.

A5
A developer may have multiple repos per project, but a single repo only
contains stuff for one project.

A6
We want developers be able to build any revision on any branch on any of their
repos on G when they want to and don't build if they don't want to.

With "build" I mean build via BuildBot for a couple of target platforms for
developers to test on target platforms others than they develop locally on.

A7
We like to have fast, incremental builds (VCS update + incr. build).

A8
If we use VCS hooks to trigger builds (see my subsequent mail), we want them
to be able to push to G, triggering a build and push to G without triggering
a build.

A8
We want them to control on which platforms to build (at least predefined sets
thereof, but ideally also their chosen list)

A9 Maybe: let developers control what variant to build (release, debug, ..)
and control special build parameters.

As we're still thinking about workflows, that list might still be incomplete /
subject to change.