-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 21.01.2013 17:03, schrieb Ralf Lang:

Am 21.01.2013 16:58, schrieb Stephan Kulow:

...

Hi,

...

I'm still getting tons of stupid version updates thrown at me. Get real guys - unless you come up with *really* good arguments *on this list* I don't see any reason to take it.

...

Greetings, Stephan

I don't feel guilty this time, however:

I think the "forward to factory" button is auto-ticked and not prominent enough on the SR accept screen, so users may accidentally forward SRs to factory when they don't explicitly want to.

The question arises why I would accept a thoughtless, untested version update into the devel project at this point of time. Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlD9a2EACgkQwFSBhlBjoJac9QCeMpxfFm5rp8oxFQSXWG6tK2ig 3XwAnRW4zic7rgbuN5iFtyCIQXoi0ZY5 =/4N5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 01/21/2013 11:22 AM, Stephan Kulow wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Am 21.01.2013 17:03, schrieb Ralf Lang:

...

Am 21.01.2013 16:58, schrieb Stephan Kulow:

...

Hi,

...

I'm still getting tons of stupid version updates thrown at me. Get real guys - unless you come up with *really* good arguments *on this list* I don't see any reason to take it.

...

Greetings, Stephan

I don't feel guilty this time, however:

I think the "forward to factory" button is auto-ticked and not prominent enough on the SR accept screen, so users may accidentally forward SRs to factory when they don't explicitly want to.

The question arises why I would accept a thoughtless, untested version update into the devel project at this point of time.

Just because the "acceptor" of the SR into the devel project follows the "auto submit to factory" (by accident or intention) does not imply that the request is thoughtless or untested. I would argue that the devel project maintainers should be protected from themselves and release managers should be protected from auto submits after feature freeze. This implies that after feature freeze anything that goes through "auto submit" goes to a queue or that "auto submit" is disabled between feature freeze and branch. All of this should be reasonably easy to implement and will be more effective than expecting every devel project maintainer to remember at every hour of every day that we are now in feature freeze mode. My $0.02 Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 01/21/2013 04:15 PM, Stephan Kulow wrote:

Am 21.01.2013 20:39, schrieb Robert Schweikert:

...

I would argue that the devel project maintainers should be protected from themselves and release managers should be protected from auto submits after feature freeze. This implies that after feature freeze anything that goes through "auto submit" goes to a queue or that "auto submit" is disabled between feature freeze and branch.

All of this should be reasonably easy to implement and will be more effective than expecting every devel project maintainer to remember at every hour of every day that we are now in feature freeze mode.

You're serious? I'm having a hard time replying to this - it sounds like a bad joke. You make it sounds as if it depends on the moon phase if we're in feature freeze or not.

Sorry, I did not mean to imply that we are depending on the moon or the way the stars happen to be aligned. We do have a public and well presented schedule and in general we stick to it and I like that ;) . However, people that do not work with it every day do forget, obviously or this thread would have never started. Therefore a little help from the tools can only be to everyone's advantage. I think our tools should be smart enough to know when to "auto forward" and when not to based on the state of the release. As release manager you should be able to set a flag that says "feature freeze". From that point forward until branch all auto-submit SRs should go into a queue. Thus, you would only see the bugfix SRs. The SRs that get auto submitted are marked as "pending factory branch" thus we should avoid the "my SR has not been accepted" e-mail issue, for the most part. With such an automated queuing system we get the best of both worlds: - release managers do not see any auto-submits for version updates at inopportune times in the release cycle (the reason for this thread) - devel project maintainers can still accept version bumps in the devel project without having to keep a list of "these packages need to go to factory after branch" because the autosubmit feature does that for them (the reason for some of the replies to this thread) - when we branch for the new release all the queued SRs are released and factory moves forward right away. As I have never peeked under the lid of the build service I can only proclaim that his "shouldn't be that hard" and if it turns out to be hard I can proclaim ignorance ;) Thus, sorry for making it sound like our release cycle is willy-nilly, it certainly isn't and I did not mean to imply that. With that out of the way, I do think there is room for improvement in the tools area that should be reasonably straight forward to implement. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried writes:

