[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Fwd: KDE Frameworks Release Cycle
From:       Scott Kitterman <kde () kitterman ! com>
Date:       2014-05-20 11:19:59
Message-ID: 37beaf3d-c6ed-42dd-9ff9-00d31bd16783 () email ! android ! com
[Download RAW message or body]

On May 20, 2014 4:19:26 AM EDT, Jos Poortvliet <jospoortvliet@gmail.com> wrote:
> On Tuesday 20 May 2014 19:07:41 Ben Cooksley wrote:
> > On Tue, May 20, 2014 at 6:04 PM, Kevin Ottens <ervin@kde.org> wrote:
> <snip>
> > > Now, I think we'll have to agree to disagree on something. You
> believe
> > > there's some rule written in stone somewhere which will make the
> > > "everyone will pile up backports only" the new status quo forever,
> I say
> > > let's try and find out.
> > In the meantime, everyone but the developers will suffer.
> 
> Yes, and saying no to every proposal won't change that.
> 
> I believe that the only advantage of the current situation (slow
> release 
> cycle with a period of 'bugfixes' that go untested) seems to be that it
> is a 
> known evil: we're lying about them being stable bugfix releases but the

They are almost completely bugfix. Every now and then something slips through, but \
those are mistakes. 

We (packagers) know exactly how much testing gets done upstream, so we test them \
before releasing to our users. 

No, they aren't perfect, but they are by and large what they claim to be.

> release numbering and lack of new dependencies makes the distro
> management 
> believe the story.
> 
> Perhaps, as proposed, going for a cycle where only the January and July
> 
> releases introduce a major version number and mandatory new
> dependencies 
> while the other releases are minor-numbered (but otherwise
> unconstrained in 
> features as long as new dependencies are optional) means we improve on
> the 
> current situation (minor/bugfix releases don't get tested very well)
> while 
> also loosing a little (there are new, but optional, dependencies and
> new 
> features).
> 
> The packagers can simply go to distro management and call this bugfix 
> releases, as they will (arguably) be more stable than what they
> currently 
> accept as 'bugfix releases'. And the developers get what they want,
> too.
> 
> So after 5.0, 5.0.1 is released with minor features and bugfixes (but
> no 
> mandatory changes in dependencies at all); which continues until
> January, 
> when 5.1 comes out, with new dependencies and changes.
> 
> Consider the potential new API's and components introduced after 5.0 as
> 
> 'experimental' until January.

So your big plan is we intentionally lie about it? I don't think so. 

We've pushed nearly every point release to end users throughout the KDE4 cycle. I use \
them myself. Your characterization of the KDE4 point releases doesn't match my \
experience. 

The first time through on this topic, what fraction of packagers said they saw this \
new release strategy as an improvement?  On the kde-core-devel version of this \
discussion it was claimed the goal of the change was to get KF5 fixes out to app \
developers sooner so they wouldn't work around KF5 issues in their code.

App developers are going to write code that can be deployed. This approach to KF5 \
releases is, I believe, going to have the opposite effect. 

Scott K

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


[prev in list] [next in list] [prev in thread] [next in thread]