On Thu, Oct 29, 2015 at 9:11 AM, Sandro Knauß <[email protected]> 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 [email protected]... (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 >> [email protected] >> https://mail.kde.org/mailman/listinfo/release-team > > _______________________________________________ > release-team mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/release-team > _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