One example is that we should start testing bluez5, which surely never will go into 12.1, 12.2, 12.3. But should we delay it until summer just to wait until 12.3 is out of the door?

Agreed, but usually coolo isn't that a bad guy and will probably create the branch some weeks earlier.

No, this implies that at the time of the feature freeze, 12.3 project should have been created and detached from Factory.

For us packagers this would be handy. Otherwise it might happen again that I forget to submit something from a devel project ;-( -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 23/01/13 10:09, Stephan Kulow escribió:

We're at 47 problems now -

I am trying to do my part getting rid of part of this 47 problems, but it seems insanity has taken over the review team, the only thing missing now is a grammar police with the cops knocking at my door. So sad that this absurd nitpicking now takes precedence over getting stuff building and running. I just give up and somebody else with patience can take over. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Quoting Sascha Peilicke :

Am 24. Januar 2013 01:51:49 schrieb Cristian Rodríguez :

...

El 23/01/13 10:09, Stephan Kulow escribió:

...

We're at 47 problems now -

I am trying to do my part getting rid of part of this 47 problems, but it seems insanity has taken over the review team, the only thing missing now is a grammar police with the cops knocking at my door.

So sad that this absurd nitpicking now takes precedence over getting stuff building and running.

I just give up and somebody else with patience can take over.

Christian, whats the issue here? I suspect you got a review declined for disputable reasons? Generally it is worth discussing this either with the reviewer or the review@ ML. Reviewers can't know everything and they (I should say we) make mistakes. And at times, they receive a lot of heat for that :-)

Very much assuming that the issue is #149730: this was actually declined BEFORE it reached the review team. It's the games maintainer which refused to accept a patch that hides much more inside than what is documented. It is not exactly the first time such patches are being submitted, claiming to do one thing and in the same patch doing much more.

But I assume the intent was to respect our policies and to keep the packaging quality high (and we achieved quite a bit with regards to that). Of course that can collide with the short term goal of fixing Factory build errors ASAP. So I would recommend solving this with the reviewer directly. Or you explain the issue here (neutrally) and leave the reviewer a chance to clarify, so that we all can learn something.

'Fixing' Factory should not go directly on cost of packaging quality... Those two are not mutually exclusive, if people respect them to start with... Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Jan 24, 2013 at 6:49 PM, Cristian Rodríguez wrote:

- hours arguing about a piece of text that NOBODY reads (aka. the changelog)

I have stupid habit of reading changelogs and moreover, believing what is written there. May be I'm just an old fart. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 24/01/13 13:04, Dominique Leuenberger a.k.a. Dimstar escribió:

Quoting Cristian Rodríguez :

...

- 30 minutes to fix the actual problem.

- hours arguing about a piece of text that NOBODY reads (aka. the changelog)

the hour could easily be saved by 'taking the advice'

What happends if the advice and the rules are completely insane ? I have the right to question them. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 24/01/13 12:51, Ralf Lang escribió:

I think rule-making should happen on the discussion list,

I agree, however this is not the way things were done, nobody voted, someone just put in place a set of rules of dubious value and decided to enforce them. This set of rules is probably one of the reasons that the number of new developers is so low or non-existent. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 24/01/13 13:32, Guido Berhoerster escribió:

* Cristian Rodríguez [2013-01-24 17:16]:

...

El 24/01/13 12:51, Ralf Lang escribió:

...

I think rule-making should happen on the discussion list,

I agree, however this is not the way things were done, nobody voted, someone just put in place a set of rules of dubious value and decided to enforce them.

We had this exact same discussion back in October and it was only you making a drama out of writing a couple of lines of useful changelog entries.

I am not making any drama, I'm telling crytal clear that I disagree with this rules, which were: a) not subject of any discussion b) not subject of cost-benefit analysis

...

This set of rules is probably one of the reasons that the number of new developers is so low or non-existent.

See the statistics by Andreas and me on -project from May last year which suggest the exact opposite, that is a growing number of contributions.

That numbers probably do not count people that became frustrated and gave up. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 24/01/13 14:01, Guido Berhoerster escribió:

Changes of policy without discussion happen and that's certainly not OK, e.g. see the recent change of default configuration in systemd breaking every desktop environment.

That's a completely different topic.

And we do even have a formal process for that now: http://en.opensuse.org/openSUSE:Packaging_guidelines_change_process

So, in short I am expected to spend MORE time in a bureaucratic process that is already crazy ? no thanks. I would rather play guitar or hack into something else. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 01/23/2013 04:38 AM, Karl Eichwalder wrote:

Stefan Seyfried writes:

...

One example is that we should start testing bluez5, which surely never will go into 12.1, 12.2, 12.3. But should we delay it until summer just to wait until 12.3 is out of the door?

Going to be picky on purpose, with the intend to tone down the hyperbole a bit. 12.3 will release in March, we will have a branch for 12.3 prior to March, thus bluez5 can be expected to proceed to factory in late February or early March. This, at least on the calendar for the northern hemisphere is way before Summer.

Agreed, but usually coolo isn't that a bad guy and will probably create the branch some weeks earlier.

...

No, this implies that at the time of the feature freeze, 12.3 project should have been created and detached from Factory.

For us packagers this would be handy. Otherwise it might happen again that I forget to submit something from a devel project ;-(

That's the point of the queue, you would not forget to submit to factory, you still "auto forward" the SR just shows up in Factory after the product branch is created. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Quoting Stefan Seyfried :

Am 21.01.2013 20:39, schrieb Robert Schweikert:

...

I would argue that the devel project maintainers should be protected from themselves and release managers should be protected from auto submits after feature freeze.

I would argue that Factory contributors should be protected from "feature freeze" for a Product they are not submitting for.

I'm submitting stuff to Factory if I think it's ready for Factory. If I think it is an important fix for 12.2, I submit it to 12.2. 12.3 likewise.

Err... aren't we all working on the 'next release of openSUSE', which at this time happens to be 12.3? Factory is not a distribution of it's own.. it's the 'sandpit' where we work towards the goal of reaching 12.3. The upmost goal of every contributor to Factory should be a solid release, no?

One example is that we should start testing bluez5, which surely never will go into 12.1, 12.2, 12.3. But should we delay it until summer just to wait until 12.3 is out of the door?

12.3 will be out in March.. In countries in the northern hemisphere this is the transition from Winter to Spring (still far from Summer).. arguably, of course, in the south, this is AFTER summer... so no issue there :)

...

This implies that after feature freeze anything that goes through "auto submit" goes to a queue or that "auto submit" is disabled between feature freeze and branch.

No, this implies that at the time of the feature freeze, 12.3 project should have been created and detached from Factory.

IF we would do that, this would result, as coolo already mentioned, in a full distraction of resources to Factory and having 12.3 split off and kept in bad state... if THIS is the way the project is heading, I see a big sign of doom at the end of the tunnel... We should strive to increase the quality of the distribution (which is especially measured on the dates of releases) and not increase the rate of breakages... Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Quoting Stefan Seyfried :

Am 23.01.2013 11:17, schrieb Dominique Leuenberger a.k.a. Dimstar:

...

...

No, this implies that at the time of the feature freeze, 12.3 project should have been created and detached from Factory.

IF we would do that, this would result, as coolo already mentioned, in a full distraction of resources to Factory and having 12.3 split off and kept in bad state... if THIS is the way the project is heading, I see a big sign of doom at the end of the tunnel...

Not testing new software early enough also will *not* make the product better. We're both right -- only history will tell who's more right :-)

