-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joop Boonen wrote:

All,

Hi Joop

I was looking via: http://software.opensuse.org/search trough different packages in OBS. I saw that there quite a few duplicate projects. Some with identical new versions and some with old versions.

Yes. That's quite a plague IMO, to put it mildly.

I saw there are also quite a few overlaps with the fwbuilder package that I also have in OBS.

So I'm wondering if there is a way to consolidate packages in groups so that more people can put effort in building packages and bundle their knowledge to get the best out of it. Currently a lot of people put a lot of time in "duplicate" packages.

I'm wondering wouldn't it be better to start for for instance fwbuilder a security project that can be maintained by joined effort of people? In that way more package can be maintained in OBS I think?

Yes, absolutely, that would be the best solution in this case. 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 really think that we should get rid of home: repositories for anything else then playing around. The current situation is problematic because some home: repositories are really just playgrounds for experimenting or learning, and other home: repositories contain proper packages that are adequate for public consumption by the masses. If we could at least move such proper packages to non-home: repositories, the easy rule would be "don't use home: unless you _really_ know what you're doing". And also, for example, not return search results from home: repositories unless explicitly for (e.g. a checkbox on the search page). It could also somewhat soften the duplication problem as home: repositories are for fiddling around, but when a packager wants something advertised as stable and OK for everyone to use, she should get in touch with maintainers to have their packages moved to non-home: repositories. Or propose their help to co-maintain a duplication of that package in a non-home: repository. Or let go and package something else, it's not like there isn't enough work for everyone ;)

If this option if feaseble what is the best way to accomplish this? The project of course needs to be created. Shall the individual OBS builder contact the other OBS builder?

I'm afraid that is the only option as of now. Look up who the maintainers are for a specific non-home: repository if it already exists, and contact them directly (on IRC or by email or on the opensuse-buildservice mailing-list). If an appropriate non-home: repository does not exist yet, send an email to the opensuse-buildservice list. cheers - -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM::7+8 Feb 2009, Brussels, http://fosdem.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFJHsasr3NMWliFcXcRApJdAJ4v+iSF8WO6dzfJO3xXrO+Jla6W2QCgpx+a q7HUVxkSs7czrksDuTGcGic= =nR5U -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Hi, Pascal Bleser 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: 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

Patrick Shanahan writes:

* Susanne Oberhauser [11-18-08 04:56]:

...

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.

Perhaps prior to an individual introducing a package, that package particulars should be broadcast to a wiki/database for simi-automagic comparison of those already in existance. Would possible provide information to preclude duplicated efforts.

Maybe, yes. Maybe the obs could also support people in dropping old, outdated package versions. Hermes could even annoy maintainers about hosting an old package version. As it could annoy maintainers about new package versions that are available. Yet then you'd need a flag to tell 'Yes I know. This is the maintained version, that needs to be here, too, for compatibility.' And the obs could help users to find a 'good' package based on the ratings Marko is working on or based on actual test results of real users. Or both. Or all three of them. There is many solutions to this. And several ankles to it. So where's that place where we put this thinking down in a structured way that at the end gives us not just technology but a way to jointly provide prepackaged, tested open source software? On the distro of your choice? And as part of openSUSE proper? 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

Patrick Shanahan writes:

* Susanne Oberhauser [11-18-08 12:40]:

...

Patrick Shanahan writes:

...

* Susanne Oberhauser [11-18-08 04:56]:

...

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.

Perhaps prior to an individual introducing a package, that package particulars should be broadcast to a wiki/database for simi-automagic

s/simi/semi :^)

yes. see, you understand what I want to say :)

Ahhh, your spelling resembles mine :^) or you have another agenda

oh puleese, ankle comes close enough to angle doesn't it ;) ?

...

So where's that place where we put this thinking down in a structured way that at the end gives us not just technology but a way to jointly provide prepackaged, tested open source software? On the distro of your choice? And as part of openSUSE proper?

Appears the need for another wiki page with a call for collaboration. There definitely needs to be an easy way to help channel work efforts away from duplications.

I'd volunteer to start that effort, along the lines I've described iff I can anticipate interest and contribution for such writings. I love the technology we create and I think it will greatly benefit from a more structured description of whom we are doing this for, what we want to achieve for these users, how they interact using the build service and how specifically it's supposed to be used. 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