Re: [opensuse-buildservice] How to manage a product with very frequent releases and no maintenance for each release
Julio González Gil wrote:
On viernes, 7 de septiembre de 2018 14:41:54 (CEST) Ludwig Nussel wrote:
Julio González Gil wrote:
We basically want to release each two/four/six weeks a new version, starting with 4.0, promoting packages from systemsmanagement:Uyuni:Master (development project) to some place.
Check the :ToTest mechanism of Factory.
I think this is exactly what I could need!
However I see at https://build.opensuse.org/project/show/ openSUSE:Factory:ToTest that the project is described as "This project does not build, it is just for storing snapshots used for automated testing. The result is released as Tumbleweed" but https://build.opensuse.org/package/ view_file/openSUSE:Factory:ToTest/000product/ _service:product_converter:openSUSE-ftp-ftp-i586_x86_64.kiwi?expand=1 seems to be publishing to <productoption name="REPO_LOCATION">http:// download.opensuse.org/tumbleweed/repo/oss/</productoption>
It's not relevant what is in that file. The point about the mechanism is that the main project can be used for building and only if it's done building the packages are moved over to :ToTest for testing by openQA. Based on that the result is released or held back.
Between one version and the other, there will be no maintenance. Each change, whatever itis, will required a new release and version.
You could see it as Tumbleweed to some extent, but with a big difference: we really want to have versions, as Leap or SLE, but unlike Leap or SLE, very frequent releases.
Tumbleweed does have an integer number as version that can be displayed as date. Just not coded into the project name in OBS. By default OBS only publishes the last version of the repo to download.o.o. There is work in progress to keep some previous snapshots around though: http://release-tools.opensuse.org/2018/02/26/Tumbleweed-snapshot-review-site .html
Yes, I had a look at https://github.com/boombatower/tumbleweed-cli/blob/ master/tumbleweed which is mentioned at one of the links of your link above, but as you said, the snapshots are not ready yet.
Since you mentioned that "by default OBS only the last version of the repo to download.o.o", is there a switch I can change at the prjconfig, meta or _product to change that behaviour?
No, we have scripts on download.opensuse.org side that implement the history outside OBS. Nevertheless if that is a more often requested feature, maybe the OBS team wants to implement it after all ... :-) What I wanted to say is that instead of jumping through hoops creating subprojects etc (where users would have to change their repos), just stick with the one project approach. If historic repo versions turn out to be really needed, OBS should implement means for that. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Mon, Sep 10, 2018 at 10:29 AM Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Julio González Gil wrote:
Since you mentioned that "by default OBS only the last version of the repo to download.o.o", is there a switch I can change at the prjconfig, meta or _product to change that behaviour?
No, we have scripts on download.opensuse.org side that implement the history outside OBS. Nevertheless if that is a more often requested feature, maybe the OBS team wants to implement it after all ... :-)
What I wanted to say is that instead of jumping through hoops creating subprojects etc (where users would have to change their repos), just stick with the one project approach. If historic repo versions turn out to be really needed, OBS should implement means for that.
This would actually be really helpful for what I do for our internal OBS. It's been a sticking point that we don't have a way to flag in prjconf or meta that repo publishing should be multiversioned (for RPMs and DEBs). -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On lunes, 10 de septiembre de 2018 17:18:07 (CEST) Neal Gompa wrote:
On Mon, Sep 10, 2018 at 10:29 AM Ludwig Nussel <ludwig.nussel@suse.de>
What I wanted to say is that instead of jumping through hoops creating subprojects etc (where users would have to change their repos), just stick with the one project approach. If historic repo versions turn out to be really needed, OBS should implement means for that.
This would actually be really helpful for what I do for our internal OBS. It's been a sticking point that we don't have a way to flag in prjconf or meta that repo publishing should be multiversioned (for RPMs and DEBs).
The subprojects would be only as a way of storing old versions, in case somebody needs, for example, to test migration starting from a new server. But of course our idea is that a regular user would be able to upgrade by just running "zypper up" + the regular steps we already have for SUSE Manager, from a static repository from a static project (let's say systemsmanagement:Uyuni:Stable or something similar). -- Julio González Gil <jgonzalez@suse.com> Release Engineer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
On Montag, 10. September 2018, 17:22:14 CEST wrote Julio González Gil:
On lunes, 10 de septiembre de 2018 17:18:07 (CEST) Neal Gompa wrote:
On Mon, Sep 10, 2018 at 10:29 AM Ludwig Nussel <ludwig.nussel@suse.de>
What I wanted to say is that instead of jumping through hoops creating subprojects etc (where users would have to change their repos), just stick with the one project approach. If historic repo versions turn out to be really needed, OBS should implement means for that.
This would actually be really helpful for what I do for our internal OBS. It's been a sticking point that we don't have a way to flag in prjconf or meta that repo publishing should be multiversioned (for RPMs and DEBs).
The subprojects would be only as a way of storing old versions, in case somebody needs, for example, to test migration starting from a new server.
But of course our idea is that a regular user would be able to upgrade by just running "zypper up" + the regular steps we already have for SUSE Manager, from a static repository from a static project (let's say systemsmanagement:Uyuni:Stable or something similar).
so just keeping N versions or build results for X days would be enough? This can indeed become a functionality of the publisher relativ easy. But manual tagging would be something what needs to be done via releasing to another project/repo. -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Mon, Sep 10, 2018 at 12:13 PM Adrian Schröter <adrian@suse.de> wrote:
On Montag, 10. September 2018, 17:22:14 CEST wrote Julio González Gil:
On lunes, 10 de septiembre de 2018 17:18:07 (CEST) Neal Gompa wrote:
On Mon, Sep 10, 2018 at 10:29 AM Ludwig Nussel <ludwig.nussel@suse.de>
What I wanted to say is that instead of jumping through hoops creating subprojects etc (where users would have to change their repos), just stick with the one project approach. If historic repo versions turn out to be really needed, OBS should implement means for that.
This would actually be really helpful for what I do for our internal OBS. It's been a sticking point that we don't have a way to flag in prjconf or meta that repo publishing should be multiversioned (for RPMs and DEBs).
The subprojects would be only as a way of storing old versions, in case somebody needs, for example, to test migration starting from a new server.
But of course our idea is that a regular user would be able to upgrade by just running "zypper up" + the regular steps we already have for SUSE Manager, from a static repository from a static project (let's say systemsmanagement:Uyuni:Stable or something similar).
so just keeping N versions or build results for X days would be enough?
N versions based on committed sources, with maybe also a fade-out (by X days) for old versions in repos. This would be especially useful for us for "CI projects", where we want to push something and keep latest-N as well as maybe latest-N for X days to give people an opportunity to test. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (4)
-
Adrian Schröter -
Julio González Gil -
Ludwig Nussel -
Neal Gompa