9:49 p.m.
On Tue, 2017-05-16 at 13:09 +0100, Paul Sherwood wrote:
Hi all,
Hi !
So I want to jump in at the top here and say that this is an ideal time
for us to take a step back and consider/define "What is Baserock" more
clearly.
Sorry if this is thread-hijacking but I think it's basically inline
with this thread, so I'm branching it off with a different subject
heading.
Since I got involved over a year ago, this has never really been very
clear, after spending some time in the project I can tell that Baserock
was an idea which grew and snowballed into various things, the main
components of which I would think are:
o The format and and tooling
o Trove (a continuous aggregator of various revision control systems
and tarballs into git)
o The reference builds (definitions)
With the tight coupling we've had, it's been quite difficult to gain
any traction or widespread adoption of the concepts innovated in this
project, but they are all quite nice things when you take them in more
bite sized pieces.
So I'd like to just break the above down and highlight some things:
Format and tooling
~~~~~~~~~~~~~~~~~~
With BuildStream we've been trying to take the concepts innovated
in the Baserock project and make them applicable to a much wider
variety of use cases, and I think so far we've been successful with
this.
In addition to being able to build full stack operating systems, one
will be able to build and deploy a variety of things such as Docker
images, Bundled applications such as Flatpaks, Snaps or AppImages,
SDKs and standalone runtime environments, Distro specific packages,
etc.
Also we are not tightly coupled to any VCS, making migrations to
BuildStream more user friendly for various projects which have always
been using a variety of upstream tarballs and other repositories,
without stating that one absolutely must use Trove (However I do
think trove is a good idea, and would recommend that Baserock
reference systems continue to use it).
Trove, software aggregation into git
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is a relatively small component of Baserock but I think it shows
great potential on it's own.
When building large complex stacks, whether they are base operating
systems or otherwise, all from source; a system like this helps a
great deal with being able to track stack-wide branches and various
downstream patches. In fact it would be interesting if Trove could
itself have a concept of stack-wide branches and perhaps a frontend
allowing developers to more easily track the work they have applied
across multiple git repositories.
This has always been unidirectional, though; software aggregated into
Trove stays in trove and downstream patches live in git branches.
I think it would be a novel idea if this could be made bidirectional,
or at least assist organizations and developer teams in the
upstreaming of downstream managed work branches - we already have
the lorry plugins/modules for aggregating incoming commits; why
not extend these to allow a developer to:
a.) Work on a git managed repository with an upstream SVN/CVS
b.) Allow the same developer to do either of the following:
b1.) Push downstream git-managed work branches onto upstream
SVN/CVS/HG/BZR branches
b2.) Produce foreign VCS friendly patches that are convenient
for upstream maintainers to merge into their own
repositories that may not be managed with git
Baserock reference systems
~~~~~~~~~~~~~~~~~~~~~~~~~~
I think this is the only thing we should end up keeping under the
"Baserock" banner. Let Trove/Lorry be a separate project.
What I think we need to concentrate on here is becoming a welcoming
and "Safe" venue for people to contribute to the building of some
linux reference builds from scratch.
As Paul mentions below, I have been towing the line about stable
release branches for as long as I have known about Baserock, without
this discipline, Baserock will never be a safe venue for contributing
real integration fixes.
Beyond this, Baserock can also be a venue for demonstrating good
CI practices.
It would also be amazing I think if we could generate documentation
from BuildStream YAML and annotations to rival those of the LFS,
project, maybe even one day we could get the LFS folks on board and
merge the two projects, since they are doing something very similar,
and it's sad to see resources split across various projects doing
almost the same things.
Personally I am most interested in the last point here, I want to know
what are we calling "Baserock" and what are our priorities with the
Baserock project and brand moving forward ?
Best Regards,
-Tristan