Novell detiene el desarrollo de SaX2, como se puede ver en este thread. Ahora se deja en manos de la comunidad: ¿sobrevivirá?

Hey Hackers,

For the future of openSUSE development we want to change some things.
Currently, we have some policies around the distribution that date
back to the time when there was no openSUSE. Code contributions are only
possible if you go through a Novell developer. The same thing is true if
you want to make some technical decision.

On the other hand it’s really easy to pass contributions to the Novell
Developers. A simple “osc sr” and you have the change you want in the
openSUSE distribution. But we want to go further now and make it as
easy as possible for everybody to leave a footprint in, and become
responsible for, the openSUSE distribution.

To make this transition easy going for everybody we came up with the
following plan:

We want to split up Factory into smaller parts and join together devel
projects of packages into topic projects in the Build Service. So for
instance we want to have a GNOME:Factory project with all GNOME and
related packages and Kernel:Head project with all the packages that
belong to the kernel. To no one’s surprise there are already a lot of
teams that handle their packages in this way. For instance the GNOME and
the Kernel Teams What we want now is to use this model for every
aspect of the distribution, not only the big parts where this comes
naturally. All current maintainers are working at the moment on an
initial setup for these groups. You can see it evolving live in this
svn repo:

http://svn.opensuse.org/svn/henne-6f900df20eaf3d879d36ea8a00da5012/

This is of course not the only possible way to sort packages and in fact
we are only trying to come up with a good starting point. We will always
allow moving of packages, creation of new topic groups, or removal of
obsolete ones. We also use currently an Novell internal database called
the Package Database (PDB). It holds a lot of RPM metadata, for instance
the description, the license, URL and so on but also data that does not
end up in the specfile like the devel project and things like that. We
have started to migrate this data to the OBS and to provide means of
changing it.

Those are the “technical” changes we are about to do for Factory. The
other change we want to introduce is a policy change. As our goal is to
make it possible for everybody to work on the distribution we will
simply allow the topic groups to organize themselves. We think that
there is not the one and only way such a group of maintainers can work
together, but it depends on the involved people and also on the topic
what the best way is. So to transition we will throw together the people
that are currently maintainer of packages and help them work out how to
best collaborate with each other and new people.

This is what we will do. I also have this summarized in the following
Roadmap:

2009.06.03 – 2009.06.15
* Create HOWTO for packagers with the most used osc commands, persons
to contact, documentation and so on. -> Portal/Maintainers
* Current maintainers sort through the packages in the topic groups

2009.06.10
* have drop submitreq done
* have clone submitreq done
* have change devel project submitreq done

2009.06.15
* Create missing buildservice projects
* Set devel project for the packages in Factory
* Turn of PDB syncing for Factory
* Start working with the TOPIC groups

2009.06.15 – future
* Fix “bugs” in the new way of working (AI: everybody)
* finish pdb migration (AI: henne/adrian/jw/rudi)
* open up maintenance process (AI: henne/dirk)
* open up check in/review process (AI: henne, autobuild team)
* open up other teams/tasks/processes that support the distribution
(AI: henne)

I hope you support us in this ongoing move and bear with us as we change
the way we work on this distribution for the last God knows how many
years!

Henne

–
Henne Vogelsang, openSUSE.
Everybody has a plan, until they get hit.
- Mike Tyson

Para la comunidad susera de Mx (o cuaquier interesado en linux en general), dare algunas conferencias relacionadas con SUSE en la H. Facultad de Ciencias de la UNAM. El programa y fechas a continuacion:

2009-2 Ciclo de pláticas Linux / OpenSUSE. Auditorio Carlos Graef de 17:00 a 19:00 horas

* Mauro Parra – SUSE Studio – 15 de abril de 2009

o SuSE Studio – presentación del proyecto auspiciado por Novell/SUSE, busca crear el sistema operativo de appliances o versiones personalizadas de openSUSE. La interfaz es muy sencilla, permite hacer una personalizacion del “branding” de la distribución, asi como adelgazarla o extendera con paquetes propios y extraños.

* Mauro Parra – Open Build Service – 22 de abril de 2009

o Open Build Service – Distribuir tu software para Linux nunca fue mas facil, a partir de una sola descripción, puedes generar paquetes para Debian, Ubuntu, Redhat, Mandrake, SUSE para diversas arquitecturas. En esta platica aprenderas a crear proyectos, añadir paquetes, compilarlos local y remotamente, asi como un poco acerca de como es el RPM spec.

* Mauro Parra – Cómo crear una distribución – 6 de mayo de 2009

o Cómo crear una distribución – Workflow de desarrollo de una distribución de linux, caso openSUSE. En esta platica el alumno podra ver todo el ciclo de desarrollo de una distribución como openSUSE y SLE, asi como los distintos roles laborales que intervienen en la misma.

* Mauro Parra – Gnome – 13 de mayo de 2009
o Gnome – ¿qué es gnome? ¿cuales son sus componentes básicos? ¿qué implica instalar el nuevo gnome? Analisis del ciclo de desarrollo de gnome, asi como las novedades de la ultima version disponible.

El listado completo de eventos aqui.

- Forcing a package to be installed in your jail

- disabling devel files checking in rpmlint.

- adding debugging to your package

- How to package java programs properly?

- How to tag your patches for gnome

- SUSE Insanities

- Create lighter packages, use -lang subpackages

That’s all folks!