[gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Anant Narayanan wrote: P.P.S. Maybe this is more suited for -project, but everyone knows that nobody reads that list :-p Only because nobody posts there. Knock it off. ;P -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Markus Ullmann wrote: we had that in the past already yet it didn't solve one problem at hand: users getting distacted and devs getting nervous b/c the process is a) undocumented and b) a bit complex as you have to keep $repo and gentoo-x86 in sync So giving both (devs and users) an automated way of working with that would help a lot IMHO. like the user submits using echangelog "My cool change" repoman submit then the dev gets a diff or whatever against current state and then just does repoman accept or repoman reject Markus, you're talking about git. note: just brainstorm idea but we definitely could use some scripts for this kind of work. Greetz -Jokey -- Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / SPARC / KDE -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Markus Ullmann kirjoitti: So giving both (devs and users) an automated way of working with that would help a lot IMHO. like the user submits using echangelog "My cool change" repoman submit then the dev gets a diff or whatever against current state and then just does repoman accept or repoman reject note: just brainstorm idea but we definitely could use some scripts for this kind of work. There was a GSoC project/idea last year for this but I don't know if anything came of it. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Zhang Le schrieb: IMO giving proxy-maintainer due credit and publicity, meaning make it a formal position, could solve the very problem Anant's proposal intended to solve. we had that in the past already yet it didn't solve one problem at hand: users getting distacted and devs getting nervous b/c the process is a) undocumented and b) a bit complex as you have to keep $repo and gentoo-x86 in sync So giving both (devs and users) an automated way of working with that would help a lot IMHO. like the user submits using echangelog "My cool change" repoman submit then the dev gets a diff or whatever against current state and then just does repoman accept or repoman reject note: just brainstorm idea but we definitely could use some scripts for this kind of work. Greetz -Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Sunday, 2. March 2008, Richard Freeman Ви написали: > George Shapovalov wrote: > > The good thing about this approach is that it only requires an initial > > investment of organizing and automating things but does not add any > > regular work to the devs. In fact, if the "tested" category becomes > > popular enough, it can cut the work for stable testers, may be even by > > something like a factor of 10 eventually (due to less requests for > > explicit stabilizaion being issued).. > > We might also aim to make it easy for users to mix-and-match levels of > stability by package. I know it is possible already, but perhaps it > could be improved, or pre-canned lists of packages that users might > typically want bleeding-edge vs stable could be compiled. Well, we already have "system set" and it is defined in profile. With users being able to define and use their own profiles all that is left to do is to add an ability by portage to use different stability settings for system and out-of-system packages, as the most trivial approach. Of course more complex combinations are possible, but would require a proper discussion. > I think there are a large number of users who wouldn't mind less > stability on packages that won't prevent booting or network-access or > general use of their system. If some nice-to-have utility breaks I > don't mind reverting it, but if baselayout goes haywire I could spend > hours just getting my system to boot. Exactly. I did not mention this in order not to overcomplicate my previous message, but this is one of the things I had in ming for a long time. Besides > I like your idea though. Thanks! Although it is somewhat strange to hear "idea" when it has been an "old news" :) (at least for me), just check the timing of that bug I mentioned above. I merely adapted one of the not-yet-implemented issues discussed there to the present situation. Oh, btw, these two issues (extra stability levels and separate stability rankings for groups of packages) are independant enough to make it possible to implement them separately. George -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Hi, "Santiago M. Mola" <[EMAIL PROTECTED]>: > On Sat, Mar 1, 2008 at 7:45 PM, Christian Faulhammer > <[EMAIL PROTECTED]> wrote: > > > > What we propose is proper testing and keywording by anyone > > around...not just team members. > > Writing test plans like emacs team does really helps too. I waste too > much time figuring out how to test properly some packages, and I'm > sure me and other ATs miss a lot of important use cases. Maybe this could be centralised? User interaction is really simple here, so this could be wikified. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Richard Freeman wrote: We might also aim to make it easy for users to mix-and-match levels of stability by package. I know it is possible already, but perhaps it could be improved, or pre-canned lists of packages that users might typically want bleeding-edge vs stable could be compiled. Tusnam said it better than I would, so I'll just post a link -- http://tsunam.org/2008/01/29/arch/ Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
George Shapovalov wrote: > The good thing about this approach is that it only requires an initial > investment of organizing and automating things but does not add any regular > work to the devs. In fact, if the "tested" category becomes popular enough, > it can cut the work for stable testers, may be even by something like a > factor of 10 eventually (due to less requests for explicit stabilizaion being > issued).. > We might also aim to make it easy for users to mix-and-match levels of stability by package. I know it is possible already, but perhaps it could be improved, or pre-canned lists of packages that users might typically want bleeding-edge vs stable could be compiled. I think there are a large number of users who wouldn't mind less stability on packages that won't prevent booting or network-access or general use of their system. If some nice-to-have utility breaks I don't mind reverting it, but if baselayout goes haywire I could spend hours just getting my system to boot. I like your idea though. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
On Sat, Mar 1, 2008 at 7:45 PM, Christian Faulhammer <[EMAIL PROTECTED]> wrote: > > What we propose is proper testing and keywording by anyone > around...not just team members. > Writing test plans like emacs team does really helps too. I waste too much time figuring out how to test properly some packages, and I'm sure me and other ATs miss a lot of important use cases. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Sunday, 2. March 2008, Steve Dibb Ви написали: > Christian Faulhammer wrote: > > What we propose is proper testing and keywording by anyone > > around...not just team members. > > I agree... our main problem is manpower -- people actually working on > the stable bugs. I've tried to do it myself a few times, but each time > it just burns me out to the point where I don't want to (and won't) work > on anything Gentoo-related for a time. So, may be we should expand the number of "stability classes"? (something akin to my origina proposal, parst of which has been implemented, but looks like there is yet another usefull issue or two that did not make it yet :) (bug #1523, though probably not worth studying a this point as it mostly contains old stuff by now)). Right now with packages being only "in testing" and "stable" we basically cover the audiences with stances "original dev says it works - it's fine for me" and "I want it rigorously tested". There should be plenty of people, who would be happy with an intermediate level of control. May be we should add an intermediate category with a somewhat automated workflow? So that the evolution of packages in the tree would follow such pattern (plus, of course, there are overlays for even less stable stuff): 1. as the package gets released it goes into the "testing", as it does now 2. After say 2-4 wekks (take your pick) without issues and possibly going trhough some compile-farm (automatically scheduled at the end of this period if no open bugs (normal or more severe) are detected) the package is marked as belonging to the "tested" category. This is where many users would set their running stability level and, in a way, participate in testing things for the next level. If, any time after entering the "tested" state, package gets a bug assigned against it (again, normal or more severe) we start a countdown of, perhaps a few days, to let developers take care of the bug and if it does not get resolved within this time frame the package goes back to "testing". The decision to mask it or pull it off the tree completely remains with the respective devs, as it is now. Some packages can be marked as "critical" to make them go back to "testing" immediately upon getting an open bug, should such effect be desired (might be usefull for some security-sensitive system packages, or may be not, due to possible breakage this may introduce. Still we are having such downgrade situations already from time to time). 3. "completely stable" profile, to which packages only go when explicitly requested and processed by stabilization team, as they are now. We should probably impose the requirement, that stabilization can only be requested for packages in the "tested" category. The good thing about this approach is that it only requires an initial investment of organizing and automating things but does not add any regular work to the devs. In fact, if the "tested" category becomes popular enough, it can cut the work for stable testers, may be even by something like a factor of 10 eventually (due to less requests for explicit stabilizaion being issued).. George -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Christian Faulhammer wrote: What we propose is proper testing and keywording by anyone around...not just team members. I agree... our main problem is manpower -- people actually working on the stable bugs. I've tried to do it myself a few times, but each time it just burns me out to the point where I don't want to (and won't) work on anything Gentoo-related for a time. I've mostly resigned myself to working on just security bugs, but even those are so common that we need people looking at them all the time as well. Anyway, I'm all for a policy of if you have an amd64 box, and you're on a team / herd that wants to move forward with stable plans, just consult the amd64 team and then go ahead with it. Anything to spread the workload so that people don't get fed up with the bottlenecks. Steve -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Christian Faulhammer wrote: > > What we propose is proper testing and keywording by anyone > around...not just team members. > Thanks for the info - inactive maintainers are obviously a problem. Maybe the proper approach is for a more "Free-for-all" system like you suggest, with arch teams focusing on more arch-specific aspects of gentoo (such as the 32-bit libs for amd64, etc), and with arch teams having a QA oversight role for their arch. Perhaps arch teams should publish clear (and reasonably simple) policies they would like to see followed with their archs, and then devs could feel free to follow them on their own initiative. Accountability would obviously matter, but we don't want to chop off hands for first offenses, either. The Gentoo dev community is fairly closed - it isn't like just anybody can go keywording packages left and right. However, we do need to make sure that QA is followed. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Hi, Richard Freeman <[EMAIL PROTECTED]>: > > Hope you're not referring to any of my arches because that's not > > true :) In fact, if i did that, i wouldn't crash the alpha dev box > > so often, right Tobias? > I dunno - I just hit bug 211021 today while trying to clean out old > bugs. Already stable on one arch and not a word from the maintainer. As I was the one ccing arches, I should explain here...humpback has not reacted on tor bugs for a long time, not even security ones. So I did bumps and minor fixes for some time now, including stabilisation requests. My only failure here was, that I did not add myself to metadata.xml. My policy is to ask for stabilisation --> no reaction for one week (if it is urgent), I call arches. > While amd64 is a lot more mainstream than it used to be you can't just > assume that upstream wouldn't have released something if it didn't > work perfectly on amd64. Here you are right, and I must admit I sometimes only compile-test. I test everything I can, for special hardware I ask around in the team, but if there is no one I have no other choice. > No disputing that there is a problem - we just want to be careful that > the solution isn't worse than the problem... What we propose is proper testing and keywording by anyone around...not just team members. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Christian Faulhammer wrote: [snip] I agree 100%, thanks for explaining it better than me :P -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Hi, Richard Freeman <[EMAIL PROTECTED]>: > Raúl Porcel wrote: > > > > So it would be cool if they accepted help from other devs who don't > > have an amd64 system but have access to one and can test stuff. Cla > > is willing to help. [...] > I don't keyword a package stable unless I've done at least a moderate > amount of testing on the package to ensure that it works. If a > package looks simple but obscure I might go ahead and install it and > play with it, but I'd probably never keyword an emacs package stable, > since I don't ever use emacs and I won't pretend that all there is to > it is installing it and typing "hello world" and figuring out how to > quit. Hah, got you. Emacs team has a collection of test plans, that are understandable and have a step-by-step guide to the package. You may not have noticed because at the moment, Emacs teams handles nearly all stabilisation requests itself on amd64. Yes, testing is crucial, but it eases your pain if you have an arch tester going over it beforehand and amd64 is well equipped with that. > If there are folks out there who can test on amd64 systems then I'm > sure that the amd64 team would look forward to their help (just > contact kingtaco about it) - either by arch testing or perhaps by > just keywording as appropriate. However, we do need to be careful > about just going on a hunt to close bugs - "if it builds then it's > stable" isn't really a policy I think we want to follow. As an amd64 > user as well as a dev I know that I'd rather be a little further > behind on package foo (with the ability to accept ~amd64 on it if I > wanted to) than to have packages breaking every other week because > somebody keyworded them just because it compiled and didn't have any > glaring faults. There are dozens of bugs out there for amd64, that are no stabilisation requests but contain a patch or simple requests that could be handled in a fast wayproblem is, nobody does. Don't get Raul or myself wrong, we are not here to accuse someone or do a mud fight. We care and are worried about the state of amd64, but do not want to lower the work invested by some members of the team, so don't take anything personal or try to justify by all means. As a matter of fact amd64 has some broken packages in the stable tree where bugs exist and noone seems to care. > I think we also need better coordination across gentoo regarding when > packages should be stabilized. I've seen amd64 CC'ed on stablereq > bugs filed by end users, and arch teams keywording them left and > right, and there is no sign that the package maintainer wants the > package stabilized. I know that I'd be annoyed if arch teams > stabilized a package that I maintained and I didn't intend for it to > become stable for whatever reason. At the very least maintainers > should be contacted before packages go stable - and they should > probably document their intent in STABLEREQ bugs before everybody > goes crazy closing them out. This happens seldomly...and normally stabilisations are assigned to the maintainer which should react and cc arches. Only maintainer-wanted is directly cced with arches by bug wranglers. So such problems occur if developers/trusted users create the stabilisation bug. > I think that if we have the right policies then we'll be where we > want to be. Personally, it doesn't concern me a great deal that > there are tons of bugs open on an arch in and of itself (although > blockers and security bugs are a different matter). I'd rather that > then keyword something stable anytime one person (usually not the > maintainer) asks us to. And users who feel like they're being held > up should feel free to ping a dev to talk about it - and comments by > users and maintainers in bugs indicating how stable a package really > is make people like me more warm and fuzzy about keywording it > without as much personal testing. Again, this is not a question of not testing but a question of getting more work done (by more people). Sometimes I do amd64 bugs although I am not on the team, my only test system is a remote machine with hardened kernel (miranda), but I do test the packages I mark stable. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
