[opensuse-gnome] GNOME:STABLE and GNOME:UNSTABLE

newer
[opensuse-gnome] Collecting Reviews

Michael Wolf

3 Oct 2007 3 Oct '07

15:24

Hello As you all know, we've been discussing how to best maintain and utilize the GNOME:STABLE and GNOME:UNSTABLE projects. We discussed this in the past meeting. The relevant part of the transcript is here: http://en.opensuse.org/GNOME/Meetings/20070927/transcript#GNOME:STABLE_merge... Here's my plan. Note that it's different from what I said in the meeting; after further thought and discussion with a few people, I've changed my opinion on how best to proceed. * GNOME:STABLE We'll repopulate GNOME:STABLE with the contents of the relevant packages as they currently exist in Factory. As a result, GNOME:STABLE will soon include GNOME 2.20.0. Because we'll be upgrading GNOME:STABLE to 2.20.1 soon (20071017), we'll be copying packages, not linking them. * GNOME:UNSTABLE We'll also repopulate GNOME:UNSTABLE with the contents of the revelant packages as they currently exist in Factory. However, the future of this repository will be different. When GNOME 21 comes out, we'll be tracking it closely. At the same time, we'll stop directly updating the GNOME packages directly in Factory. Instead, packages from GNOME:UNSTABLE will be (automatically, I hope) synced to Factory on a regular basis. Tarballs for GNOME 21.1 are due on 20071029, so we'll start updating it then, but we can start improving our .specs as discussed in http://en.opensuse.org/GNOME/Patches sooner than that. * Timeline ** GNOME:STABLE update I intend to start updating it on Thursday, 20071011. ** GNOME:UNSTABLE update Since GNOME:STABLE and GNOME:UNSTABLE will for a time contain the same packages, I plan to do this at the same time as the GNOME:STABLE update. * Issues and Questions ** Workflow Doing our ongoing development in GNOME:UNSTABLE will make it easier for anyone interested in contributing to do so. There will be some hitches for people who work for Novell/SUSE and use the internal autobuild system. Expect a different mail to address that soon. Its main thrust will be asking everyone to submit fixes to GNOME packages via the Build Service once GNOME:UNSTABLE has been updated. ** GNOME:ALMOST-STABLE? When will we update GNOME:STABLE to 2.22.0? Only when GNOME 2.22.0 is released? When GNOME 2.21.90 is released? Etc. ** Security We'll need help from the SUSE security team in preparing security updates. I've already sent mail to Marcus, the security team lead, about this. ** Other problems / questions / suggestions? Let me and the rest of the list know. I'd like to stress how important the GNOME:UNSTABLE repository will be for all of us. As I said above, anyone interested in shaping our corner of the distro will have the opportunity to do so directly. You won't be limited to sending patches or making suggestions -- although contributions in this form will of course always be welcome. Additionally, since GNOME:UNSTABLE will be available for older distros (at least on 10.3), it'll be possible to run an experimental desktop without the risk and hassle of of an entire distribution under development. I think that's it. Let the list know what you have to say. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Show replies by date

Rodrigo Moya

3 Oct 3 Oct

15:45

On Wed, 2007-10-03 at 10:24 -0500, Michael Wolf wrote:

...

* GNOME:UNSTABLE

We'll also repopulate GNOME:UNSTABLE with the contents of the revelant packages as they currently exist in Factory. However, the future of this repository will be different. When GNOME 21 comes out, we'll be tracking it closely.

At the same time, we'll stop directly updating the GNOME packages directly in Factory. Instead, packages from GNOME:UNSTABLE will be (automatically, I hope) synced to Factory on a regular basis.

Tarballs for GNOME 21.1 are due on 20071029, so we'll start updating it then, but we can start improving our .specs as discussed in http://en.opensuse.org/GNOME/Patches sooner than that.

great!

...

** GNOME:ALMOST-STABLE?

When will we update GNOME:STABLE to 2.22.0? Only when GNOME 2.22.0 is released? When GNOME 2.21.90 is released? Etc.

I think it makes sense to do it when 2.22.0 is released, which is when 2.21/2.22 becomes the real GNOME stable release.

...

I'd like to stress how important the GNOME:UNSTABLE repository will be for all of us. As I said above, anyone interested in shaping our corner of the distro will have the opportunity to do so directly. You won't be limited to sending patches or making suggestions -- although contributions in this form will of course always be welcome.

that's very good indeed. -- Rodrigo Moya -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

JP Rosevear

16:16

On Wed, 2007-10-03 at 10:24 -0500, Michael Wolf wrote:

...

** Workflow

