More Plasma bug fix releases

Thu Oct 29 07:48:34 UTC 2015

On Thu, Oct 29, 2015 at 9:11 AM, Sandro Knauß <sknauss at kde.org> wrote:
> Moin,

Hi,

>
> 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

This comment reads to me that bugs in anything but the Debian bug
tracker is invalid.
I certainly hope the Debian Release Team isn't that elitist - they
should certainly be accepting upstream bug trackers.
If they don't, perhaps they would like to be connected to the firehose
that is kde-bugs-dist at kde.org...

(Ignoring the fact they think they're more qualified than upstream to
review the suitability of patches - something I find quite arrogant).

> 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

Regards,
Ben

>
> --
> 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
>
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>