>his is e.g. when we'll move from KDE 5.x to 6.x We know what need to do here, need to implement.
>Health warnings should be put prominently This too. I suggest to mark with RED all critical packages, systemd,glibc, etc and we will mark username who pushed "publish" button 2016-09-06 15:32 GMT+03:00 rugyada <[email protected]>: > Hi, > > In the ideal world: > - the process works as much as possible more by means of automation > and less manual (agreeing Robert) > - packagers write a warning email at the beginning (I'm starting > update XYZ) and at the end (finished XYZ, you can run update now). > - cooker branch is the experiment field - and Lx is the stable > environment where only reliable packages are pushed > - people communicate and coordinate each other. > > Apparently we currently don't live in the ideal world, nor seems we wish > to do. > > > > > 2016-09-06 13:45 GMT+02:00 Bernhard Rosenkraenzer <[email protected]>: > > Hi, > > > > this is e.g. when we'll move from KDE 5.x to 6.x -- if we push one > package > > at a time, the "stable" repository will go insane for a bit with the > > plasma-desktop's requirements not matching the libraries. > > > > We need a way to move the whole set of packages that make up KDE 6.0 to > > stable at the same time. > > > > ttyl > > > > bero > > > > On 2016-09-06 13:40, Alexander Stefanov-Khryukin wrote: > > > > Hi. We are talking about with HisShadow about abf improvements > > and found that we don't understand what it is > > > > "We need to find a way to push 100 updates w/o causing the repositories > to > > go inconsistent. So maybe locking/unlocking publishing, batching updates > > from Cooker to Lx (snapshotting), and more." > > > > Please explain. > > > > 2016-09-06 8:18 GMT+03:00 Robert Xu <[email protected]>: > >> > >> At the last TC meeting, we talked for a good hour about rolling > releases. > >> Following that, we decided that it's not possible at this time -- mainly > >> because we need to be stricter about the way we do quality control and > we > >> need to automate more of our system. > >> > >> As if to somehow laugh at the situation, the "why broken pkgs are > >> released?" thread appeared, and it seems to have pushed more of the > issues > >> to the forefront. > >> > >> I've written up the situation we've established from the TC meeting at > >> https://github.com/robxu9/documents/blob/master/ > openmandriva/2016-09-06-QA-improvements.md, > >> and I'm looking for feedback. Especially: > >> > >> 1. How do we improve strict quality control? > >> 2. What can we do to improve project management? > >> 3. How can we enforce strict quality control and project management > usage? > >> > >> I hope this will be an ongoing discussion. If I should cross post this > to > >> the forums, let me know. > >> > >> -- > >> cheers, Robert :: rxu.io > >> > >> _______________________________________________ > >> OM-Cooker mailing list > >> [email protected] > >> http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml. > openmandriva.org > > > > > > _______________________________________________ > > OM-Cooker mailing list > > [email protected] > > http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml. > openmandriva.org > > > > > > > > _______________________________________________ > > OM-Cooker mailing list > > [email protected] > > http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml. > openmandriva.org > > > > > > -- > ____________________ > Best regards, > Cristina > > _______________________________________________ > OM-Cooker mailing list > [email protected] > http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml.openmandriva.org >
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml.openmandriva.org