nobody stops you from having a staging devel repo and 'test' that on your system... Example of this approach is the entire gnome stack: - The Factory devel prj is GNOME:Factory.. this has been version frozen last year in October (frozen to the 3.6 branch.. not on the exact version). Simply because the planning clearly showed: gnome 3.8 will not make it into 12.3 (release is shortly after ours only). BUT: That did not stop us from still packaging up the entire 3.8 stack already.. just, it's done in a staging project (GNOME:Next) which is a branched off variant of GNOME:Factory... once in a while (well, with every factory fix), of course, I have to rebase that project on top... but that's the price to pay for a solid release...

I don't care too much -- I'll just linkpac everything installed on my box from the devel projects into home:seife:testing and update from there :-)

So, why not use this approach but be a bit more 'strict' if you only linkpac or do even some version upgrades before you push them to the mass? Everybody would for sure appreciate if the package has the most annoying bugs worked out before they see it. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 23.01.2013 10:52, Stefan Seyfried wrote:

However, if Factory gets out of sync with reality for > 2 Months, I'll need a bit more than just the few packages of mine in there :-)

Yeah, but can we discuss *that* problem if we have it and not now? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, Andrey, On Thu, Jan 31, 2013 at 4:58 PM, Andrey Borzenkov wrote:

Sorry for stupid question but where this button is? I just was hit by this and I could not find where I say "no". I have either submit or decline.

