[OM Cooker] [om-qa] kahinah enhancements
Colin Close
itchka at compuserve.com
Thu Dec 8 14:21:48 EST 2016
I have explored the addition of Kahinah functionality to abf with Alexey (avokhmin). He did not think it was a practical solution but he felt that between kahinah and abf we could achieve what was needed.
I tried to define the task for him in this document https://github.com/OpenMandrivaSoftware/rosa-build/issues/13#issuecomment-256779214
and your own comments are welcome. I think it hightlights the main requirements and he has promised to review it at some point. I have tried a number of times to get some engagement from the Ruby experts but they are all pretty busy with their day jobs. This issue has been discussed in at least three time in TC's but we are no further forward because of resource limitations.
As for the mess kahinah is in there are a number of reasons for this.
The first is that I have not been able to give it my full attention as I have been using the majority of my spare time on another OpenMandriva project, fortunately this was completed yesterday so I will be able to devote more time to cleaning it up.
The second is that jobs like updating KDE and it apps cause instability of peoples systems due to the fact the updates are not presented 'en bloc' thus a QA person takes a considerable risk to the stability of their working systems when they run urpmi --auto-update as they may find that the next time they reboot they will have a non-functional GUI due to some missing dependency.
Until we have build lists in abf we must explore an alternative method of building so that we can at least ensure that those who are willing to do testing get a complete update. This problem coupled with the fact that there is no straightforward way of reversing a failed auto-update has discourages frpm testing. One of our team has said they will do no more untill a workable method of reversal is provided. Please remember that QA testers are what it says testers not coders and they need tools to help them do the job quickly and efficiently.
The suggestion that we do away with Kahinah is the first step on the road to ruin especially when KDE updates are in the pipeline. We need to have a constructive debate on a means of resolving these issues in the interim period until ABF and Kahinah can updated to work as required.
Lets have some ideas for resolving these issues in the interim for instance why don't we set up a separate repository for KDE. This would enable testers to enable or disable updates from it (the repository) dependent on it's status. The status with regard to Kahinah's voting system could be indicated by a dummy (or inconsequential) rpm which could serve as a voting indicator to those testing the KDE repo. It's appearance would indicate to testers that it is time to enable the repository and it's movement to the "passed" list in Kahinah would trigger the release of the KDE repository to the main repo the developer could do this manually or with some small changes to Kahinah it could probably be done automagically.
As for the reversal of testing updates; mechanisms exist in urpmi for doing this but what does not exist any more (at least from my brief exploration) is any are tha logs of what has been installed and from what repo it originated. I'm pretty sure I recall that urpmi used to log changes to the system in a seperate log restoring this whould allow the use of some basic shell scripts to allow dodgy updates to be reversed.
If these issues can be addressed even in the interim before any abf changes then Kahinah will useful once more and our testers will be able to work from a sound footing.
Best,
Colin
On Thursday, 8 December 2016 10:54:08 GMT Efrem Mc wrote:
> Hi all:
>
> I am not sure we want to put the "axe" to Kahinah before adding this
> functionality to ABF.
>
> I recall back in Nov 2014 everyone agreed to move to Kahinah for
> testing and voting. I guess the workflow is not working.
> We need to agree on the workflow and use it. Otherwise, explore what
> it takes to add "voting" if nothing else to ABF.
> I am not that close to the process and need to be, since I do some
> testing. We should publish a general workflow to follow.
>
> Regards,
>
> Efrem Mc
>
> Reference:
>
> Stated back on 11-13-14: (I just cut and paste.. no edits...)
>
> 3. Policies on stabilizing other branches than cooker -
>
> We recognize policy that is crutacl to OMV distribution consistencty between
> cooker and other branches - all kind imporvements(commits) related for other
> than cooker branches MUST not overrun cooker, unless exceptional cases that
> must be discussed on TC.
>
> Commiting FLOW: cooker (master branch) -> own testing -> backport to other
> branches -> QA testing (kahinah) -> publishing to repository
>
> On Thu, Dec 8, 2016 at 8:48 AM, Tomasz Gajc <tpgxyz at gmail.com> wrote:
> > I'd go further, and id' suggest to kill kahiniah, because we agreed long
> > time ago that ABF will be extended with voting functionality.
> > So when kahinah is alive then ABF will never reach new functionalities.
> >
> > 2016-12-08 7:56 GMT+01:00 Crispin Boylan <cris at beebgames.com>:
> >>
> >> Hi all
> >>
> >> As no-one is really voting on updates for 3.0 it seems to have left
> >> kahinah in a bit of a state.
> >>
> >>
> >> There are loads of updates which have either been published or rejected in
> >> abf but are languishing on kahinah making it difficult to see what really
> >> needs to be tested. Some (hopefully!) minor enhancements to kahinah could
> >> really help this situation:
> >>
> >> * Allow the maintainer of an update to reject it entirely, this would
> >> elimate dud/superseded updates where the only thing the maintainer can do is
> >> downvote it.
> >>
> >> * Update the kahinah list with the actual state of the package (ie instead
> >> of only looking at Complete or Testing Published, if the update is
> >> 'Published' then move it to published in kahinah, likewise if it is
> >> 'Rejected' on ABF then reject it in kahinah.
> >>
> >>
> >> is any of this achievable relatively quickly?
> >>
> >>
> >> thanks
> >>
> >> cris.
> >>
> >>
> >>
> >> _______________________________________________
> >> OM-Cooker mailing list
> >> OM-Cooker at ml.openmandriva.org
> >> http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml.openmandriva.org
> >
> >
> >
> > _______________________________________________
> > OM-QA mailing list
> > OM-QA at ml.openmandriva.org
> > http://ml.openmandriva.org/mailman/listinfo/om-qa_ml.openmandriva.org
> >
>
> _______________________________________________
> OM-Cooker mailing list
> OM-Cooker at ml.openmandriva.org
> http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml.openmandriva.org
>
More information about the OM-Cooker
mailing list