Doing our ongoing development in GNOME:UNSTABLE will make it easier for anyone interested in contributing to do so.

When will we start this? ie should we be submitting internally only still for now? -JP -- JP Rosevear Novell, Inc. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Stanislav Brabec

17:09

JP Rosevear wrote:

...

On Wed, 2007-10-03 at 10:24 -0500, Michael Wolf wrote:

...
** Workflow

Doing our ongoing development in GNOME:UNSTABLE will make it easier for anyone interested in contributing to do so.

When will we start this? ie should we be submitting internally only still for now?

It is not a technical problem, it is a work-flow problem. Please consult with aj and coolo, what can be done to not conflict between ongoing development of GNOME:UNSTABLE and ongoing development of Factory. We might use technical solutions to solve this problem - e. g. making snapshot of Factory packages in a moment of starting separate development in G:U, but success ratio of an automatic spec and patch merging is not as good as one could expect (I guess ~70%). -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Michael Wolf

4 Oct 4 Oct

00:33

On Wed, 2007-03-10 at 19:09 +0200, Stanislav Brabec wrote:

...

JP Rosevear wrote:

...
On Wed, 2007-10-03 at 10:24 -0500, Michael Wolf wrote:

...
** Workflow

Doing our ongoing development in GNOME:UNSTABLE will make it easier for anyone interested in contributing to do so.

When will we start this? ie should we be submitting internally only still for now?

It is not a technical problem, it is a work-flow problem. Please consult with aj and coolo, what can be done to not conflict between ongoing development of GNOME:UNSTABLE and ongoing development of Factory.

I think the right thing to do is to ask the autobuild team to reject submissions for anything that'll go into /work/SRC/all/GNOME unless it comes from GNOME:UNSTABLE or another repository in the build service.

...

We might use technical solutions to solve this problem - e. g. making snapshot of Factory packages in a moment of starting separate development in G:U, but success ratio of an automatic spec and patch merging is not as good as one could expect (I guess ~70%).

I think any plan for this that requires any manual merges, other than merges within a single branch (in the terms of a proper version control system) or project, would be a real mistake. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Stanislav Brabec

08:27

Michael Wolf wrote:

...

On Wed, 2007-03-10 at 19:09 +0200, Stanislav Brabec wrote:

...
JP Rosevear wrote:

...
On Wed, 2007-10-03 at 10:24 -0500, Michael Wolf wrote:

...
** Workflow

Doing our ongoing development in GNOME:UNSTABLE will make it easier for anyone interested in contributing to do so.

When will we start this? ie should we be submitting internally only still for now?

It is not a technical problem, it is a work-flow problem. Please consult with aj and coolo, what can be done to not conflict between ongoing development of GNOME:UNSTABLE and ongoing development of Factory.

I think the right thing to do is to ask the autobuild team to reject submissions for anything that'll go into /work/SRC/all/GNOME unless it comes from GNOME:UNSTABLE or another repository in the build service.

Well, then we need a way, how people could do global changes in GNOME packages (e. g. BuildRequires after package rename / branch, new CFLAGS,...).

...

...
We might use technical solutions to solve this problem - e. g. making snapshot of Factory packages in a moment of starting separate development in G:U, but success ratio of an automatic spec and patch merging is not as good as one could expect (I guess ~70%).

I think any plan for this that requires any manual merges, other than merges within a single branch (in the terms of a proper version control system) or project, would be a real mistake.

Standard version control system does not work well for packages - spec files changes are concentrated in preamble and %prep and you get a lot of rejects there. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Federico Mena Quintero

18:35

On Thu, 2007-10-04 at 10:27 +0200, Stanislav Brabec wrote:

...

Standard version control system does not work well for packages - spec files changes are concentrated in preamble and %prep and you get a lot of rejects there.

Any version control system would be better than what we have now :) Right now, there is no one-liner (i.e. easy) way to answer any of these questions: * What changed in this package since two weeks ago? * What was the state of this package when $internal_release was done? * Who changed this patch between revisions 6 and 7 of this package? During development, it is very valuable to be able to answer those questions *really quickly* without hunting down old versions by hand, extracting srpms, diffing things, etc. Also, any revision control system keeps a better history than we do in the %changelog part of a specfile. Tools like Stacked Git (stgit) would be very helpful to let us do development while keeping a stack of patches on top of a pristine tarball. They solve the problem of "there are 42 patches in this package, and I need to do a change in patch number 13 and then rebase all the other patches on top of it". Federico -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Michael Wolf

19:05

On Thu, 2007-04-10 at 10:27 +0200, Stanislav Brabec wrote:

...

