More Plasma bug fix releases

Wed Oct 28 18:13:58 UTC 2015

Moin,

Let's look at an example: we wanna push the patch releases to debian:

On the one side we have unstable and testing. There the mantainer can upload 
most time a new version (if it is not frozen for the upcomming stable release 
~ three moth before the release). And any new version inside unstable will end 
up automatically after 5 days without any release critical bug in the testing. 
So far so good -> the only bottleneck i see here of shipping new releases is 
manpower / automatisation power.

But there is also debian stable (also kubuntu LTS,...), that most users are 
using. And debian stable is time based, and no updates are allowd by default. 
Only if a maintainer steps up and explains the release team, why a change is 
needed (closing these bugs etc) this is allowed to been pushed. That's where a 
patch tracker would help me to explain the release team: look we have these 
bugs at the packages (debian bug tracker) - upstream also took care about 
these and fixed them properly and additionally, they fixed these three other 
bugs too and they are marked as serious. Than I have better arguments to get 
this into debian stable. I think a patch tracker could help here to get an 
overview:  these distros also applied the patches and or had these questions 
about the patches. Maybe I also see, there okay, if I want to fix that bug 
properly than I also need to fix that other package...

For me the patch tracker is nothing, because I do not trust you as mantainer 
of KWin. I see it more as meta informations about patches, to be able to use 
it as argument for pushing things more easily futher down to the user.

Also one note: On debian side it is like that, every diff against debian 
stable is reviewed by the release team, so the diff must close serious bugs 
and should be as minimal as possible (but this should a stable fix anyhow :)

Regards,

sandro

--
Am Mittwoch, 28. Oktober 2015, 00:52:34 schrieb Albert Astals Cid:
> 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 good.
> 
> > 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
> that.
> 
> 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,
>   Albert
> 
> > Cheers, Eric
> 
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team
-------------- 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/6c25e92e/attachment.sig>