Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

update some build notes

- notes.dmc.txt: misc updates
- notes.process.txt: simple import of important ascendos-dev post
    from Troy Dawson describing his preferred/ideal workflow
  • Loading branch information...
commit c891fa7d45745b955c30a98a065910fcb7286d5d 1 parent fdd33c6
@dmcclendon dmcclendon authored
Showing with 94 additions and 5 deletions.
  1. +26 −5 6/misc/notes.dmc.txt
  2. +68 −0 6/misc/notes.process.txt
View
31 6/misc/notes.dmc.txt
@@ -14,15 +14,21 @@ first alpha
-----------
rc's are in the pipeline from el-build, now even with inital live spin.
Presently seeking better consensus and documentation on mirror/output
-layout. Issue being pursued on -dev,wiki,bugzilla
+layout. Issue being pursued on -dev,wiki,bugzilla. Note, being so
+close to 6.1 package completeness, that is now a blocker for the next
+real alpha rc.
upcoming beta tasks
-------------------
need to handle the 6.0 package off-spec release naming issues, and the
-~200? 6.1 packages that need being built. The current gen-big-board
-script is already a long way towards being able to submit the missing
-builds in an automated way. Currently it needs an updated bugfix for
-the koji-dump-buildinfo script.
+~200? 6.1 packages that need being built. The 2 oldest unbuilt packages
+(grub and qt) have been built. The next batches require some abbreviated
+manual steps (for the .asc ones), along with leveraging present gen-tdv
+automation. And several require dispatch logic that should simultaenously
+be encoded into v-bake or preferably newly factored subcommand. Beyond
+that, everything may just build, with the dozen(?) or so of the remaining
+updates that require the semi-manual import (to be automated, e.g. the
+quintessential httpd default test page branding example.
build3
@@ -32,6 +38,13 @@ i.e. koji and its output.
(prior build2 run went to ~1950)
current status: ~300/~2800
+current state: suspended while focusing on 6.1-alpha-rc3, and also new
+anonymous testing person w/hardware resource (3 beefy systems) Andrew
+introduced me to. Formalized test/help procedures will be drafted, though
+the first phase would boil down to familiarizing yourself with the
+existing documentation, and figuring out how to blow that 100G bandwidth
+from your ISP. As that is a one time up front thing that will likely
+take a couple or more days anyway.
todo: need to add pxe live image serving configuration such that
any willing builder nodes on the local net are utilized
@@ -41,6 +54,14 @@ maintenance process
-------------------
need to start documenting candidate mainenance workflows, preferably with dia
+- note, ran across old post from Troy about his rpmcomparing to SL6, somewhat
+ contradicting how I responded to someone about what rpmcompare was used against
+ by us. Though I presume Troy's longterm intent was to rpmcompare against tuv, or
+ at the least centos and similar, and not focus on the results against SL6.
+ BUT, the point is that such a phase against at least SL6 seems worth doing and
+ encoding at the very least as a non?default option for the el-build user.
+
+
build.a.o/linux/ascendos
------------------------
View
68 6/misc/notes.process.txt
@@ -0,0 +1,68 @@
+This seems important enough to just quote here in tree until it
+gets blended in in other ways-
+
+http://lists.ascendos.org/pipermail/ascendos-dev/2011-July/000091.html
+
+>> >> I think Dag had a really good point regarding Github lowering the
+>> >> barrier to participation. Although depending on how we use it, space
+>> >> could / will be an issue. I think github do have flexible space limits
+>> >> for open source projects, so I might drop them a line.
+>> >>
+>> >> At an outset, how much repo space would we need?
+> >
+> > This gets to needing to flush out that list of project data, and which
+> > of those pieces live in the repo, and estimates of their sizes going
+> > forward.
+> >
+> > -dmc
+Hi,
+This has been a very good discussion, and I just don't know where to
+put my opinion in, so I'm just going to bottom post and put my
+view/vision.
+This is not gospel, this is just what I wish, what I think would be good.
+For the most part, I am also going to leave out specific tools, except koji.
+
+My ideal build system with it's workflow.
+
+1 - Automatically detect and download new errata source rpm's
+1a - Expload those rpm's into some git/svn repository
+1b - Give some notification of new package (rss feed, twitter, email ...)
+1c - If there is a known "diff" in the main ascendos release, apply
+the diff, if possible. If not possible, notify someone in some way.
+2 - Send the source rpm to the appropriate build queue on koji
+2a1 - If the build fails - koji sends email. Possibly put in some
+other notification.
+2b1 -- This is where manual intervention come in. Fix the problem.
+2a2 - If build succeeds - koji also sends email. Sign the package, proceed to 3
+3 - Test the built packages - Have some type of webpage, such as
+bodhi, that watches the packages as they go through testing.
+3a - Automatically test packages against some ideal binary package
+3b - If a package is a known problem package, do the appropriate
+manual and/or automatic test
+4 - After the package passes the tests, mark it as ready.
+4a - Update the web page(s) that describe the latest errata
+4b - push the updated packages into the appropriate errata updates repo
+4c - Do notifications of errata
+5 - At the appropriate time, create a distribution / release / live image
+5a - Mark the packages with the appropriate tag
+5b - Pull all the marked packages
+5c - Mash all the packages into the distribution / release / live image
+
+I need to send this before my connection dies again.
+Each section can use seperate tools, although some tools might be able
+to do several of the steps. (I *think* bodhi can do several of the
+steps, but I haven't had any real world experience with it)
+What would also be ideal is anyone can do a mini-fork at any point after 1b.
+So if you had your own distribution (TAR - Troys Awesome Release) that
+was exactly like Ascendos, except that openoffice had a purple theme,
+You would create your own diff of openoffice at point 1c and mark that
+diff "TAR", and you could manually (or automatically if you set it up)
+walk that diff through all the steps, creating your own distribution
+with the tag of TAR.
+
+Ok, now I really have to go.
+Troy
+_______________________________________________
+Ascendos-dev mailing list
+Ascendos-dev@lists.ascendos.org
+http://lists.ascendos.org/mailman/listinfo/ascendos-dev
Please sign in to comment.
Something went wrong with that request. Please try again.