On Mon, Aug 24, 2009 at 03:10:22PM +0200, Stephan Kulow wrote:

Am Montag 24 August 2009 schrieb Petr Uzel:

...

what should we do with 'version update' requests coming to a devel project?

Since Factory is now frozen, by accepting such request, the code would diverge between the devel project and Factory and so further bugfixes through the devel project would be impossible.

On the other hand, declining/ignoring the request might upset the contributor and discourage him/her from any further contributions.

Don't ignore it, decline it with the comment that he should come back after 11.2. Sticking to rules is not something bad, the rules may not be known to everyone.

There are two reasons for the feature/version freeze for 11.2: - keep time to find (and preferable fix) the bugs in that specific version, don't replace them continuely with new bugs - keep developers from spending on new features and new versions, but fix the bugs found so far.

No doubts that version freeze is needed - I'm definitely not saying we should 'break' the rules just to make contributors happy.

Of course if someone comes along and has only one interest: the latest version for 11.1 and the 11.2 devel project is happen to be set to the only repo that has such new versions, then there is a problem.

In other words, there is a problem when the devel project also serves as a backports project - I think this holds for most devel projects. IMHO splitting such devel projects to 'real' devel project (used exclusively for Factory development) and backport project (no freeze, built for e.g. 10.3-11.1) might solve some of the problems. Benefits: - one can always update foo to newest version regardless of the Factory 'version freeze' period - if the backport project contained just source links to Factory/devel project, one can fix builds for older distros just by adding a patch without the need of submitting that to Factory What do you think?

But there is a solution I guess: copypac BAR foo BAR foo_next and then disable foo_next for factory and foo for older distros. Then after 11.2 you can merge it back. But of course it's up to your own responsiblity not to fall in the goal 2 trap.

This would also work, bit I'd consider it a workaround rather than a solution. -- Best regards / s pozdravem Petr Uzel, openSUSE Community Multiplier Team ----------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: puzel@suse.cz Lihovarská 1060/12 http://www.suse.cz 190 00 Prague 9, CR

2009/8/24 Pavol Rusnak :

Petr Uzel wrote:

...

In other words, there is a problem when the devel project also serves as a backports project - I think this holds for most devel projects. IMHO splitting such devel projects to 'real' devel project (used exclusively for Factory development) and backport project (no freeze, built for e.g. 10.3-11.1) might solve some of the problems.

Benefits: - one can always update foo to newest version regardless of the   Factory 'version freeze' period - if the backport project contained just source links to Factory/devel   project, one can fix builds for older distros just by adding a patch   without the need of submitting that to Factory

What do you think?

Yes, that sounds reasonable. But before we start to even think about it, we should try do decrease the number of devel projects. (As this change will double their count).

There is a problem because of the number of projects per se? I mean, the number of builds would be the same. The "Backports" project would not build for Factory... we want people that uses Factory to use Factory packages and nothing else, otherwise their testing would not be helpful. Sometimes openSUSE would have available a newer version of TuxRacer than Factory, but that should not be a problem. But, even if separated backport/devel projects would be cleaner, I think we can archieve the same with a single project. Using http://en.opensuse.org/Build_Service/Tips_and_Tricks#Using_different_spec_fi... one can create a foo.spec for backports and a foo-openSUSE_Factory.spec for devel. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, Aug 24, 2009 at 06:16:23PM +0200, Cristian Morales Vega wrote:

2009/8/24 Pavol Rusnak :

...

Petr Uzel wrote:

...

In other words, there is a problem when the devel project also serves as a backports project - I think this holds for most devel projects. IMHO splitting such devel projects to 'real' devel project (used exclusively for Factory development) and backport project (no freeze, built for e.g. 10.3-11.1) might solve some of the problems.

Yes, that sounds reasonable. But before we start to even think about it, we should try do decrease the number of devel projects. (As this change will double their count).

But, even if separated backport/devel projects would be cleaner, I think we can archieve the same with a single project. Using http://en.opensuse.org/Build_Service/Tips_and_Tricks#Using_different_spec_fi... one can create a foo.spec for backports and a foo-openSUSE_Factory.spec for devel.

Interesting idea. However, I'm afraid it won't work, because of the fact that Factory and backports might have different versions (that's what we want to achieve). And every change in backports would be propagated to Factory -> mess in Factory. IMHO the goal should be to keep Factory as clean as possible and build backport packages based on it (sourcelinks+patches). -- Best regards / s pozdravem Petr Uzel, openSUSE Community Multiplier Team ----------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: puzel@suse.cz Lihovarská 1060/12 http://www.suse.cz 190 00 Prague 9, CR

Stephan Kulow wrote:

Don't ignore it, decline it with the comment that he should come back after 11.2.

The problem is we mix the purpose of projects: the same project is used for Factory development, for the latest version of the packages and for the backports. :-/ -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Community Multiplier Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org