[OM Cooker] Regarding Rolling Releases
Alexander Stefanov-Khryukin
nobodydead at gmail.com
Tue Sep 6 10:01:50 EDT 2016
>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 <rugyada at gmail.com>:
> 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 <bero at lindev.ch>:
> > 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 <robxu9 at gmail.com>:
> >>
> >> 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
> >> OM-Cooker at ml.openmandriva.org
> >> http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml.
> openmandriva.org
> >
> >
> > _______________________________________________
> > OM-Cooker mailing list
> > OM-Cooker at ml.openmandriva.org
> > http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml.
> openmandriva.org
> >
> >
> >
> > _______________________________________________
> > OM-Cooker mailing list
> > OM-Cooker at ml.openmandriva.org
> > http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml.
> openmandriva.org
> >
>
>
>
> --
> ____________________
> Best regards,
> Cristina
>
> _______________________________________________
> OM-Cooker mailing list
> OM-Cooker at ml.openmandriva.org
> http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml.openmandriva.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.openmandriva.org/pipermail/om-cooker_ml.openmandriva.org/attachments/20160906/e0201c49/attachment-0001.html>
More information about the OM-Cooker
mailing list