[GoOSe Project / Ascendos cross post] Enterprise Linux Rebuild Collaboration Manifesto
Derek Carter (aka goozbach)
the best way to communicate to both groups. I've enabled non-member
moderated access to the GoOSe Project mailing list to facilitate
discussion. Please reply to both goose...@googlegroups.com and
ascend...@lists.ascendos.org with comments.
A couple of people have approached us at the GoOSe Project about the
Ascendos project. Consider this our 'official' response to the questions
they asked.
The below content is shared as a collaborative document found at [1].
Please check that location for the most up-to-date information.
[1]https://github.com/gooseproject/main/blob/master/brainstorm/collaboration.rst
The GoOSe Project is only one of the upstream enterprise Linux rebuild
projects. We are excited to work together with others in the EL rebuild
space, and feel that there is plenty of room for separate but
collaborative communities. The similarities in our goals should work for
our mutual benefit. And the differences which exist should only
strengthen us all.
So we need to answer this question:
In what can we collaborate?
What follows are the results of a pretty free-form brainstorming session
we had at one of the GoOSe Project's weekly meetings.
* Shared infrastructure
Sharing certain pieces of infrastructure makes a lot of sense.
* Upstream Sources Mirroring -- Although there are various places
that one can find the upstream sources having another collaborative
mirror for the various rebuild projects could be beneficial.
* Cross Project Backups -- Doing backups is difficult, if we spread
out the load of backing up our repositories, scripts, look aside caches,
configuration files we could restore in the case of a catastrophic failure
* Project Mirroring -- Distributing the final product of our efforts
can be daunting as well. Again, being willing to mirror the ISOs or
packages of the other projects will help make all the products better
accessible.
* Help Building and Configuring Non-Shared Infrastructure -- Most of
these projects are using the same or similar tools, Koji for example.
Working together on setting up these systems will help reduce the amount
of constitutional knowledge(better phrase here?)
* QA help
* Building QA Test Suites -- Due to the common ancestor of these
projects, a common set of test cases could be useful. This should be
extensible/fork able for the test cases which would be specific to a
certain project.
* Cross-QA Checks -- A very good way of testing if something is
correct is having someone else run the same test as you. Sharing the QA
work and results would reduce the need for everyone to figure things
like this out for themselves. I think the best example of this would be
the information needed to verify ABI compatibility.
* Documentation
Of the many places where EL rebuild projects can easily collaborate,
the best return of investment is sure to come from the documentation
side. Again the common ancestor of these distribution works in our
favor. There is a great need for documentation and how-to's. Sadly most
good documentation is out of date. Thus a collaborative documentation
effort would help lighten the load and keep things better up to date.
Other documentation-like ideas include common wikis, a common
askbot-style system, etc.
* Distribution Creation Information
The main product of all these different projects is a Linux
distribution. Sharing the problems and various solutions to compile and
create this product helps to make the entire community better. Things to
share include:
* package build order
* package meta data
* package content signatures
* ABI compliance information
* upstream trademark issues/problems
* missing build dependencies
* Community Enhancements
As the number one goal of the GoOSe project is to build the
community, we spend a lot of time thinking about the ways to enhance the
*ENTIRE* community ecosystem. We plan on sharing what we learn for best
practices for:
* community management
* meetings
* organizational structure
* updates to your community about your progress
We also plan on working on spreading the word about our community
goals. Some tools to help us accomplish this include:
* EL Rebuild Planet -- Would others be interested in joining this?
* Social Networking -- Twitter, Identica, Facebook, etc.
We also want to practice what we preach about making this truly a
community based idea. Please see
https://github.com/gooseproject/main/blob/master/brainstorm/collaboration.rst
to help us improve this document.
With a stronger community around our projects we can all have a better
time accomplishing our goals. And hopefully making the world a little
bit better than we found it :).
--
Derek Carter
aka goozbach
Clint Savage
Nice to make your acquaintance. I'm the primary developer here at the
GoOSe Project. Most of my work has been focused around building GoOSe
Linux 6.0 and the tools to make the process simpler for anyone to
repeat overall.
See my responses inline.
> Hello,
>
> My name is Douglas McClendon, I am the current lead developer of
> Ascendos, having taken over for Troy Dawson in early september after he
> was lured away from ScientificLinux/Ascendos by employment with RedHat.
>
> I'm not sure if the people approaching you that you referred to was our
> project leader Andrew Cutler or others, though Andrew had mentioned
> GoOSe once or twice. I really hadn't looked into the project until just
> now as I saw the github homepage url you provided. The website stored as
> git repo I do like.
The initial email was from Andrew. I think a few other folks visited
us in our #gooseproject irc channel on freenode. Come lurk if you
like, we'd love to chat with you about what you've been doing. I'm
sure we'll have a good bit of knowledge exchange and maybe can work
out a plan for further collaboration.
> Anyway, I'll leave it to Andrew to provide a more 'official' response to
> the many good things you brought up, but I'll make a few quick comments.
>
> First, of course yes, I do see much room for collaboration in many of
> the below areas you mention.
>
> One thing that I couldn't find in the first few minutes of looking over
> your project, is how to access/inspect/review/learn-from the current
> state of your build. You have a Download page with 777/1800 packages
> built, but with a caveat that the information is not accurate. Below
> that you have 3 download links to 'skein'/'grapple'/'chase' but those
> are all broken links as is the 'about' tab which I was hoping would give
> me insight into the history of your project.
You are right. we're still in the process of developing that site and
the community around the site. The goal for the website was to have a
simple rss feed or something AJAX-like that would pull that
information when you sat on the site. It clearly doesn't work, but we
do at least have some basic information there.
As for our current build status, you can check out
http://koji.gooselinux.org as we've done most of our builds to date.
There are around 300 failed builds at the moment and several others
we're going to need to scrub out upstream material, or generate our
own package. I plan to work on these fixes today and tomorrow and hope
to have most of it resolved by the end of the weekend. We'll see how
it goes.
> Perhaps the essence of what I feel our project is about, vs the
> canonical example- CentOS, is making the build and development process
> completely open/transparent to the public so that anyone can use it as a
> reference. I.e. my immediate response is-
Our goals are similar here. The main difference we discussed was that
we wanted to de'bus'ify the process. In other words, if one person
gets removed from the process by a bus or a velociraptor, the project
continues to function at a fairly similar pace. At the current moment,
that means removing barriers for contribution and making the process
simple enough that anyone could come in and make that work. We want
our community to work first and foremost and the release is a result
of this community engine working on all cylinders.
I'm not saying that Ascendos doesn't aspire to this, as I don't have
any proof against that. I would suspect indeed, that you have every
intent of de'bus'ifying your process as well. Let me know what you
think about this direction. I bet there is more in common than it
currently appears.
> I'm currently having trouble composing a 6.1-x86_64
> traditional(non-live) installer (that works), and if you have already
> got one built that does work, I'd love to see the specific compose
> commands you used (and tools versions, build environment details). I
> see several git-repos, but can you point me at the start of the path
> that you would expect the public or future members of your community to
> use to help them find the answer to that. I.e. do you have a
> 'start-here' kind of document for how someone could reproduce your build
> thus far? The analog for our project would be something like what we
> have in-
Douglas, I've been watching the ascendos mailing list with much
interest. I really like what you are doing. At the moment, we're still
focusing on 6.0 and have plans to get an alpha 6.0 out by EOY 2011. We
are pretty darn close to making that a reality. I'd love to talk with
you more as we approach 6.1 builds in early 2012.
> ascendos.org/wiki/BuildTesting
> (also useful are)
> ascendos.org/wiki/DistroTesting
> ascendos.org/wiki/Development
>
> Right now I'm just heads-down trying to get a first vaguely working pass
> of the entire up-to-current packages and pointreleases built (and
> trivially reproducible by anyone interested from looking at our existing
> scripts and documentation). Once I'm past that I'll have more bandwidth
> for the many wider issues and collaboration opportunities outside the
> core OS output generation tract.
Awesome. We look forward to working more with you and the Ascendos
project at large. I'm very excited to get this communication started
and start working together to grow the Enterprise Linux Rebuild
community!
Cheers,
Clint
Andrew Cutler
> Douglas,
>
> Nice to make your acquaintance. I'm the primary developer here at the
> GoOSe Project. Most of my work has been focused around building GoOSe
> Linux 6.0 and the tools to make the process simpler for anyone to
> repeat overall.
Thanks for introducing yourself to the list. I think I dropped you
guys a line a while back, and didn't hear anything back. In any case
it's good to make contact. I've tried to encourage it by instilling a
culture of openness in the project, so we are definitely receptive to
contact from projects, groups, or individuals with similar aims.
>
> See my responses inline.
>
>> Hello,
>>
>> My name is Douglas McClendon, I am the current lead developer of
>> Ascendos, having taken over for Troy Dawson in early september after he
>> was lured away from ScientificLinux/Ascendos by employment with RedHat.
>>
>> I'm not sure if the people approaching you that you referred to was our
>> project leader Andrew Cutler or others, though Andrew had mentioned
>> GoOSe once or twice. I really hadn't looked into the project until just
>> now as I saw the github homepage url you provided. The website stored as
>> git repo I do like.
>
> The initial email was from Andrew. I think a few other folks visited
> us in our #gooseproject irc channel on freenode. Come lurk if you
> like, we'd love to chat with you about what you've been doing. I'm
> sure we'll have a good bit of knowledge exchange and maybe can work
> out a plan for further collaboration.
Sounds like a plan. As I've always said our aim is to avoid
duplication of effort, and to not "invent wheels".
>
>> Anyway, I'll leave it to Andrew to provide a more 'official' response to
>> the many good things you brought up, but I'll make a few quick comments.
>>
>> First, of course yes, I do see much room for collaboration in many of
>> the below areas you mention.
>>
>> One thing that I couldn't find in the first few minutes of looking over
>> your project, is how to access/inspect/review/learn-from the current
>> state of your build. You have a Download page with 777/1800 packages
>> built, but with a caveat that the information is not accurate. Below
>> that you have 3 download links to 'skein'/'grapple'/'chase' but those
>> are all broken links as is the 'about' tab which I was hoping would give
>> me insight into the history of your project.
>
> You are right. we're still in the process of developing that site and
> the community around the site. The goal for the website was to have a
> simple rss feed or something AJAX-like that would pull that
> information when you sat on the site. It clearly doesn't work, but we
> do at least have some basic information there.
>
There are also plans in place for us to rebuild our site, but we
haven't yet finalised what/where.
A live build update would although be a pretty cool feature, and I'd
like to do something similar if you get it working.
> As for our current build status, you can check out
> http://koji.gooselinux.org as we've done most of our builds to date.
> There are around 300 failed builds at the moment and several others
> we're going to need to scrub out upstream material, or generate our
> own package. I plan to work on these fixes today and tomorrow and hope
> to have most of it resolved by the end of the weekend. We'll see how
> it goes.
>
>> Perhaps the essence of what I feel our project is about, vs the
>> canonical example- CentOS, is making the build and development process
>> completely open/transparent to the public so that anyone can use it as a
>> reference. I.e. my immediate response is-
>
> Our goals are similar here. The main difference we discussed was that
> we wanted to de'bus'ify the process. In other words, if one person
> gets removed from the process by a bus or a velociraptor, the project
> continues to function at a fairly similar pace. At the current moment,
> that means removing barriers for contribution and making the process
> simple enough that anyone could come in and make that work. We want
> our community to work first and foremost and the release is a result
> of this community engine working on all cylinders.
>
> I'm not saying that Ascendos doesn't aspire to this, as I don't have
> any proof against that. I would suspect indeed, that you have every
> intent of de'bus'ifying your process as well. Let me know what you
> think about this direction. I bet there is more in common than it
> currently appears.
I think in the context of Ascendos we've focused on making the project
(or at least the important build portions) reproducible. (Which is
really the same thing as "de'bus'ifying", just on a macro scale.)
In the short term it has never been my priority to ensure that
*everything* is "de'busify'ed". The focus has been getting builds
done. In the longer term it is of course is important to ensure the
security, and resilience of the project. Along with formalisation of
the project governance, and a legal entity under which to operate
under.
Excellent. (Hopefully) more hands, will make light work. We're all
heading in the same direction, so lets make it work.
Cheers, AC
>
> Cheers,
>
> Clint
Clint Savage
>
>
> I do apologize in that I'm somewhat old (by tech industry standards), and
> for personal reasons I don't use IRC and instant messaging, it just isn't my
> thing. I hope you can tolerate the present communication channel.
>
>>
>>
>> Our goals are similar here. The main difference we discussed was that
>> we wanted to de'bus'ify the process. In other words, if one person
>
>
> as a difference, let alone the main one. I've actually put a ton of work
> into our wiki, and would expect that the _primary_ impression one would get
> from my work in the last 3 months, is that we are about "de'bus'ifying" the
> process. Please elaborate as to what gave you that impression, because it
> is positively antithetical to what I've been trying to build and document.
> ascendos.org/wiki/BuildTesting is my single page answer to the
> 'debusification' issue.
I am sorry if you got the wrong impression. I'm only looking at a
small slice of what you are doing. At the moment, I think about how
both communities are trying to come up with the best way to rebuild an
Enterprise Linux distribution and more importantly, build a
contributor community along the way. After looking tonight at some of
your code from links you mentioned above, I see that you are
definitely going for transparency and repeatability.
It's probably just the different directions we're taking toward
building community that might have thrown me for a loop. The direction
we're taking is to involve the community in every step of the rebuild
process. Overall, I think this is hard to do, since it could all be
easily automated, which appears to be more of the approach you are
taking. I don't think either direction can live without a contributor
community. I was thinking of de'bus'ifying the process as more about
getting others involved directly. However, I do see how either
approach could accomplish the same goal.
>> I'm not saying that Ascendos doesn't aspire to this, as I don't have
>> any proof against that. I would suspect indeed, that you have every
>> intent of de'bus'ifying your process as well. Let me know what you
>> think about this direction. I bet there is more in common than it
>> currently appears.
>
>
> Again, whatever gave you that impression needs to be corrected.
I left my original quote above to clarify my point. I was only asking
what directions you are taking. I meant no offense, only curiosity.
..snip..
>>
>> Awesome. We look forward to working more with you and the Ascendos
>> project at large. I'm very excited to get this communication started
>> and start working together to grow the Enterprise Linux Rebuild
>> community!
>
>
> Indeed. It is certainly a common cause. I hope you take the time to look
> at our approach thus far and lend us your thoughts on what you think we're
> doing right and wrong. But again, if thinking that we aren't focused on
> 'debusifying' the process is your main impression on what we are doing
> differently (on the 'wrong' end of things), then I must be failing utterly
> in my attempts to lay down just the opposite ideal on our wiki and in our
> build scripts.
>
> -dmc
Most definitely. I'm just glad to see the EL Rebuild community
growing. It makes everyone's job easier, even the upstream. I think I
just need to spend a bit more time asking you more questions about
your scripts and why you are doing certain things. I hope we can both
learn from each other and benefit from one another's hard work.
Cheers,
Clint
Douglas McClendon
> Excuse the cross-post. I think that sending this to both lists would be
> the best way to communicate to both groups. I've enabled non-member
> moderated access to the GoOSe Project mailing list to facilitate
> discussion. Please reply to both goose...@googlegroups.com and
> ascend...@lists.ascendos.org with comments.
>
> A couple of people have approached us at the GoOSe Project about the
> Ascendos project. Consider this our 'official' response to the questions
> they asked.
Hello,
My name is Douglas McClendon, I am the current lead developer of
Ascendos, having taken over for Troy Dawson in early september after he
was lured away from ScientificLinux/Ascendos by employment with RedHat.
I'm not sure if the people approaching you that you referred to was our
project leader Andrew Cutler or others, though Andrew had mentioned
GoOSe once or twice. I really hadn't looked into the project until just
now as I saw the github homepage url you provided. The website stored as
git repo I do like.
Anyway, I'll leave it to Andrew to provide a more 'official' response to
the many good things you brought up, but I'll make a few quick comments.
First, of course yes, I do see much room for collaboration in many of
the below areas you mention.
One thing that I couldn't find in the first few minutes of looking over
your project, is how to access/inspect/review/learn-from the current
state of your build. You have a Download page with 777/1800 packages
built, but with a caveat that the information is not accurate. Below
that you have 3 download links to 'skein'/'grapple'/'chase' but those
are all broken links as is the 'about' tab which I was hoping would give
me insight into the history of your project.
Perhaps the essence of what I feel our project is about, vs the
canonical example- CentOS, is making the build and development process
completely open/transparent to the public so that anyone can use it as a
reference. I.e. my immediate response is-
I'm currently having trouble composing a 6.1-x86_64
traditional(non-live) installer (that works), and if you have already
got one built that does work, I'd love to see the specific compose
commands you used (and tools versions, build environment details). I
see several git-repos, but can you point me at the start of the path
that you would expect the public or future members of your community to
use to help them find the answer to that. I.e. do you have a
'start-here' kind of document for how someone could reproduce your build
thus far? The analog for our project would be something like what we
have in-
ascendos.org/wiki/BuildTesting
(also useful are)
ascendos.org/wiki/DistroTesting
ascendos.org/wiki/Development
Right now I'm just heads-down trying to get a first vaguely working pass
of the entire up-to-current packages and pointreleases built (and
trivially reproducible by anyone interested from looking at our existing
scripts and documentation). Once I'm past that I'll have more bandwidth
for the many wider issues and collaboration opportunities outside the
core OS output generation tract.
Thanks,
-dmc
Douglas McClendon
> _______________________________________________
> Ascendos-dev mailing list
> Ascend...@lists.ascendos.org
> http://lists.ascendos.org/mailman/listinfo/ascendos-dev
Douglas McClendon
> Douglas,
>
> Nice to make your acquaintance. I'm the primary developer here at the
> GoOSe Project. Most of my work has been focused around building GoOSe
> Linux 6.0 and the tools to make the process simpler for anyone to
> repeat overall.
That sounds pretty much identical to our goals.
>
> See my responses inline.
>
>> Hello,
>>
>> My name is Douglas McClendon, I am the current lead developer of
>> Ascendos, having taken over for Troy Dawson in early september after he
>> was lured away from ScientificLinux/Ascendos by employment with RedHat.
>>
>> I'm not sure if the people approaching you that you referred to was our
>> project leader Andrew Cutler or others, though Andrew had mentioned
>> GoOSe once or twice. I really hadn't looked into the project until just
>> now as I saw the github homepage url you provided. The website stored as
>> git repo I do like.
>
> The initial email was from Andrew. I think a few other folks visited
> us in our #gooseproject irc channel on freenode. Come lurk if you
> like, we'd love to chat with you about what you've been doing. I'm
> sure we'll have a good bit of knowledge exchange and maybe can work
> out a plan for further collaboration.
I do apologize in that I'm somewhat old (by tech industry standards),
and for personal reasons I don't use IRC and instant messaging, it just
isn't my thing. I hope you can tolerate the present communication channel.
>
I hate to say this, but I'm somewhat offended by the fact that you see
that as a difference, let alone the main one. I've actually put a ton
of work into our wiki, and would expect that the _primary_ impression
one would get from my work in the last 3 months, is that we are about
"de'bus'ifying" the process. Please elaborate as to what gave you that
impression, because it is positively antithetical to what I've been
trying to build and document. ascendos.org/wiki/BuildTesting is my
single page answer to the 'debusification' issue.
> gets removed from the process by a bus or a velociraptor, the project
> continues to function at a fairly similar pace. At the current moment,
> that means removing barriers for contribution and making the process
> simple enough that anyone could come in and make that work. We want
> our community to work first and foremost and the release is a result
> of this community engine working on all cylinders.
>
> I'm not saying that Ascendos doesn't aspire to this, as I don't have
> any proof against that. I would suspect indeed, that you have every
> intent of de'bus'ifying your process as well. Let me know what you
> think about this direction. I bet there is more in common than it
> currently appears.
Again, whatever gave you that impression needs to be corrected.
>
Indeed. It is certainly a common cause. I hope you take the time to
look at our approach thus far and lend us your thoughts on what you
think we're doing right and wrong. But again, if thinking that we
aren't focused on 'debusifying' the process is your main impression on
what we are doing differently (on the 'wrong' end of things), then I
must be failing utterly in my attempts to lay down just the opposite
ideal on our wiki and in our build scripts.
-dmc
Douglas McClendon
> On Sun, Dec 11, 2011 at 8:01 AM, Clint Savage<her...@gmail.com> wrote:
>
>> You are right. we're still in the process of developing that site and
>> the community around the site. The goal for the website was to have a
>> simple rss feed or something AJAX-like that would pull that
>> information when you sat on the site. It clearly doesn't work, but we
>> do at least have some basic information there.
>>
>
> There are also plans in place for us to rebuild our site, but we
> haven't yet finalised what/where.
> A live build update would although be a pretty cool feature, and I'd
> like to do something similar if you get it working.
'live build update'?
-dmc