...
I think the right thing to do is to ask the autobuild team to reject submissions for anything that'll go into /work/SRC/all/GNOME unless it comes from GNOME:UNSTABLE or another repository in the build service.

Well, then we need a way, how people could do global changes in GNOME packages (e. g. BuildRequires after package rename / branch, new CFLAGS,...).

These are some of the issues: 1) If foo depends on bar which is renamed to (or branched to, replaced with, etc) baz, then foo will fail to build. Somebody will look at the logs or attempt a local build with osc, see what's changed in Factory or G:U, and fix the package. Same thing when the toolchain changes and gcc is stricter, or whatever. 1a) Autobuild has its own set of checks that it performs on built packages. These checks are stricter than the ones in the Build Service. Some people told me that the checks will someday be in the Build Service; others have told me that they won't. I'm of the opinion that they should be. Either way, until they are (which may be never) somebody who works for Novell will need to watch for packages that fail to build in Autobuild, fix each package so that it builds internally, do a getpac -d to figure out what he did, and apply the result of getpac -c to the package in the G:U. - Tasks that need to be done in the PDB: package renames, splits, etc. For now, somebody who works for Novell will need to do these, although I think a good case can be made for opening the PDB.

...

...
...
We might use technical solutions to solve this problem - e. g. making snapshot of Factory packages in a moment of starting separate development in G:U, but success ratio of an automatic spec and patch merging is not as good as one could expect (I guess ~70%).

I think any plan for this that requires any manual merges, other than merges within a single branch (in the terms of a proper version control system) or project, would be a real mistake.

Standard version control system does not work well for packages - spec files changes are concentrated in preamble and %prep and you get a lot of rejects there.

I don't follow. Fixing rejects and merging things by hand is a fact of life. It's like that now, and it would be like that with version control, although probably easier. Our Esteemed Competition uses revision control to manage their spec files and .deb equivalents [0]. One of our Esteemed Competitors even went so far as to write their own standalone revision control tool. It isn't tightly coupled with their infrastructure or workflows. They've done a pretty good job at it -- I'm a fan. I don't propose writing our own, of course. There's no need. But to say that revision control doesn't work well for packages? I don't buy it. (Needless to say, Federico's comments about the benefits of revision control are spot on.) [0] For example, see http://cvs.fedoraproject.org/viewcvs/devel/nautilus/ and https://code.launchpad.net/~ubuntu-desktop/nautilus/ubuntu. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Michael Wolf

21:52

On Thu, 2007-04-10 at 14:05 -0500, Michael Wolf wrote:

...

Either way, until they are (which may be never) somebody who works for Novell will need to watch for packages that fail to build in Autobuild, fix each package so that it builds internally, do a getpac -d to figure out what he did, and apply the result of getpac -c to the package in the G:U.

Whoops, that'd be "getpac -d" in both instances. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Stanislav Brabec

5 Oct 5 Oct

09:40

Michael Wolf wrote:

...

I don't propose writing our own, of course. There's no need.

We even may start with osc - osc is based on svn and their authors could help us with accessing its svn functions.

...

But to say that revision control doesn't work well for packages? I don't buy it.

It was my practical experience. In December 2006 we branched ~280 packages to G:U to move packages to /usr. I did a complete backup of all packages in the branch point. G:U changed ~250 packages. Factory changed ~30 packages. There was ~30 packages with paralles changes. In late January 2007 I went to merge both branches.

...

From those ~30 packages, ~20 was fixed by a simple merge and ~10 had to be merged manually.

The major problems of simple diff-patch-wiggle are: - Upstream updated package and fixed the same problem in parallel. Added patch is rendered obsolete. - Changes are in the same patch. Second level patch are often hard to apply (code change -> patch change -> second level patch cannot apply). - Changes in spec preamble often conflict - upgrade changes patch sets, fix does it as well. You have to merge patch set as first in order. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Michael Wolf

14:31

On Fri, 2007-05-10 at 11:40 +0200, Stanislav Brabec wrote:

...

Michael Wolf wrote:

...
I don't propose writing our own, of course. There's no need.

We even may start with osc - osc is based on svn and their authors could help us with accessing its svn functions.

As far as I can tell, osc is based on svn only insofar as its user interface for checking in packages is similar. I'm not averse to osc wrapping a proper revision control system (eg, osc diff, osc checkin, etc being based on their hg equivalents), but I am quite convinced that: a) We will sometimes want or need a way to drop down into lower-level and more powerful tools b) Something distributed is the way to go.

...

...
But to say that revision control doesn't work well for packages? I don't buy it.

It was my practical experience.

In December 2006 we branched ~280 packages to G:U to move packages to /usr.

I did a complete backup of all packages in the branch point.

