Hi,
Pascal Bleser
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: Personas: 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 distros - 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 snapshots - 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, rc1..gm) 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 - ... Features 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 Design: 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. Architecture: ... =================================================================== 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. ? S. -- 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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org