Re: [gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages
2011/9/20 Tomáš Chvátal : > The issue here is that if some part of the tree looses lots of its > maintainers we as devs usually manage to shape it up enough for us in > testing but nobody ever bothers to wait that 30 days and open > stablereq. An issue your suggestion doesn't address is when packages don't even stick around 30 days/etc. I know I've seen many packages where there is an ancient stable version that is never touched, and a much newer ~arch version that gets tweaked every 3-6 weeks. When it gets tweaked, often the old version is just removed immediately, or shortly after it is bumped. So, packages often don't stick around the 30 days it takes to stabilize them. Granted, this is a bit anecdotal so I can't speak for how big a problem this is in reality. However, for any stabilization scheme to work packages have to be, well, stable. :) Rich
Re: [gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages
On 09/20/11 23:18, Tomáš Chvátal wrote: [snipped to bits] > So, the issue is obvious, we have packages in testing that are in > better shape than stable ones. I'm aware that some of my packages could use a stablereq, but since I don't run any stable machines at the moment it just never bothers me. > Well it would be something like priority based queue with maximum 60 > points value. > > So do you thing it is possible to write such web app/ do you know if > anyone would be able to write so? If no I think I have proposal for > next GSoC as mentor :P but I would really like to see it sooner. Sounds like something that can be done, is not too complex ... Maybe we should agree on some standards for such webapps so that they are easy to support - what languages / toolkits / frameworks does infra support / tolerate ? - what data exchange formats can we define? There's things like packages.g.o that already do parts of it, there's euscan and other tools. Can we maybe unify that a bit? - how do we coordinate people that want to help out? For now I'll not be the one trying to carry such things forward, there's enough other distractions for me at the moment. But I see what can be done and think "that'd be, like, awesome" :) Patrick
Re: [gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages
2011/9/20 Tony "Chainsaw" Vroon : > On Tue, 2011-09-20 at 23:18 +0200, Tomáš Chvátal wrote: >> Well it would be something like priority based queue with maximum 60 >> points value. >> Each update after the month in main tree would get 0 points for >> stabilisation, any-developer / maintainer would be able to add up to >> 40 points to any package and security team members would be able to >> add all 60 points. Security team/any developer would also have >> possibility to add new packages to queue manualy. > > This sounds to me like you are trying to automate common sense. If you > see packages that have good ~arch ebuilds that appear to be fermenting, > please file a bug. Rumours of unresponsive arch teams have been greatly > exaggerated! > > The worst that could happen is that a more exotic arch sees your bug and > decides "sorry, we would rather unkeyword it" rather than "okay, we will > stable that". Either way seems a valid outcome though? > > I can't speak for other arches than AMD64, but we are happy to receive > more than the current influx of bugs, particularly if you are willing to > take suggestions to heart (a lot of QA niggles get shaken out in AT > reports lately). > > Regards, > Tony V. > I am not saying that Archs are unresponsive (well they are on ppc for example sometimes) but I try to solve other problem about finding what packages CAN go stable and nobody ever bothered to do a bugreport. Yeah we can do it by hand like robot and open bugs for zilions of packages just to get all the spell packages stable etc etc, but look on the euscan, it is quite usefull to have automatically generated report of what can you bump and what did you miss to update. Instead of waiting on maintainer/anyone to notice that you can stable something this would give you nice report itself. And usually when i update and qa clean some package in 30 days I don't even really remember which one it was :) Tom
Re: [gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages
On Tue, 2011-09-20 at 23:18 +0200, Tomáš Chvátal wrote: > Well it would be something like priority based queue with maximum 60 > points value. > Each update after the month in main tree would get 0 points for > stabilisation, any-developer / maintainer would be able to add up to > 40 points to any package and security team members would be able to > add all 60 points. Security team/any developer would also have > possibility to add new packages to queue manualy. This sounds to me like you are trying to automate common sense. If you see packages that have good ~arch ebuilds that appear to be fermenting, please file a bug. Rumours of unresponsive arch teams have been greatly exaggerated! The worst that could happen is that a more exotic arch sees your bug and decides "sorry, we would rather unkeyword it" rather than "okay, we will stable that". Either way seems a valid outcome though? I can't speak for other arches than AMD64, but we are happy to receive more than the current influx of bugs, particularly if you are willing to take suggestions to heart (a lot of QA niggles get shaken out in AT reports lately). Regards, Tony V. signature.asc Description: This is a digitally signed message part
[gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages
Hi guys, as I am now messing around libreo I am meeting a lot packages that none bothered to stablereq since 2009 or so, the versions in ~ are cleaner, more up to date, and possibly contain less bugs. The issue here is that if some part of the tree looses lots of its maintainers we as devs usually manage to shape it up enough for us in testing but nobody ever bothers to wait that 30 days and open stablereq. So, the issue is obvious, we have packages in testing that are in better shape than stable ones. Testing requests for bumps are now handled by euscan +-, cool job for that website by Iksaf, and I thing we need something similary scanning the main tree for stables and instead of bugreports the arch teams would have queue. How would such thing work? Well it would be something like priority based queue with maximum 60 points value. Each update after the month in main tree would get 0 points for stabilisation, any-developer / maintainer would be able to add up to 40 points to any package and security team members would be able to add all 60 points. Security team/any developer would also have possibility to add new packages to queue manualy. Each user could vote for any package giving out 1 point up to 10 points (eg max voteup for 10 concurent packages). For each folowing month the package would gain another 10 points, unless disqualified by qa/maintainer where it has to be off the queue for 1 month (or disqualified indefinetly based on some version range, eg beta series is 2.5 so we don't want to stable). Then arch team would just go and stabilise based up on the queue where each AT or arch dev could mark it as working. If there are 3 acks from Arch testers then even maintainer can proceed with the addition of the keyword not having to wait for arch dev to test the package, reducing the workload on arch devs (hopefully). The key problem for whole app is that you need to make sure the queue is a) properly sorted b) each request has proper depgraph so things does not break for AT/devs. This could be achieved by running the script and solving the depgraph prior creating the request. Example: We have stable possibility for harfbuzz and libreoffice, libreoffice depends on harfbuzz. The application would open just one stablerequest for libreoffice where it would put everything pulled in by its depgraph including harfbuzz and no separate request for harfbuzz is opened. If harfbuzz would not be ready yet for stabilisation then the libreoffice would not be YET added to the queue untill the harfbuzz passes the 30 days too. Here the queue of course have to differ for other arches as sparc have keyword for harfbuzz but not libreoffice. So do you thing it is possible to write such web app/ do you know if anyone would be able to write so? If no I think I have proposal for next GSoC as mentor :P but I would really like to see it sooner. Cheers Tom PS: no i can't write it, I seriously lack a time for such thing so I am just trying to find out if anyone is interested to work on it or if you even thing this is a good idea.
