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
