Mailinglist Archive: opensuse-project (47 mails)

< Previous Next >
Re: [opensuse-project] Projects
  • From: Susanne Oberhauser <froh@xxxxxxxxxx>
  • Date: Tue, 18 Nov 2008 10:52:46 +0100
  • Message-id: <s2iprktbbtd.fsf@xxxxxxxxxxxxx>

Pascal Bleser <pascal.bleser@xxxxxxxxxxxx> writes:

I personally believe that the problem is two-fold:

1) We're missing (quite?) a few top-level projects (such as
filesharing, security:*, ...) and I personally managed to have a few
packages that don't fit into any of them. I ended up putting them in
my home:pbleser:* projects because of that.

That might be a problem for more packagers, which would explain why
so many packages end up in home:* repositories instead of top-level
ones (or "non-home:" ones).

2) We don't have a lot of collaboration tooling around the OBS at
this point. The branches/patching approach is not trivial and it
doesn't really help wrt communication between packagers. Packagers
who do their work during their free time, which is usually at night
with whatever timezone, might also have a hard time to poke people
who can give them maintainer role or create a new non-home: project
quickly. Personally, I think it is an issue because waiting a few
days for such stuff getting done is a major annoyance when you
maintain several dozens of packages. Maybe a broader coverage of
"super-maintainers" (I only know of Adrian having such root powers
on the OBS, and.. darix maybe ?) would help there.

I agree with this.

And I wonder how the build server is really meant to be used as a
collaboration tool. I think having a clear common picture of that
would give me a better understanding of what is really missing.

I very much like a structured approach like this one:

- Who (Personas)
- needs what (Requirements)
- and works like this (Usage Scenarios)
- thus she needs this (Features)

- this is how we can make the above work (Interaction Design)

- and this is how it works behind the scenes (Architecture)

We have started this whole thing from our rock solid gut feeling
within SUSE, and we all had one or the other gut feeling on how this
should work together. That's why we got so far with so little in
writing :)

Anyway I believe it's a good time to give our shared thinking a little
form now.

Here is a draft to make tangible what I mean:


In a package lifecycle, there is many people invovled like Audrey
Author, Peter Packager (or Pascal ;), Ted Tester, and last not least
Ursula User. And as Packages come in packs (pun intended), which is
products or add-ons, there also is Ingo Integration Manager, like
Adrian for the obs or Andreas for Factory.

Personas and their Requirements:

These people all have different views and have different requirements
on our build service:

Audrey Author
- creates this real cewl code
- likes the idea to get her code to different distros magically
- doesn't know and doesn't want to learn much about packaging
- would create or update packages if that works 'magically' from
some svn/git/cvs branch
- knows her development environment (maybe shell, maybe eclipse, ...)
- develops her code to some very specific snapshot of packages

Peter Packager
- *loves* packages
- knows a little of everything
- knows how to fit some arbitrary code into a distribution
- is a command line wizzard
- handles many packages
- needs to be up-to-date about changes and status
- lives in email and possibly irc
- needs to cope with different base package versions on different
- wants his check-ins to build 'soon', even at the cost of getting a
rebuild later, so builds don't starve

Ted Tester
- is no coder
- knows some applications
- will run and use them
- would like a clear process:
package is there for testing -> I have tested it ok
- needs guidance on how to submit bug reports

Ursula User
- wants well integrated, tested and relatively current packages
- wants to find them easily
- wants dist upgrades to work smoothly with third party packages
- wants an easy mechanism to report bugs
- wants updates to be presented automatically

Ingo Integration Manager
- needs to know the overall status and progres of his project
- needs to reach out to "where the flow doesn't flow"
- needs to control how active his project is, to create stable
- needs to collect several tests into one, synchronous release

Usage Scenarios

this describes step by step how people interact in specific
situations, focussing on the process and the kind of information,

* initial package
* patch update
* major update
* base package update which creates failure
* release cycle management (a1, a2, b1..b6,

e.g. patch update:
- check out local working copy (osc co)
- use quilt to create source tree
- modify to heart's content with quilt, doing rebuilds
- if local build and test is ok: check in to test
- test
- if ok: prepare for release
- release
if the package is maintained in the upstream repo:
- similar, using the distribute script to abstract away 'osc'

e.g. release cycle management
- ...


e.g. patch update:
- simple workflow in obs:
check-in for build -> test repo -> production repo
- distribute script needs ...
- quilt step by step guide for this use case

e.g. simple workflow in obs:
Each project has three stages: development, integration and
test, production

the packages are built by Peter Packager into the development
stage. when the build looks ok to Peter (per local tests or
regression tests), Peter flags the package as ready for testing.
Ted Tester then puls the package into the integration test area
and tests the package from there, also in it's interaction with
other packages. When the integration test is ok, then Ted flags
the package as ready for release. when all apcages are flagged
for release, Ingo Integration Manager will release this snapshot
of packages to production.


=================================================================== I
believe that the obs and it's documentation will really benefit from
describing it like this and from expanding and growing this
description for new feaures. It makes life simple: it allows Ingo
Integration Manager of the obs to watch a new requirement or other
changes to trickle through this model down into architecture and then
implementation. And it will help any other participants in the obs to
better find into it, understand how it's meant to be used and to enjoy
it and improve it.


Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business
OPS Engineering Maxfeldstraße 5
Processes and Infrastructure Nürnberg
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups