More Plasma bug fix releases

Albert Astals Cid aacid at
Tue Oct 27 23:52:34 UTC 2015

El Tuesday 27 October 2015, a les 15:31:45, Eric Hameleers va escriure:
> On Tue, 27 Oct 2015, Albert Astals Cid wrote:
> > El Tuesday 27 October 2015, a les 14:39:15, Eric Hameleers va escriure:
> >> On Tue, 27 Oct 2015, 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.
> >>> 
> >>> Cheers,
> >>> 
> >>>  Albert
> >> 
> >> You developers are so funny, my false teeth fell out from shaking.
> > 
> > I did a serious reply to your comment and all i got back was sarcasm,
> > please let's try to be constructive, otherwise what's the point of having
> > this discussions?
> > 
> > Do you really think we commit things that are not bugfixes to stable
> > branches?
> > 
> > Can you name some "meh stuff" that was commited to a stable branch and in
> > your opinion should have waited for the next major release?
> Says the master of sarcasm. 

The fact that i may have been not well behaved at some points in the past does 
not give anyone carte blanche to be badly behaved, two bads don't make one 

> I was being constructive. Please put on
> your release management hat.
> But you are indeed correct, I should adjust one of my statements, by
> s/major/minor/ ; patches should not have to wait for the next
> *major* release.

That's why we have stable releases, no?

> However, I id not interpret your reply as anywhere near serious. If
> your view of distro packaging is that the packager should follow the
> git commits from day to day, minute to minute then you need to adjust
> your view of distro development. It is OK for *developers* to sit on
> top of the git commits since that is what they do. A packager on the
> other hand needs proper releases, because that makes the
> user's experience of the distro deterministic and will add the
> developer in triaging the bug reports because he knows what source
> went into the distro. If the developer wants to push critical
> patches downstream, then the developer still wants deterministic
> behaviour from the binaries produced by the distros and therefore a
> proper patch-release management is crucial.

I didn't say distro packagers do not need a release, neither i did say that 
distro packagers should follow git.

In fact, I (and i'd say Sebas too) understood you were the one suggesting 

You said you wanted a patch tracker with all the fixes on top a release.

Sebas and me said that such a patch tracker is exactly what the stable branch 
is (as far as I understand it).


> Cheers, Eric

More information about the release-team mailing list