10:36 a.m.
I have today merged a lot of stuff into a bunch of repositories. This
work consists of a change in the way morph builds stuff, namely, that it
unpacks the chunks it builds so later chunks can use them as build
dependencies. morph also now has a bootstrap mode, and its repo contains
a baserock-bootstrap script which can bootstrap a rudimentary native
toolchain for Baserock, based on Linux From Scratch 7.0.
I've also renamed a lot of branches, which may cause trouble for people
who merge/pull from gitorious. My apologies: I only realized afterwards
that this is going to be a bit of a mess. Please flame me if you are
inconvenienced.
I've also renamed the core stratum to foundation, since several people
asked be the difference between base (a system) and core (a stratum),
and I'm hoping this will help.
In the future, I hope I can work in smaller jumps so that the merges are
not quite so large.
We should also decide on a branch naming and merging policy at some
point, possibly soon.
10:27 a.m.
On 11/30/2011 04:36 PM, Lars Wirzenius wrote:
We should also decide on a branch naming and merging policy at some
point, possibly soon.
Wouldn't <username>/<description> be enough of a policy for branch
names? And maybe branches without <username> if we work on something as
a group? That sort of policy works well for many other projects AFAIK.
- Jannis
7:32 a.m.
On 05.12.2011 15:27, Jannis Pohlmann wrote:
On 11/30/2011 04:36 PM, Lars Wirzenius wrote:
> We should also decide on a branch naming and merging policy at some
> point, possibly soon.
Wouldn't <username>/<description> be enough of a policy for branch
names? And maybe branches without <username> if we work on something
as a group? That sort of policy works well for many other projects AFAIK.
username/whatever is fine for personal development branches, I agree on
that.
However, there's the bigger issue of how to use shared branches,
especially long-term ones. For example, we might want to do this:
baserock/bootstrap -- used during the toolchain bootstrap process
baserock/stable -- version of upstream used for stable Baserock builds
(no Baserock changes)
baserock/morph -- adds the morphology and nothing else
baserock/bugfix-123 - fixes bug #123 (in whatever bug tracker we
eventually choose)
baserock/feature-foo - adds feature foo
baserock/integration/stable -- merges baserock/stable and baserock/morph
and other branches
In addition to the branches, we need a policy on when stuff can be
merged into branches above. Supposed I make an improvement to the
morphology that I believe should be propagated to the stable integration
branch. Who makes the decision? Is there a release manager or a +1/-1
voting process on the mailing list? Should there be a mandatory code
review, or is it OK to merge if nobody reacts?
At some point we'll add a continuous integration system into the mix.
That'll bring up all these issues again.
http://wiki.baserock.org/Morph/repositories/ has some of my thoughts on
this.
Opinions?
3861
days inactive
3867
days old
2 comments
2 participants
participants (2)
-
Jannis Pohlmann -
Lars Wirzenius