https://build.opensuse.org/request/show/150248 I don't know if you have the permission to view this SR. but this SR can exist enough long without occasionally getting accepted or declined before the thread ends. There's a checkbox BELOW the title: Submit package M17N:Devel / xxx to package M17N / xxx [*] Forward to developed package openSUSE:Factory / xxx The option is shown only when you SR to the devel package in a devel repository for openSUSE Factory (There're other cases but this is the most common one). I don't know if only repository maintainers can see it. But it do exist there. Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 21.01.2013 20:09, schrieb Lars Müller:

On Mon, Jan 21, 2013 at 04:58:35PM +0100, Stephan Kulow wrote:

...

I'm still getting tons of stupid version updates thrown at me. Get real guys - unless you come up with *really* good arguments *on this list* I don't see any reason to take it.

Samba 4.0.1 is one of those. I'm sorry but we had some trouble to get it not only building but also working earlier, before Jan 17th.

See https://build.openSUSE.org/request/show/149418

Yeah, I'm sorry if I made it not clear enough - but Lars, how is "we had some trouble", a really good argument? Greetings; Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlD9sOsACgkQwFSBhlBjoJY4tACgw4eWSxqKi+OsvS7R6SVyUAWL w7YAoM+BtroqGrDqFhmvl4TEsrJAOZrn =XPRe -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Quoting Cristian Rodríguez :

El 21/01/13 12:58, Stephan Kulow escribió:

...

Hi,

I'm still getting tons of stupid version updates thrown at me. Get real guys - unless you come up with *really* good arguments *on this list* I don't see any reason to take it.

OK, then why isnt the product branched so factory can move along regardless of the release status ?

Because we are supposed to do bugfixes for the release, branching it off early will result in everyone ignoring and submitting shitloads of new stuff to Factory. -- SUSE LINUX Products GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 21 January 2013, Stephan Kulow wrote:

Am 21.01.2013 20:47, schrieb Cristian Rodríguez:

...

El 21/01/13 12:58, Stephan Kulow escribió:

...

Hi,

I'm still getting tons of stupid version updates thrown at me. Get real guys - unless you come up with *really* good arguments *on this list* I don't see any reason to take it.

OK, then why isnt the product branched so factory can move along regardless of the release status ?

Because this would mean even less testing and bug fixing. Are you in here for a great product or for a quick version update? If the latter, develop in your home project for the time being.

I don't understand the whole issue. For my understanding the devel projects are there for development. I submit to them whenever I feel I've made something useful whithin my home projects. It's up to the devel project owner to submit it to factory at the right time. The auto-submit thing may not be really helpful here ... but that's not my problem. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org