G:U changed ~250 packages.

Factory changed ~30 packages.

There was ~30 packages with paralles changes.

In late January 2007 I went to merge both branches.

...
From those ~30 packages, ~20 was fixed by a simple merge and ~10 had to be merged manually.

The major problems of simple diff-patch-wiggle are:

- Upstream updated package and fixed the same problem in parallel. Added patch is rendered obsolete.

- Changes are in the same patch. Second level patch are often hard to apply (code change -> patch change -> second level patch cannot apply).

- Changes in spec preamble often conflict - upgrade changes patch sets, fix does it as well. You have to merge patch set as first in order.

Right. Well, conflicts are a fact of life, whether it comes to personal opinions or changes made to text files. :) Also we have plans to improve our .specs so that, among other things, it'll be obvious that a patch is expected to appear upstream and is therefore a candidate for removal. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Stanislav Brabec

14:53

Michael Wolf wrote:

...

On Fri, 2007-05-10 at 11:40 +0200, Stanislav Brabec wrote:

...
Michael Wolf wrote:

...
I don't propose writing our own, of course. There's no need.

We even may start with osc - osc is based on svn and their authors could help us with accessing its svn functions.

As far as I can tell, osc is based on svn only insofar as its user interface for checking in packages is similar.

I'm not averse to osc wrapping a proper revision control system (eg, osc diff, osc checkin, etc being based on their hg equivalents), but I am quite convinced that:

As far as I remember the discussion, OSC internal data are stored in a svn repository. osc log and osc co -r are already wrapped, tagging, branching etc. are not yet.

...

a) We will sometimes want or need a way to drop down into lower-level and more powerful tools AFAIK it's not possible yet.

-- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Stanislav Brabec

14:55

Michael Wolf píše v Pá 05. 10. 2007 v 09:31 -0500:

...

On Fri, 2007-05-10 at 11:40 +0200, Stanislav Brabec wrote:

...
Michael Wolf wrote:

...
I don't propose writing our own, of course. There's no need.

We even may start with osc - osc is based on svn and their authors could help us with accessing its svn functions.

...

As far as I can tell, osc is based on svn only insofar as its user interface for checking in packages is similar.

I'm not averse to osc wrapping a proper revision control system (eg, osc diff, osc checkin, etc being based on their hg equivalents), but I am quite convinced that:

a) We will sometimes want or need a way to drop down into lower-level and more powerful tools

b) Something distributed is the way to go.

...
...
But to say that revision control doesn't work well for packages? I don't buy it.

It was my practical experience.

In December 2006 we branched ~280 packages to G:U to move packages to /usr.

I did a complete backup of all packages in the branch point.

G:U changed ~250 packages.

Factory changed ~30 packages.

There was ~30 packages with paralles changes.

In late January 2007 I went to merge both branches.

...
From those ~30 packages, ~20 was fixed by a simple merge and ~10 had to be merged manually.

The major problems of simple diff-patch-wiggle are:

- Upstream updated package and fixed the same problem in parallel. Added patch is rendered obsolete.

- Changes are in the same patch. Second level patch are often hard to apply (code change -> patch change -> second level patch cannot apply).

- Changes in spec preamble often conflict - upgrade changes patch sets, fix does it as well. You have to merge patch set as first in order.

Right. Well, conflicts are a fact of life, whether it comes to personal opinions or changes made to text files. :)

Also we have plans to improve our .specs so that, among other things, it'll be obvious that a patch is expected to appear upstream and is therefore a candidate for removal.

Michael Wolf

3 Oct 3 Oct

22:29

On Wed, 2007-03-10 at 12:16 -0400, JP Rosevear wrote:

...

On Wed, 2007-10-03 at 10:24 -0500, Michael Wolf wrote:

...
** Workflow

Doing our ongoing development in GNOME:UNSTABLE will make it easier for anyone interested in contributing to do so.

When will we start this? ie should we be submitting internally only still for now?

Yes, until we flick a switch. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Joe Shaw

16:30

Hi, On 10/3/07, Michael Wolf wrote:

...

* GNOME:UNSTABLE

We'll also repopulate GNOME:UNSTABLE with the contents of the revelant packages as they currently exist in Factory. However, the future of this repository will be different. When GNOME 21 comes out, we'll be tracking it closely.

At the same time, we'll stop directly updating the GNOME packages directly in Factory. Instead, packages from GNOME:UNSTABLE will be (automatically, I hope) synced to Factory on a regular basis.

Tarballs for GNOME 21.1 are due on 20071029, so we'll start updating it then, but we can start improving our .specs as discussed in http://en.opensuse.org/GNOME/Patches sooner than that.

