[aur-general] TU Application -Thomas Hatch

[Thomas S Hatch]

On Wed, Jan 5, 2011 at 9:44 PM, DJ Mills <danielmills1 at gmail.com> wrote:

> Sure, I'd be interested.  I haven't had much else to do recently...
>
> What I've been doing has been primarily in bash though. Still, the concepts
> should
> be fairly similar, and it never hurts to share ideas.
>
> On Wed, Jan 5, 2011 at 10:46 PM, Thomas S Hatch <thatch45 at gmail.com>
> wrote:
>
> > On Wed, Jan 5, 2011 at 8:39 PM, Kaiting Chen <kaitocracy at gmail.com>
> wrote:
> >
> > > On Wed, Jan 5, 2011 at 7:07 PM, Thomas S Hatch <thatch45 at gmail.com>
> > wrote:
> > >
> > > > On Wed, Jan 5, 2011 at 4:57 PM, Christopher Rogers
> > > > <slaxemulator at gmail.com>wrote:
> > > >
> > > > > I was working on something that is like quarters. I called it absbb
> > (or
> > > > ABS
> > > > > Build Bot). I was trying to make a build like
> > > > > slitaz<http://www.slitaz.org/>has for there distro but for arch. I
> > > > > used makerepo to help with making the
> > > > > packages once in chroot. I have not looked at it in a few months
> > since
> > > i
> > > > > was
> > > > > busy trying to make slitaz better and updated.
> > > > >
> > > > > https://github.com/godane/devtools-pkgbuild/tree/archbb
> > > > >
> > > > > Also there is archbb script that was just my attempt to  combined
> all
> > > of
> > > > > devtools into one big script. That didn't get any auto build bot
> > > feature
> > > > > into it.
> > > > >
> > > > > I hope this helps. Also +1 for TU.
> > > > >
> > > > > PS I started releasing my livecd again at
> > http://godane.wordpress.com.
> > > > >
> > > >
> > > >
> > > > Well, good ideas are thought of twice :)
> > > >
> > > > I am making quarters in python, also I wanted to make it so the the
> > > builds
> > > > could be distributed, it would be difficult and impractical to have a
> > > > continuous build system rebuilding all packages over and over again
> on
> > > just
> > > > one box.
> > > >
> > > > I have just been trying to figure out how to make it simple enough
> for
> > > > arch,
> > > > so no databases, communication systems are all built in so no setting
> > up
> > > > crazy deps etc.
> > > >
> > > > But I will look at your absbb, I will most likely be able to garner
> > some
> > > > ideas!
> > > >
> > > > Thanks for the vote!
> > > >
> > >
> > > WTF is everyone working on this? Daniel Mills admins on my server and I
> > > know
> > > he's been working on a continuous build system for parts of the AUR.
> You
> > > all
> > > should get together for lunch or something. --Kaiting.
> > >
> > > --
> > > Kiwis and Limes: http://kaitocracy.blogspot.com/
> > >
> >
> > Actually that would be a good idea, I think that there is probably some
> > divergence on ideas for what a continuous build service for arch would
> be.
> >
> > Would you mind asking him if he would be interested in collaborating on a
> > project for this?
> >
>

Watch out, someone is on a top poster burning rampage :P

I think that my plan might be a little more elaborate, since I want to be
able to build everything, and do it in a somewhat timely manner.

The Fedoa Koji server works by having 3 types of servers all tied together
via rpc and storing data in a PostgreSQL database, but this is far too
complicated (as is setting it up - murder)

I want to make a system that maintains a central pacman repo, that uses a
central manager to control builds, the builds are managed by autonomous
build bots, build bots that can be on separate machines or on the same
machine. The builds can happen in a chroot (I will use some security moves
to make if more secure), or if we want to make it MUCH more secure (for aur
builds) then we can build them in generated virtual machines.

I don't want to use a database, pacman is simple enough to use entirely live
state data, this will prevent data inconsistencies and lower system
complexity. The system should also manage builds based on changes in the
detached systems used to maintain source packages.

One thing that is AMAZING about Arch (there are many to choose from) is that
the actual os backbone, all of the source packages, and stored in unified
scms, so between the aur and the main repos all of the source packages are
there for the picking!

So basically, it needs to be dynamic, powerful, intercommunicating systems -
and most of all - Simple, Simple to set up, Simple to use, and Simple to
understand.

Another thing that is amazing about Arch is that inherently complex
and complicated problems, problems which have spurred the creation of
amazingly complicated Linux distributions, have here been solved with Arch
in simple and elegant ways. After my time working on software for the US
government I saw the absolute opposite, the most complicated and complex
systems I had ever seen.

Arch presents a platform and a challenge, a challenge to engineer
applications that are both powerful and simple taking the concept
of elegance to another level. This is really my main motivation with Arch,
The engineering is incredible, and I think that I can make the best software
by learning from the Arch way and the Arch devs.

Anyway, I will bother you off list and see if you are game.