More Plasma bug fix releases

[Martin Graesslin]

On Tuesday, October 27, 2015 10:51:47 PM CET Heinz Wiesinger wrote:
> On Tuesday 27 October 2015 22:34:06 Albert Astals Cid wrote:
> > El Tuesday 27 October 2015, a les 14:18:01, Eric Hameleers va escriure:
> > > On Tue, 27 Oct 2015, Sebastian Kügler wrote:
> > > > On Tuesday, October 27, 2015 06:25:42 AM Eric Hameleers wrote:
> > > >> I like the idea of getting more visibility for bugfixes that will
> > > >> give
> > > >> the enduser a better Plasma experience. Ideal for me would be a patch
> > > >> tracker (not the same as a bug tracker) where intermediate patches
> > > >> are
> > > >> made available that are scheduled for inclusion in the next release.
> > > >> That allows me as a package builder to assimilate those patches if I
> > > >> think they can not wait until the next release.
> > > > 
> > > > That sounds like you just want the latest stable git branch, in this
> > > > example Plasma/5.5?
> > > 
> > > No, of course not. I consider the git branch to be in eternal flux.
> > > The git HEAD may contain valuable usability patches but also other meh
> > > stuff that can wait until the next major release. I do not want to dig
> > > through hashes and commits to find out whether you solved some
> > > blocking issue.
> > > A patch tracker, containing patches you (the developers) consider
> > > critical and which should find their way to the user ASAP, that is a
> > > place where I would look.
> > 
> > Yes, of course yes.
> > 
> > Every single patch commited to a stable branch is a bugfix and thus the
> > developer considers critical and should be released as soon as possible to
> > users, otherwise instead of to the stable branch the developer would
> > commited the patch to the development branch.
> 
> I guess this is one of the core issues we need to address somehow. What's
> considered "critical" differs between developers and packagers, even between
> packagers of different distributions. What Eric would like is a way to find
> really critical fixes that can't wait until the next point release. But
> again, what he considers critical might be something completely different
> from what a developer considers critical.
> 
> In the end, whether those fixes are provided as patches or patch releases
> probably won't change much on the packager side. The core question is always
> "do I consider the changes critical enough to spend time on it". *This* is
> the problem that afaiu you want to solve.
> 
> So I suppose it's less about the amount of releases, but more getting to a
> common understanding (on both sides) of what "critical" entails. What are
> the expectations of developers what should happen on the distribution side
> with "critical" fixes, and what are the expectations of packagers on what
> to consider "critical".

Let's put it quite simple: I as e.g. the KWin maintainer do the evaluation for 
each bug fix whether it's something which should go into the 5.4 branch or 
not. Do you trust me on that or not? If not how do you want to do the 
evaluation without any domain knowledge? Do you really think you can do a 
better job on evaluating the KWin bug fixes than I can? That would either mean 
I'm the wrong person in the job or you have a rather arrogant view on our 
work.

In the end it all boils down whether you trust us or not. If you don't trust 
us: we have a problem and I can only conclude with what sebas replied to this 
thread: "What I'd really like to see is that distros actually ship our 
updates."

Please remember: it costs us time to do bug fix releases. If distros think 
they can ignore it: hell, yeah, much more time for feature development for me. 
Doing a bug fix on a stable branch is way more work, than doing it on the 
feature development branch. Given what you wrote here about the trust model, 
you ignore our work put into that, which is sad.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20151028/b161e543/attachment.sig>