How will this setup work when it comes time to release a new version of openSUSE? In particular, what version (and from repo) will we ultimately ship GNOME from? How does the alignment of GNOME releases and openSUSE releases affect this? Etc. Joe -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Michael Wolf

4 Oct 4 Oct

00:23

On Wed, 2007-03-10 at 12:30 -0400, Joe Shaw wrote:

...

Hi,

On 10/3/07, Michael Wolf wrote:

...
* GNOME:UNSTABLE

We'll also repopulate GNOME:UNSTABLE with the contents of the revelant packages as they currently exist in Factory. However, the future of this repository will be different. When GNOME 21 comes out, we'll be tracking it closely.

At the same time, we'll stop directly updating the GNOME packages directly in Factory. Instead, packages from GNOME:UNSTABLE will be (automatically, I hope) synced to Factory on a regular basis.

Tarballs for GNOME 21.1 are due on 20071029, so we'll start updating it then, but we can start improving our .specs as discussed in http://en.opensuse.org/GNOME/Patches sooner than that.

How will this setup work when it comes time to release a new version of openSUSE? In particular, what version (and from repo) will we ultimately ship GNOME from? How does the alignment of GNOME releases and openSUSE releases affect this? Etc.

Good questions. GNOME 2.22.0 is about 6 months away, and openSUSE 11.0 is about 8 months away. So, assuming we will ship 2.22.0 in 11.0, then when 2.22.0 ships, we can create a new repository [0], populated from the contents of GNOME:UNSTABLE at the time. If we had real revision control, we'd call this a branch. After "branching", GNOME 2.23 can go into GNOME:UNSTABLE. Upon creation of that new repository, a switch will be flicked, and Factory will pull its updates from there. Upon release of 11.0, another set of switches will be flicked: Factory will once again pull from GNOME:UNSTABLE, and 11.0 internally will pull from that new repository. Does that make sense? Is it even what you were asking about? (jpr on irc thought you were asking about something else, but I'll answer the question as I understood it. :)) This is complicated, but I haven't worked out a better way to invite people who don't work for Novell to get more involved than they already are. I think it would be greatly simplified if we used bzr, hg, or git [1] throughout. [0] What to call it? GNOME:Factory? GNOME:2.22.x? GNOME:11.0? I think the latter, GNOME:11.0, makes the most sense, since fixes for our stuff, post 11.0 release, should continue going through the Build Service. [1] I guess this makes the order of my preferences obvious, but I'd be a lot happier with any of them than I am now. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Joe Shaw

20:29

Hi, On 10/3/07, Michael Wolf wrote:

...

GNOME 2.22.0 is about 6 months away, and openSUSE 11.0 is about 8 months away. So, assuming we will ship 2.22.0 in 11.0, then when 2.22.0 ships, we can create a new repository [0], populated from the contents of GNOME:UNSTABLE at the time. If we had real revision control, we'd call this a branch. After "branching", GNOME 2.23 can go into GNOME:UNSTABLE.

Upon creation of that new repository, a switch will be flicked, and Factory will pull its updates from there.

Upon release of 11.0, another set of switches will be flicked: Factory will once again pull from GNOME:UNSTABLE, and 11.0 internally will pull from that new repository.

Does that make sense? Is it even what you were asking about? (jpr on irc thought you were asking about something else, but I'll answer the question as I understood it. :))

Yep, it makes sense and was what I was asking. Your original email implied to me that we'd always be pulling from G:U, which obviously isn't the right thing to do for openSUSE releases. The additional info was what I was after. Sounds like you've got it all under control. :) Thanks, Joe -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org

Igor Jagec

3 Oct 3 Oct

18:22

On Sri, 2007-10-03 at 10:24 -0500, Michael Wolf wrote:

...

* GNOME:STABLE We'll repopulate GNOME:STABLE with the contents of the relevant packages as they currently exist in Factory. As a result, GNOME:STABLE will soon include GNOME 2.20.0. Because we'll be upgrading GNOME:STABLE to 2.20.1 soon (20071017), we'll be copying packages, not linking them.

I must say I'm a bit confused about the repos. Speaking about GNOME Stable repo, how stable it really is? I'm quite new to openSUSE so I'm not quite sure what repos should I use, but I would like to use GNOME Community and GNOME Stable (if it is really as safe as SUSE's supplied version of GNOME). Cheers! -- Igor Jagec

6054

Age (days ago)

6056

Last active (days ago)

List overview

Download

17 comments

7 participants

participants (7)

Federico Mena Quintero
Igor Jagec
Joe Shaw
JP Rosevear
Michael Wolf
Rodrigo Moya
Stanislav Brabec