Re: Automating the NonResponsiveMaintainers policy
On Fri, 02 Mar 2012 12:09:21 +0100 Reindl Harald h.rei...@thelounge.net wrote: if you are working the whole month on a different component and give no single feedback to a new reported bug you are ending in frustrated submitters - if they get a assigned they do not feel ignored This is going to end in counter-automation, with a script that uploads I'm busy, this bug is not to be used as an excuse to initiate punitive automation comment every 6 days. -- Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Am 02.03.2012 17:55, schrieb Rahul Sundaram: On 03/02/2012 10:15 PM, Reindl Harald wrote: * writing the systemd-unit takes 2 minutes for postfix * no need for package anything, install put it locally in /etc/systemd/system * so testing takes another 3 minutes, no compile needed This timeline is not reasonable. It typically takes half an hour to an hour to write and test it properly if you are not already familiar with systemd. for a simple service like postfix or dbmail? surely not! For most packages, I would consider this a low priority item because systemd has compatibility built-in. i was there and saw enough things breaking Remember that many maintainers deal with more than one package remember that i converted enough services after F15 hit me the first time and that i am maintaining nearly all server-packages as fork in a own repo becuase the half is unuseable for me with missing systemd-unit at least for mysqld and the other half is unuseable because the feodra packages are restarting services on each yum update instead let the admin control this and several of them have other projects including upstream development to take care of. If you think you are more efficient at it, you are welcome to sign up as package maintainer and demonstrate that. Talk is cheap. i even sent a bunlde of systemd-units to the devel-list * i sent a full migration-guide dbmail2-dbmail3 to the devel-list * also including the systed-units * i made a bugreport that 3.0 is final with the reference i spent WEEKS with the upstream-developer to get dbmail3 stable many threads on the mailing-list, most communication and debugging off-list, provide a build/test-service upstream, even initiated that my company spent money upstream to support the development and the fedora-maintainer does NOT act in any single way http://old.nabble.com/dbmail-users-f17485.html look for my name there, and this are only 10% of the communication over a full month, 7 days a week ___ the result is still a RC3 with sysv-init this is the best example for really bad maintainance first because a simple test proves that the RC3 never should been included in a GA-release and finally because this mistake is not fixed - so not talking is cheap * http://old.nabble.com/dbmail-users-f17485.html * http://koji.fedoraproject.org/koji/packageinfo?packageID=1572 * https://bugzilla.redhat.com/show_bug.cgi?id=797118 ___ normally my job is web-developer. below a list of packages forked/rebuilt and converted to systemd, so please do not tell me about talk is cheap while i am doing all the work missed in F15 besides my normal job a52dec-0.7.4-15.fc15.20111201.rh.x86_64.rpm a52dec-devel-0.7.4-15.fc15.20111201.rh.x86_64.rpm aespipe-2.4c-2.fc15.20111201.rh.x86_64.rpm apr-1.4.5-1.fc15.20111201.rh.x86_64.rpm apr-devel-1.4.5-1.fc15.20111201.rh.x86_64.rpm avidemux-2.5.5-6.fc15.20111206.rh.1.x86_64.rpm avidemux-cli-2.5.5-6.fc15.20111206.rh.1.x86_64.rpm avidemux-gtk-2.5.5-6.fc15.20111206.rh.1.x86_64.rpm avidemux-libs-2.5.5-6.fc15.20111206.rh.1.x86_64.rpm avidemux-qt-2.5.5-6.fc15.20111206.rh.1.x86_64.rpm cmirror-2.02.84-4.fc15.20111201.rh.x86_64.rpm crypto-utils-2.4.1-31.x86_64.rpm cups-1.5.0-11.fc15.20120205.rh.x86_64.rpm cups-devel-1.5.0-11.fc15.20120205.rh.x86_64.rpm cups-ipptool-1.5.0-11.fc15.20120205.rh.x86_64.rpm cups-libs-1.5.0-11.fc15.20120205.rh.x86_64.rpm cups-lpd-1.5.0-11.fc15.20120205.rh.x86_64.rpm cups-php-1.5.0-11.fc15.20120205.rh.x86_64.rpm dbmail-3.0.1-22.fc15.20120301.rh.a6e9ce2795eab12e56592802772a17ab03111829.x86_64.rpm dbmail-3.0.1-23.fc15.20120302.rh.62c20e2b2c15909941916bfe3c71386b31acc82a.x86_64.rpm dbmail-3.0.1-23.fc15.20120302.rh.83199b3f9da0aa430bf9f99d38f8bbdc3f60e348.x86_64.rpm dbmail-3.0.1-24.fc15.20120302.rh.62c20e2b2c15909941916bfe3c71386b31acc82a.x86_64.rpm dbmail-auth-ldap-3.0.1-22.fc15.20120301.rh.a6e9ce2795eab12e56592802772a17ab03111829.x86_64.rpm dbmail-auth-ldap-3.0.1-23.fc15.20120302.rh.62c20e2b2c15909941916bfe3c71386b31acc82a.x86_64.rpm dbmail-auth-ldap-3.0.1-23.fc15.20120302.rh.83199b3f9da0aa430bf9f99d38f8bbdc3f60e348.x86_64.rpm dbmail-auth-ldap-3.0.1-24.fc15.20120302.rh.62c20e2b2c15909941916bfe3c71386b31acc82a.x86_64.rpm dbmail-postfix-policyd-2011.05.25-7.fc15.20111201.rh.noarch.rpm device-mapper-1.02.63-4.fc15.20111201.rh.x86_64.rpm device-mapper-devel-1.02.63-4.fc15.20111201.rh.x86_64.rpm device-mapper-event-1.02.63-4.fc15.20111201.rh.x86_64.rpm device-mapper-event-devel-1.02.63-4.fc15.20111201.rh.x86_64.rpm device-mapper-event-libs-1.02.63-4.fc15.20111201.rh.x86_64.rpm device-mapper-libs-1.02.63-4.fc15.20111201.rh.x86_64.rpm dimp-1.1.8-2.fc15.20120210.rh.noarch.rpm dirb-2.0.3-1.fc15.20111218.rh.x86_64.rpm dovecot-2.1.1-2.fc15.20120224.rh.x86_64.rpm dovecot-devel-2.1.1-2.fc15.20120224.rh.x86_64.rpm dovecot-mysql-2.1.1-2.fc15.20120224.rh.x86_64.rpm dovecot-pgsql-2.1.1-2.fc15.20120224.rh.x86_64.rpm
Automating the NonResponsiveMaintainers policy
I am a feature owner for a feature that involves components in the hundreds and is heavily depended on maintainers responsiveness. For me to start enacting the non responsive maintainers policy is a tremendous work thus I'm wondering if there is something preventing us from automating the non responsive maintainer policy? An bugzilla script that acts something like if maintainer has not responded to a bug report with the status new in a week ( or some other time ) the non responsive maintainers policy automatically starts taking effect. To get out of that automatic non responsive process the maintainer would have to comment on the bug and set it's status assigned ( or something similar ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 11:20 AM, Jóhann B. Guðmundsson wrote: I am a feature owner for a feature that involves components in the hundreds and is heavily depended on maintainers responsiveness. For me to start enacting the non responsive maintainers policy is a tremendous work thus I'm wondering if there is something preventing us from automating the non responsive maintainer policy? An bugzilla script that acts something like if maintainer has not responded to a bug report with the status new in a week ( or some other time ) the non responsive maintainers policy automatically starts taking effect. Ok, so you'll automatically start non-responsive maintainer process, because maintainer didn't work on a one bug. But he might be working on different component for whole month. He might be working on a new upstream release and not paying attention to low priority bugzillas. You should take more parameters than one bug to kick someone from Fedora. Marcela To get out of that automatic non responsive process the maintainer would have to comment on the bug and set it's status assigned ( or something similar ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 11:02 AM, Marcela Mašláňová wrote: Ok, so you'll automatically start non-responsive maintainer process, because maintainer didn't work on a one bug. But he might be working on different component for whole month. He might be working on a new upstream release and not paying attention to low priority bugzillas. You should take more parameters than one bug to kick someone from Fedora. This is based on more then one bug against one component and through observation in several release cycles. If an maintainer does not want to be affected by the automatic non responsive process all he would have to do would simply be something like changing the report status from new to assigned and leave feed back on it. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Dne 2.3.2012 12:02, Marcela Mašláňová napsal(a): On 03/02/2012 11:20 AM, Jóhann B. Guðmundsson wrote: I am a feature owner for a feature that involves components in the hundreds and is heavily depended on maintainers responsiveness. For me to start enacting the non responsive maintainers policy is a tremendous work thus I'm wondering if there is something preventing us from automating the non responsive maintainer policy? An bugzilla script that acts something like if maintainer has not responded to a bug report with the status new in a week ( or some other time ) the non responsive maintainers policy automatically starts taking effect. Ok, so you'll automatically start non-responsive maintainer process, because maintainer didn't work on a one bug. But he might be working on different component for whole month. He might be working on a new upstream release and not paying attention to low priority bugzillas. You should take more parameters than one bug to kick someone from Fedora. Marcela Actually I support such initiative. We have also filled a few bugs against Ruby components which needs some love due to Ruby update and it happens that we have no response. If there would be tool that reports yes, the maintainer was active in some Fedora project 3 days ago, then it would be meaningful to nag him again, because the BZ was probably somewhere lost/forgotten, but if you see that the maintainer have been non-active for last 6 months, you know that you should probably start NonResponsiveMaintainer process. Vit To get out of that automatic non responsive process the maintainer would have to comment on the bug and set it's status assigned ( or something similar ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 12:20:10 PM Subject: Automating the NonResponsiveMaintainers policy I am a feature owner for a feature that involves components in the hundreds and is heavily depended on maintainers responsiveness. For me to start enacting the non responsive maintainers policy is a tremendous work thus I'm wondering if there is something preventing us from automating the non responsive maintainer policy? An bugzilla script that acts something like if maintainer has not responded to a bug report with the status new in a week ( or some other time ) the non responsive maintainers policy automatically starts taking effect. Well, this is plain nonsense. Do you know how many bug reports do a number of the packagers have ? And speaking for A WEEK is something that is even offensive. People tend to take 2 weeks of vacation still. So I would make a contra-proposal. If a maintainer doesn't respond to a bug repord with the status new in a week - give commit rights to the reporter in pkgdb so he/she can fix it himself. I really think this is way more fare and people that tend to think that packagers are just a bunch of lazy guys should step in do some of this dirty work to get an idea what we speak about. Alex To get out of that automatic non responsive process the maintainer would have to comment on the bug and set it's status assigned ( or something similar ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 12:12 PM, Jóhann B. Guðmundsson wrote: On 03/02/2012 11:02 AM, Marcela Mašláňová wrote: Ok, so you'll automatically start non-responsive maintainer process, because maintainer didn't work on a one bug. But he might be working on different component for whole month. He might be working on a new upstream release and not paying attention to low priority bugzillas. You should take more parameters than one bug to kick someone from Fedora. This is based on more then one bug against one component and through observation in several release cycles. If an maintainer does not want to be affected by the automatic non responsive process all he would have to do would simply be something like changing the report status from new to assigned and leave feed back on it. JBG You didn't consider people or pseudousers, who are assigned to packages with dozens of bugs. Also some developers are using NEW as their state for something. I'm afraid we end up with more bureaucracy than we have now. I'm not against tracking some statistics, so you can look up who is active and probably will answer in few days, but I'd rather not use it for the unresponsive process. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 12:52 PM, Aleksandar Kurtakov wrote: - Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 12:20:10 PM Subject: Automating the NonResponsiveMaintainers policy I am a feature owner for a feature that involves components in the hundreds and is heavily depended on maintainers responsiveness. For me to start enacting the non responsive maintainers policy is a tremendous work thus I'm wondering if there is something preventing us from automating the non responsive maintainer policy? An bugzilla script that acts something like if maintainer has not responded to a bug report with the status new in a week ( or some other time ) the non responsive maintainers policy automatically starts taking effect. Well, this is plain nonsense. Do you know how many bug reports do a number of the packagers have ? And speaking for A WEEK is something that is even offensive. People tend to take 2 weeks of vacation still. So I would make a contra-proposal. If a maintainer doesn't respond to a bug repord with the status new in a week - give commit rights to the reporter in pkgdb so he/she can fix it himself. I really think this is way more fare and people that tend to think that packagers are just a bunch of lazy guys should step in do some of this dirty work to get an idea what we speak about. Alex I would change week to longer period, but it sound better than previous proposal. Marcela To get out of that automatic non responsive process the maintainer would have to comment on the bug and set it's status assigned ( or something similar ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 11:16 AM, Vít Ondruch wrote: Actually I support such initiative. We have also filled a few bugs against Ruby components which needs some love due to Ruby update and it happens that we have no response. If there would be tool that reports yes, the maintainer was active in some Fedora project 3 days ago, then it would be meaningful to nag him again, because the BZ was probably somewhere lost/forgotten, but if you see that the maintainer have been non-active for last 6 months, you know that you should probably start NonResponsiveMaintainer process. Yeah I suspected that I was not alone in this regard since I am just dealing with ca 5% of packages in the distribution. This could be beneficial in various project processes although I'm not familiar with how FPC ensures that FPG is being followed and is updated each time changes are made to the guidelines but let's assume they are using this workflow. FPC makes changes to FPG -- They then generate a list of packages affected by the change to FPG -- They then file a report against all the component on the list were they state that the relevant package is affected by the change made by FPG and the spec file should be updated accordingly and maintainers should comment if they would they require the assistant of proven packager do to those changes for them and those changes should preferable be completed by this $DATE -- A week ( or some other time ) later the component gets hit by the automatic non responsive policy which would allow proven packager only have to walk through components that have not been flagged non responsive and check if maintainers have asked for their assistant thus focusing their available time and energy only on responsive and actively maintainer. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Marcela Mašláňová mmasl...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 1:57:11 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 03/02/2012 12:52 PM, Aleksandar Kurtakov wrote: - Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 12:20:10 PM Subject: Automating the NonResponsiveMaintainers policy I am a feature owner for a feature that involves components in the hundreds and is heavily depended on maintainers responsiveness. For me to start enacting the non responsive maintainers policy is a tremendous work thus I'm wondering if there is something preventing us from automating the non responsive maintainer policy? An bugzilla script that acts something like if maintainer has not responded to a bug report with the status new in a week ( or some other time ) the non responsive maintainers policy automatically starts taking effect. Well, this is plain nonsense. Do you know how many bug reports do a number of the packagers have ? And speaking for A WEEK is something that is even offensive. People tend to take 2 weeks of vacation still. So I would make a contra-proposal. If a maintainer doesn't respond to a bug repord with the status new in a week - give commit rights to the reporter in pkgdb so he/she can fix it himself. I really think this is way more fare and people that tend to think that packagers are just a bunch of lazy guys should step in do some of this dirty work to get an idea what we speak about. Alex I would change week to longer period, but it sound better than previous proposal. I said a week to make it close enough to the original proposal and as I said requesting every packager to request in a week is something I even consider an insult. Alex Marcela To get out of that automatic non responsive process the maintainer would have to comment on the bug and set it's status assigned ( or something similar ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 02/03/12 12:52, Aleksandar Kurtakov wrote: If a maintainer doesn't respond to a bug repord with the status new in a week - give commit rights to the reporter in pkgdb so he/she can fix it himself. I kind a' like this proposal. You're speaking of current package maintainers getting commit rights automatically after a timespan, right? What about bug reporter being unable to fix the mentioned bug? And does the bug-reporter get his right revoked after a time (automatically?) -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Dne 2.3.2012 12:56, Jóhann B. Guðmundsson napsal(a): On 03/02/2012 11:16 AM, Vít Ondruch wrote: Actually I support such initiative. We have also filled a few bugs against Ruby components which needs some love due to Ruby update and it happens that we have no response. If there would be tool that reports yes, the maintainer was active in some Fedora project 3 days ago, then it would be meaningful to nag him again, because the BZ was probably somewhere lost/forgotten, but if you see that the maintainer have been non-active for last 6 months, you know that you should probably start NonResponsiveMaintainer process. Yeah I suspected that I was not alone in this regard since I am just dealing with ca 5% of packages in the distribution. This could be beneficial in various project processes although I'm not familiar with how FPC ensures that FPG is being followed and is updated each time changes are made to the guidelines but let's assume they are using this workflow. Are the changes enforced? I don't think so ... Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 02/03/12 12:53, Marcela Mašláňová wrote: I'm afraid we end up with more bureaucracy than we have now. I'm not against tracking some statistics, so you can look up who is active and probably will answer in few days, but I'd rather not use it for the unresponsive process. Marcela I'm thinking about how to support Jóhann with a proven packager (or two). Since it seems not wanted by Fesco, to give him the corresponding rights to commit his changes directly? This final target (all services are supported by systemd) seems to be clear to everyone. -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 01:00 PM, Matthias Runge wrote: On 02/03/12 12:52, Aleksandar Kurtakov wrote: If a maintainer doesn't respond to a bug repord with the status new in a week - give commit rights to the reporter in pkgdb so he/she can fix it himself. I kind a' like this proposal. You're speaking of current package maintainers getting commit rights automatically after a timespan, right? What about bug reporter being unable to fix the mentioned bug? And does the bug-reporter get his right revoked after a time (automatically?) Yes, I would be afraid that reporters won't be able to fix it properly. Even if I'm a provenpackager, I don't commit into packages not related to mine. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Dne 2.3.2012 12:52, Aleksandar Kurtakov napsal(a): - Original Message - From: Jóhann B. Guðmundssonjohan...@gmail.com To: Development discussions related to Fedoradevel@lists.fedoraproject.org Sent: Friday, March 2, 2012 12:20:10 PM Subject: Automating the NonResponsiveMaintainers policy I am a feature owner for a feature that involves components in the hundreds and is heavily depended on maintainers responsiveness. For me to start enacting the non responsive maintainers policy is a tremendous work thus I'm wondering if there is something preventing us from automating the non responsive maintainer policy? An bugzilla script that acts something like if maintainer has not responded to a bug report with the status new in a week ( or some other time ) the non responsive maintainers policy automatically starts taking effect. Well, this is plain nonsense. Do you know how many bug reports do a number of the packagers have ? And speaking for A WEEK is something that is even offensive. People tend to take 2 weeks of vacation still. So I would make a contra-proposal. If a maintainer doesn't respond to a bug repord with the status new in a week - give commit rights to the reporter in pkgdb so he/she can fix it himself. I really think this is way more fare and people that tend to think that packagers are just a bunch of lazy guys should step in do some of this dirty work to get an idea what we speak about. Alex But what if that is one bug who the maintainer don't want touch ATM although he fixes others? I have my own priorities and as long as there is no time for some bug, I'm not touching it at all. So one bug is not enough IMO. There should be some broader amount of activities taken in account. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Matthias Runge mru...@matthias-runge.de To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:00:32 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 02/03/12 12:52, Aleksandar Kurtakov wrote: If a maintainer doesn't respond to a bug repord with the status new in a week - give commit rights to the reporter in pkgdb so he/she can fix it himself. I kind a' like this proposal. You're speaking of current package maintainers getting commit rights automatically after a timespan, right? TBH, I was really shocked by the proposal and this was the first thing that came to my mind - let the reporters join instead of throwing out people. Yes, current package maintainers should get commit rights after a timespan. Probably there is no need to do it for sponsors and provenpackagers as they already can commit. What about bug reporter being unable to fix the mentioned bug? Well, this is what https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer is for, right? The reporter should find a sponsor to review his patch and sponsor him. If he is unable to fix the issue for another reason this is out of scope for this talk because throwing out the maintainer wouldn't help the reporter for sure. And does the bug-reporter get his right revoked after a time (automatically?) No need. Alex -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 11:47 AM, Marcela Mašláňová wrote: Some developers prefer ignore it until they have time. Why should I write yes, yes, it's broken, I'll look at it next month. That's not helping anyway. I disagree it certainly does matter. For example let's take these two [1] [2] bugs that are on my components list for my feature. Bug 1 was filed 2011-11-16 and has absolutely no comments. Which leaves me wondering.. A) is this package being actively maintained? B) Is it planned for removal? C) Is there something wrong with the submitted unit file? D) Are upstream changes necessary for this component to be migrated? E) Is it safe to flag the component to be package by proven packages? Now let's look at bug 2 was also filed 2011-11-16 and has one comment from the maintainer which came 3 days later. Thanks, I'll test and apply it. Hoping to actually fix the deamon too. Now I have the answer to A,B,C,D,E. For bug 1 I have to initiate non responsive maintainers policy which takes 3+ weeks to finish For bug 2 I can just ping him with status if he has not yet packaged the submitted unit no later than week before the deadline to ship units comes. So as you can see responses do indeed matter. JBG 1. https://bugzilla.redhat.com/show_bug.cgi?id=754358 2. https://bugzilla.redhat.com/show_bug.cgi?id=754388 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 02/03/12 13:10, Aleksandar Kurtakov wrote: What about bug reporter being unable to fix the mentioned bug? Oh no. I'm mean unable to fix because of missing knowledge, not unable because of missing commit rights. I might file a bug against kernel, but I'm definitely not the right person to patch there. (You might substitute kernel with everything you want, just to make the picture). I'm a bit puzzled by quick-and-dirty 'fixes' which may lead to errors somewhere else. -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 02:00 PM, Matthias Runge wrote: On 02/03/12 12:52, Aleksandar Kurtakov wrote: If a maintainer doesn't respond to a bug repord with the status new in a week - give commit rights to the reporter in pkgdb so he/she can fix it himself. I kind a' like this proposal. You're speaking of current package maintainers getting commit rights automatically after a timespan, right? What about bug reporter being unable to fix the mentioned bug? And does the bug-reporter get his right revoked after a time (automatically?) Not to mention bug reporter not necessarily understanding the full consequences of a change - change that might look trivial but has world-breaking effects. And FWIW, four week vacations are common in this part of the world... - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 11:52 AM, Aleksandar Kurtakov wrote: So I would make a contra-proposal. If a maintainer doesn't respond to a bug repord with the status new in a week - give commit rights to the reporter in pkgdb so he/she can fix it himself. I really think this is way more fare and people that tend to think that packagers are just a bunch of lazy guys should step in do some of this dirty work to get an idea what we speak about. There currently is no place in the project for people that want to fix things without having to maintain packages themselves so I think your counter proposal as good as it is can not come to pass until that has been fixed. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Matthias Runge mru...@matthias-runge.de To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:05:07 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 02/03/12 12:53, Marcela Mašláňová wrote: I'm afraid we end up with more bureaucracy than we have now. I'm not against tracking some statistics, so you can look up who is active and probably will answer in few days, but I'd rather not use it for the unresponsive process. Marcela I'm thinking about how to support Jóhann with a proven packager (or two). Since it seems not wanted by Fesco, to give him the corresponding rights to commit his changes directly? This final target (all services are supported by systemd) seems to be clear to everyone. This is a noble goal and I wish this finishes sooner. But attacking packagers by threatening is not gaining any support for the efforts. Most of us gained their commit rights by talking to the respective maintainers getting them approve us as comaintainers, it's a lengthy process I agree. But it's not that hard to ask for co-maintainership so one gets commit rights. I wonder whether someone refused to give commit rights for someone wanting to add systemd support in his package? People should finally understand that by threatening and over-bureaucracy nothing will improve. When someone wants to see a feature done he should get his hands dirty in all aspects - do the changes, find the maintainer, talk to them, get commit rights or get them to push changes, do builds if needed. We ship a distribution so if someone do something but doesn't integrate with the rest we have nothing. And integration is collaboration it's not something one can enforce with bureacracy. Alex Alex -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 01:13 PM, Jóhann B. Guðmundsson wrote: On 03/02/2012 11:47 AM, Marcela Mašláňová wrote: Some developers prefer ignore it until they have time. Why should I write yes, yes, it's broken, I'll look at it next month. That's not helping anyway. I disagree it certainly does matter. For example let's take these two [1] [2] bugs that are on my components list for my feature. Bug 1 was filed 2011-11-16 and has absolutely no comments. Which leaves me wondering.. A) is this package being actively maintained? B) Is it planned for removal? C) Is there something wrong with the submitted unit file? D) Are upstream changes necessary for this component to be migrated? E) Is it safe to flag the component to be package by proven packages? Now let's look at bug 2 was also filed 2011-11-16 and has one comment from the maintainer which came 3 days later. Thanks, I'll test and apply it. Hoping to actually fix the deamon too. Now I have the answer to A,B,C,D,E. For bug 1 I have to initiate non responsive maintainers policy which takes 3+ weeks to finish For bug 2 I can just ping him with status if he has not yet packaged the submitted unit no later than week before the deadline to ship units comes. So as you can see responses do indeed matter. JBG 1. https://bugzilla.redhat.com/show_bug.cgi?id=754358 2. https://bugzilla.redhat.com/show_bug.cgi?id=754388 Units again :) Are you trying create some metrics because of units on whole distribution? It simply won't fit to all groups. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Matthias Runge mru...@matthias-runge.de To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:15:51 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 02/03/12 13:10, Aleksandar Kurtakov wrote: What about bug reporter being unable to fix the mentioned bug? Oh no. I'm mean unable to fix because of missing knowledge, not unable because of missing commit rights. I might file a bug against kernel, but I'm definitely not the right person to patch there. (You might substitute kernel with everything you want, just to make the picture). I'm a bit puzzled by quick-and-dirty 'fixes' which may lead to errors somewhere else. Well, the whole idea came in a second so someone should refine it. FWIW the period should be long enough - in my eyes not less than a months so if noone responded in like 3 months the fix would no longer be at least quick. And as always we trust people to do the right and have a good understanding of their capabilities and knowledge. No proposal/technology can prevent bad intentions. Alex -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 12:21 PM, Marcela Mašláňová wrote: Units again:) Are you trying create some metrics because of units on whole distribution? It simply won't fit to all groups. No I'm only using units or rather the systemd migration process since i'm most familiar with it. ( been doing it for 3 release cycles now 4 if you count the initial systemd push which got rejected ). It also deals with 500 - 600 components in total which gives it quite a measurable range to span I would believe. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:16:28 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 03/02/2012 11:52 AM, Aleksandar Kurtakov wrote: So I would make a contra-proposal. If a maintainer doesn't respond to a bug repord with the status new in a week - give commit rights to the reporter in pkgdb so he/she can fix it himself. I really think this is way more fare and people that tend to think that packagers are just a bunch of lazy guys should step in do some of this dirty work to get an idea what we speak about. There currently is no place in the project for people that want to fix things without having to maintain packages themselves so I think your counter proposal as good as it is can not come to pass until that has been fixed. Well, Fedora ships packages. I might be stupid but would someone please explain me how can one deliver fixed/improved packages to users without do at least a bit of packaging work. I don't see a way this to happen. Alex JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 02/03/12 13:06, Marcela Mašláňová wrote: Yes, I would be afraid that reporters won't be able to fix it properly. Even if I'm a provenpackager, I don't commit into packages not related to mine. Yes, I guess, that's a more general problem. But since we have proven packagers, they might jump in in this limited case. -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Aleksandar Kurtakov akurt...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:27:04 PM Subject: Re: Automating the NonResponsiveMaintainers policy - Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:16:28 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 03/02/2012 11:52 AM, Aleksandar Kurtakov wrote: So I would make a contra-proposal. If a maintainer doesn't respond to a bug repord with the status new in a week - give commit rights to the reporter in pkgdb so he/she can fix it himself. I really think this is way more fare and people that tend to think that packagers are just a bunch of lazy guys should step in do some of this dirty work to get an idea what we speak about. There currently is no place in the project for people that want to fix things without having to maintain packages themselves so I think your counter proposal as good as it is can not come to pass until that has been fixed. Well, Fedora ships packages. I might be stupid but would someone please explain me how can one deliver fixed/improved packages to users without do at least a bit of packaging work. I don't see a way this to happen. I have to do some clarification to my previous post. If someone wants to get things improved but not touching packages he clearly wants to work on upstream projects in order to get the fixes there. And the next time the package is updated to latest version the fixes will be in Fedora. I think that this is the only way to improve Fedora by not touching packages. P.S. Note that I speak about development work and what I wrote has nothing to do with the work of Documentation/Translation teams which are doing great job. Alex Alex JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 02/03/12 13:24, Aleksandar Kurtakov wrote: Well, the whole idea came in a second so someone should refine it. FWIW the period should be long enough - in my eyes not less than a months so if noone responded in like 3 months the fix would no longer be at least quick. And as always we trust people to do the right and have a good understanding of their capabilities and knowledge. No proposal/technology can prevent bad intentions. Yes, I guess, many people have very different time frame in their heads. If we'd like to try this out, what would be the right way to propose this change? -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 12:27 PM, Aleksandar Kurtakov wrote: Well, Fedora ships packages. I might be stupid but would someone please explain me how can one deliver fixed/improved packages to users without do at least a bit of packaging work. I don't see a way this to happen. Spec files are no rocket science and the process for them is heavily backed up by FPG. One way to achieve that would be that one could do so by becoming proven packager through some kind of mentoring process ( which does not exist btw ) I would think. Atleast I would think you would have to first complete that step then proceed into being allowed to actually patch the actual source of the component. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Matthias Runge mru...@matthias-runge.de To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:34:11 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 02/03/12 13:24, Aleksandar Kurtakov wrote: Well, the whole idea came in a second so someone should refine it. FWIW the period should be long enough - in my eyes not less than a months so if noone responded in like 3 months the fix would no longer be at least quick. And as always we trust people to do the right and have a good understanding of their capabilities and knowledge. No proposal/technology can prevent bad intentions. Yes, I guess, many people have very different time frame in their heads. If we'd like to try this out, what would be the right way to propose this change? I really have no idea nor I would have the time to deal with such thing anytime soon as it will also require development work if accepted. The current process works fine for me. I just wanted to show that there are better way than throwing out people. Alex -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Dne 2.3.2012 13:19, Aleksandar Kurtakov napsal(a): - Original Message - From: Matthias Rungemru...@matthias-runge.de To: Development discussions related to Fedoradevel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:05:07 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 02/03/12 12:53, Marcela Mašláňová wrote: I'm afraid we end up with more bureaucracy than we have now. I'm not against tracking some statistics, so you can look up who is active and probably will answer in few days, but I'd rather not use it for the unresponsive process. Marcela I'm thinking about how to support Jóhann with a proven packager (or two). Since it seems not wanted by Fesco, to give him the corresponding rights to commit his changes directly? This final target (all services are supported by systemd) seems to be clear to everyone. This is a noble goal and I wish this finishes sooner. But attacking packagers by threatening is not gaining any support for the efforts. Most of us gained their commit rights by talking to the respective maintainers getting them approve us as comaintainers, it's a lengthy process I agree. But it's not that hard to ask for co-maintainership so one gets commit rights. I wonder whether someone refused to give commit rights for someone wanting to add systemd support in his package? People should finally understand that by threatening and over-bureaucracy nothing will improve. When someone wants to see a feature done he should get his hands dirty in all aspects - do the changes, find the maintainer, talk to them, get commit rights or get them to push changes, do builds if needed. We ship a distribution so if someone do something but doesn't integrate with the rest we have nothing. And integration is collaboration it's not something one can enforce with bureacracy. Alex, Don't be so touchy please. The truth is somewhere in between. There are maintainers who do not respond for whatever reason and there are others who are solving reported issue in a minute. I don't believe that it was meant to threaten anybody. You read the Automating the NonResponsiveMaintainers policy as remove the original maintainer or punish him but it might be very well read in opposite way, exactly as you proposed. There is no need for drama. Vit Alex Alex -- Matthias Rungemru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 12:03 PM, Vít Ondruch wrote: Are the changes enforced? I don't think so ... Interesting which begs the question to which purpose do the guideline serve if no one is actually making sure that it's being followed? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 02/03/12 13:16, Panu Matilainen wrote: Not to mention bug reporter not necessarily understanding the full consequences of a change - change that might look trivial but has world-breaking effects. And FWIW, four week vacations are common in this part of the world... - Panu - Absolutely. I think, this can not (easily) be automated. I would prefer to have a manual selection of packagers getting access, something like proven packagers. (I know, this leads to bureaucracy and should be avoided) Accidental mistakes can happen, at least proven packagers know, how to revert this. What about: getting more proven packagers? Make them more prominent, i.e. making it easier to contact them? -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:34:10 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 03/02/2012 12:27 PM, Aleksandar Kurtakov wrote: Well, Fedora ships packages. I might be stupid but would someone please explain me how can one deliver fixed/improved packages to users without do at least a bit of packaging work. I don't see a way this to happen. Spec files are no rocket science and the process for them is heavily backed up by FPG. Sure spec files are no rocket science, it's not the format and syntax but the content that matters. One way to achieve that would be that one could do so by becoming proven packager through some kind of mentoring process ( which does not exist btw ) I would think. Hmm, proven packagers are still packagers aren't they? I thought you were asking about someone fixing things without being packager. Atleast I would think you would have to first complete that step then proceed into being allowed to actually patch the actual source of the component. Nope, if you are a packager already and you have a unit file you want to push in my package just ask me about commit rights via pkgdb and a mail explaining it and I'll definetely approve your request and I'm pretty sure that a number of packagers will do that too. Alex JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 02/03/12 13:37, Aleksandar Kurtakov wrote: I really have no idea nor I would have the time to deal with such thing anytime soon as it will also require development work if accepted. The current process works fine for me. I just wanted to show that there are better way than throwing out people. Ok, agreed, My question was merely academic. Who to contact, if... I didn't ran into a limitation so far. Ok, once or twice. In total the system works well. Changing a large number of packages is surely a corner case. -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Vít Ondruch vondr...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:37:53 PM Subject: Re: Automating the NonResponsiveMaintainers policy Dne 2.3.2012 13:19, Aleksandar Kurtakov napsal(a): - Original Message - From: Matthias Rungemru...@matthias-runge.de To: Development discussions related to Fedoradevel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:05:07 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 02/03/12 12:53, Marcela Mašláňová wrote: I'm afraid we end up with more bureaucracy than we have now. I'm not against tracking some statistics, so you can look up who is active and probably will answer in few days, but I'd rather not use it for the unresponsive process. Marcela I'm thinking about how to support Jóhann with a proven packager (or two). Since it seems not wanted by Fesco, to give him the corresponding rights to commit his changes directly? This final target (all services are supported by systemd) seems to be clear to everyone. This is a noble goal and I wish this finishes sooner. But attacking packagers by threatening is not gaining any support for the efforts. Most of us gained their commit rights by talking to the respective maintainers getting them approve us as comaintainers, it's a lengthy process I agree. But it's not that hard to ask for co-maintainership so one gets commit rights. I wonder whether someone refused to give commit rights for someone wanting to add systemd support in his package? People should finally understand that by threatening and over-bureaucracy nothing will improve. When someone wants to see a feature done he should get his hands dirty in all aspects - do the changes, find the maintainer, talk to them, get commit rights or get them to push changes, do builds if needed. We ship a distribution so if someone do something but doesn't integrate with the rest we have nothing. And integration is collaboration it's not something one can enforce with bureacracy. Alex, Don't be so touchy please. The truth is somewhere in between. There are maintainers who do not respond for whatever reason and there are others who are solving reported issue in a minute. I don't believe that it was meant to threaten anybody. You read the Automating the NonResponsiveMaintainers policy as remove the original maintainer or punish him but it might be very well read in opposite way, exactly as you proposed. There is no need for drama. This is not the first discussion on the topic I'm involved into. There are such maintainers I agree. But what is the problem with the current NonResponsiveMaintainers policy? How would you automate this? And asking to do it in a week? Every packager deserves at least the few steps described into the current procedure. Alex Vit Alex Alex -- Matthias Rungemru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 12:37 PM, Vít Ondruch wrote: Don't be so touchy please. The truth is somewhere in between. There are maintainers who do not respond for whatever reason and there are others who are solving reported issue in a minute. I don't believe that it was meant to threaten anybody. You read the Automating the NonResponsiveMaintainers policy as remove the original maintainer or punish him but it might be very well read in opposite way, exactly as you proposed. There is no need for drama. This was meant to be read as Automating the NonResponsiveMaintainers policy not as an threat not as anykind of changes to the NonResponsiveMaintainers policy itself ( other than the process being automated as in the steps having to be performed by the reporter which he currently can do with any bug btw ) and the week period I put in there was because I currently had weekly run cron job in mind and the fact that the NonResponsiveMaintainers policy takes 3 weeks to complete from the reporters point of view with announcement to this list but that week could easily be turned into a month instead which would make it month +3weeks JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Dne 2.3.2012 13:47, Aleksandar Kurtakov napsal(a): - Original Message - From: Vít Ondruchvondr...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:37:53 PM Subject: Re: Automating the NonResponsiveMaintainers policy Dne 2.3.2012 13:19, Aleksandar Kurtakov napsal(a): - Original Message - From: Matthias Rungemru...@matthias-runge.de To: Development discussions related to Fedoradevel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:05:07 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 02/03/12 12:53, Marcela Mašláňová wrote: I'm afraid we end up with more bureaucracy than we have now. I'm not against tracking some statistics, so you can look up who is active and probably will answer in few days, but I'd rather not use it for the unresponsive process. Marcela I'm thinking about how to support Jóhann with a proven packager (or two). Since it seems not wanted by Fesco, to give him the corresponding rights to commit his changes directly? This final target (all services are supported by systemd) seems to be clear to everyone. This is a noble goal and I wish this finishes sooner. But attacking packagers by threatening is not gaining any support for the efforts. Most of us gained their commit rights by talking to the respective maintainers getting them approve us as comaintainers, it's a lengthy process I agree. But it's not that hard to ask for co-maintainership so one gets commit rights. I wonder whether someone refused to give commit rights for someone wanting to add systemd support in his package? People should finally understand that by threatening and over-bureaucracy nothing will improve. When someone wants to see a feature done he should get his hands dirty in all aspects - do the changes, find the maintainer, talk to them, get commit rights or get them to push changes, do builds if needed. We ship a distribution so if someone do something but doesn't integrate with the rest we have nothing. And integration is collaboration it's not something one can enforce with bureacracy. Alex, Don't be so touchy please. The truth is somewhere in between. There are maintainers who do not respond for whatever reason and there are others who are solving reported issue in a minute. I don't believe that it was meant to threaten anybody. You read the Automating the NonResponsiveMaintainers policy as remove the original maintainer or punish him but it might be very well read in opposite way, exactly as you proposed. There is no need for drama. This is not the first discussion on the topic I'm involved into. There are such maintainers I agree. But what is the problem with the current NonResponsiveMaintainers policy? How would you automate this? And asking to do it in a week? Every packager deserves at least the few steps described into the current procedure. The current procedure is a pain ... and it happens that after month of waiting, maintainer suddenly appear and (s)he is really angry how dare you can call me unresponsive when I am just busy with other projects/live. This is not good from opposite side. And that happened to me. So current procedure is at least pretty vague and there is no support in kind of some infrastructure. You have to check hmm, is it already week since I last pinged somebody on BZ or ML? Hm, not yet. Ok, I'll wait. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Vít Ondruch vondr...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:54:52 PM Subject: Re: Automating the NonResponsiveMaintainers policy Dne 2.3.2012 13:47, Aleksandar Kurtakov napsal(a): - Original Message - From: Vít Ondruchvondr...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:37:53 PM Subject: Re: Automating the NonResponsiveMaintainers policy Dne 2.3.2012 13:19, Aleksandar Kurtakov napsal(a): - Original Message - From: Matthias Rungemru...@matthias-runge.de To: Development discussions related to Fedoradevel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:05:07 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 02/03/12 12:53, Marcela Mašláňová wrote: I'm afraid we end up with more bureaucracy than we have now. I'm not against tracking some statistics, so you can look up who is active and probably will answer in few days, but I'd rather not use it for the unresponsive process. Marcela I'm thinking about how to support Jóhann with a proven packager (or two). Since it seems not wanted by Fesco, to give him the corresponding rights to commit his changes directly? This final target (all services are supported by systemd) seems to be clear to everyone. This is a noble goal and I wish this finishes sooner. But attacking packagers by threatening is not gaining any support for the efforts. Most of us gained their commit rights by talking to the respective maintainers getting them approve us as comaintainers, it's a lengthy process I agree. But it's not that hard to ask for co-maintainership so one gets commit rights. I wonder whether someone refused to give commit rights for someone wanting to add systemd support in his package? People should finally understand that by threatening and over-bureaucracy nothing will improve. When someone wants to see a feature done he should get his hands dirty in all aspects - do the changes, find the maintainer, talk to them, get commit rights or get them to push changes, do builds if needed. We ship a distribution so if someone do something but doesn't integrate with the rest we have nothing. And integration is collaboration it's not something one can enforce with bureacracy. Alex, Don't be so touchy please. The truth is somewhere in between. There are maintainers who do not respond for whatever reason and there are others who are solving reported issue in a minute. I don't believe that it was meant to threaten anybody. You read the Automating the NonResponsiveMaintainers policy as remove the original maintainer or punish him but it might be very well read in opposite way, exactly as you proposed. There is no need for drama. This is not the first discussion on the topic I'm involved into. There are such maintainers I agree. But what is the problem with the current NonResponsiveMaintainers policy? How would you automate this? And asking to do it in a week? Every packager deserves at least the few steps described into the current procedure. The current procedure is a pain ... and it happens that after month of waiting, maintainer suddenly appear and (s)he is really angry how dare you can call me unresponsive when I am just busy with other projects/live. This is not good from opposite side. And that happened to me. So current procedure is at least pretty vague and there is no support in kind of some infrastructure. You have to check hmm, is it already week since I last pinged somebody on BZ or ML? Hm, not yet. Ok, I'll wait. You see, the maintainer is not unresponsive. Noone can expect everyone to jump in immediately (week is close to that). If you get your commit rights automatically, no problem for anyone, right? Alex Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Aleksandar Kurtakov akurt...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 3:08:26 PM Subject: Re: Automating the NonResponsiveMaintainers policy - Original Message - From: Vít Ondruch vondr...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:54:52 PM Subject: Re: Automating the NonResponsiveMaintainers policy Dne 2.3.2012 13:47, Aleksandar Kurtakov napsal(a): - Original Message - From: Vít Ondruchvondr...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:37:53 PM Subject: Re: Automating the NonResponsiveMaintainers policy Dne 2.3.2012 13:19, Aleksandar Kurtakov napsal(a): - Original Message - From: Matthias Rungemru...@matthias-runge.de To: Development discussions related to Fedoradevel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:05:07 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 02/03/12 12:53, Marcela Mašláňová wrote: I'm afraid we end up with more bureaucracy than we have now. I'm not against tracking some statistics, so you can look up who is active and probably will answer in few days, but I'd rather not use it for the unresponsive process. Marcela I'm thinking about how to support Jóhann with a proven packager (or two). Since it seems not wanted by Fesco, to give him the corresponding rights to commit his changes directly? This final target (all services are supported by systemd) seems to be clear to everyone. This is a noble goal and I wish this finishes sooner. But attacking packagers by threatening is not gaining any support for the efforts. Most of us gained their commit rights by talking to the respective maintainers getting them approve us as comaintainers, it's a lengthy process I agree. But it's not that hard to ask for co-maintainership so one gets commit rights. I wonder whether someone refused to give commit rights for someone wanting to add systemd support in his package? People should finally understand that by threatening and over-bureaucracy nothing will improve. When someone wants to see a feature done he should get his hands dirty in all aspects - do the changes, find the maintainer, talk to them, get commit rights or get them to push changes, do builds if needed. We ship a distribution so if someone do something but doesn't integrate with the rest we have nothing. And integration is collaboration it's not something one can enforce with bureacracy. Alex, Don't be so touchy please. The truth is somewhere in between. There are maintainers who do not respond for whatever reason and there are others who are solving reported issue in a minute. I don't believe that it was meant to threaten anybody. You read the Automating the NonResponsiveMaintainers policy as remove the original maintainer or punish him but it might be very well read in opposite way, exactly as you proposed. There is no need for drama. This is not the first discussion on the topic I'm involved into. There are such maintainers I agree. But what is the problem with the current NonResponsiveMaintainers policy? How would you automate this? And asking to do it in a week? Every packager deserves at least the few steps described into the current procedure. The current procedure is a pain ... and it happens that after month of waiting, maintainer suddenly appear and (s)he is really angry how dare you can call me unresponsive when I am just busy with other projects/live. This is not good from opposite side. And that happened to me. So current procedure is at least pretty vague and there is no support in kind of some infrastructure. You have to check hmm, is it already week since I last pinged somebody on BZ or ML? Hm, not yet. Ok, I'll wait. You see, the maintainer is not unresponsive. Noone can expect everyone to jump in immediately (week is close to that). If you get your commit rights automatically, no problem for anyone, right? Probably extending the current process with give me commit rights step on the second week via fesco/fpc ticket? Alex Alex Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 12:41 PM, Aleksandar Kurtakov wrote: Nope, if you are a packager already and you have a unit file you want to push in my package just ask me about commit rights via pkgdb and a mail explaining it and I'll definetely approve your request and I'm pretty sure that a number of packagers will do that too. I'm not a packager already nor can I become one since I dont want to maintain a single package in the distribution since it does not scratch my ich but I would like to be able to fix things if I do come across them at least with regards to spec files changes. ( There is atleast one feature ( systemd preset ) on the horizon that might require spec file changes and that in turn means spec file changes for the equal amount packages that are daemon/services in the distribution and somebody will have to do that work ) But I do certainly understand what your getting at since a week back I was suggesting changes to one of the component ( nothing to do with systemd ) we ship by default and adding configuration files for few other components so we could deliver better out of the box experience to our end user base and the relevant maintainer agreed and told me that he had noticed that I was up for PP and I should just go ahead and fix it myself once I had been approved since this was not high enough on the priority list for him fix... But as things are now I cant become a proven packager since I'm not already an packager and I never will become a packager since I dont want to be maintaining a package in the distribution so really there is no place for people like me that want to fix things without having to maintaining an package in the distribution first... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 12:12 PM, Jóhann B. Guðmundsson wrote: On 03/02/2012 11:02 AM, Marcela Mašláňová wrote: Ok, so you'll automatically start non-responsive maintainer process, because maintainer didn't work on a one bug. But he might be working on different component for whole month. He might be working on a new upstream release and not paying attention to low priority bugzillas. You should take more parameters than one bug to kick someone from Fedora. The real point is: There is no strict parameter set, because the reasons for why reports get not addressed are manifold. This is based on more then one bug against one component and through observation in several release cycles. If an maintainer does not want to be affected by the automatic non responsive process all he would have to do would simply be something like changing the report status from new to assigned and leave feed back on it. I other words, all is proposal would be doing is to cause bureaucratic churn. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 01:34 PM, Ralf Corsepius wrote: I other words, all is proposal would be doing is to cause bureaucratic churn. Well it only causes bureaucratic churn or otherwise inconvenience for non responding maintainers as in maintainers that do not respond to a report in timely manner + there is absolutely nothing preventing an reporter to initiate the non responsive policy manually as is. This would just automate that process and there are several advantage of doing that. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 03:21 PM, Toshio Kuratomi wrote: Process looks like this: * Guidelines updated * Someone notices that the package does not follow the guidelines (Note that this step does not require that the Guidelines were updated... the packaging bug could have been missed during review or been introduced later). * That person files a bug. * If the maintainer chooses to ignore the bug or refuse to fix it then the matter is escalated. - In an ideal world, it would probably go to FPC as a can we change the guidelines? I have this special case which I don't think you intended. - In a less ideal world, or in the case where the FPC has already made clear that they did intend it to apply in that case, it would fall on FESCo to enforce the decision. How would fesco enforce the decision? That would depend on the arguments being made and the maintainer attitude. For instance, if the maintainer said, I simply don't have time to fix this, enforcement would probably that someone would fix it for them and apply the patch to the spec file. OTOH, if the maintainer decided that they were going to revert any change made to the package to fix the issue, FESCo would have to remove the maintainer from the package and tell them they could not be a committer on that package for a period of time. They might even remove the packager from the packager group if the maintainer was uncooperative enough.enough. Does FPC have any process to measure how many packages are affected by a single change made to guidelines? If so is it hard to implement the process I mentioned which hopefully should keep packages according to guidelines and up to date? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On Fri, Mar 02, 2012 at 12:16:28 +, \Jóhann B. Guðmundsson\ johan...@gmail.com wrote: On 03/02/2012 11:52 AM, Aleksandar Kurtakov wrote: So I would make a contra-proposal. If a maintainer doesn't respond to a bug repord with the status new in a week - give commit rights to the reporter in pkgdb so he/she can fix it himself. I really think this is way more fare and people that tend to think that packagers are just a bunch of lazy guys should step in do some of this dirty work to get an idea what we speak about. There currently is no place in the project for people that want to fix things without having to maintain packages themselves so I think your counter proposal as good as it is can not come to pass until that has been fixed. Wanting to be able to do that is one of the ways you get get proven packager status. That is essentially why I have that status. I mostly use it to fix games and I also usually ask for co-maintainer status, but I also go around fixing FTBFS issues for packages I don't want to co-maintain. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Am 02.03.2012 12:02, schrieb Marcela Mašláňová: Ok, so you'll automatically start non-responsive maintainer process, because maintainer didn't work on a one bug. But he might be working on different component for whole month. He might be working on a new upstream release and not paying attention to low priority bugzillas. define working it is not too much work assign a bug of a owned package to give a sign of life not at least to the submitter even if we do not speak about any automatism if you are working the whole month on a different component and give no single feedback to a new reported bug you are ending in frustrated submitters - if they get a assigned they do not feel ignored so such automatism does not enforce anything which should not be mandatory for a package-owner to not get frustrated users no longer submitting bugreports because they feel ignored and wasted time do this signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On Fri, Mar 02, 2012 at 12:34:10 +, \Jóhann B. Guðmundsson\ johan...@gmail.com wrote: One way to achieve that would be that one could do so by becoming proven packager through some kind of mentoring process ( which does not exist btw ) I would think. I would think the implied process for someone who wanted to get proven packager status but wasn't sure about what they should be doing to accomplish that is to work with their sponsor. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Am 02.03.2012 12:47, schrieb Marcela Mašláňová: Some developers prefer ignore it until they have time. Why should I write yes, yes, it's broken, I'll look at it next month. That's not helping anyway. IT DOES HELP it is a hughe difference for a bugreporter if he feels a month ignored or becomes a response sorry needs time the devopers perfering ignore are the reason for frustrated reporters, bad comments and losing reporters because THEY SPENT TIME for writing a bugreport and should never feel ignored signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Am 02.03.2012 13:00, schrieb Matthias Runge: On 02/03/12 12:52, Aleksandar Kurtakov wrote: If a maintainer doesn't respond to a bug repord with the status new in a week - give commit rights to the reporter in pkgdb so he/she can fix it himself. I kind a' like this proposal. You're speaking of current package maintainers getting commit rights automatically after a timespan, right? What about bug reporter being unable to fix the mentioned bug? And does the bug-reporter get his right revoked after a time (automatically?) you are missing the differences between ignored, assigend and fixed where did you see a line that a bug must be fixed in whatever time? you did not because it is not there the point is that if a reporter takes time to file a bugreport he can expect any response - this response may be change status from new to assigend even without any comment if you now saying that a maintainer has not the time to do this simple step realize that the reporter in the future has no time to report any bugs for nothing and that if the assigned is tto much work the maintainer has really other problems and appearently no time to maintain the package any longer signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 04:27 PM, Jóhann B. Guðmundsson wrote: On 03/02/2012 03:21 PM, Toshio Kuratomi wrote: Process looks like this: * Guidelines updated * Someone notices that the package does not follow the guidelines (Note that this step does not require that the Guidelines were updated... the packaging bug could have been missed during review or been introduced later). * That person files a bug. * If the maintainer chooses to ignore the bug or refuse to fix it then the matter is escalated. - In an ideal world, it would probably go to FPC as a can we change the guidelines? I have this special case which I don't think you intended. - In a less ideal world, or in the case where the FPC has already made clear that they did intend it to apply in that case, it would fall on FESCo to enforce the decision. How would fesco enforce the decision? That would depend on the arguments being made and the maintainer attitude. For instance, if the maintainer said, I simply don't have time to fix this, enforcement would probably that someone would fix it for them and apply the patch to the spec file. OTOH, if the maintainer decided that they were going to revert any change made to the package to fix the issue, FESCo would have to remove the maintainer from the package and tell them they could not be a committer on that package for a period of time. They might even remove the packager from the packager group if the maintainer was uncooperative enough.enough. Does FPC have any process to measure how many packages are affected by a single change made to guidelines? If so is it hard to implement the process I mentioned which hopefully should keep packages according to guidelines and up to date? JBG You are looking for re-review of packages mentioned many times before. But we have problems to find reviewers for new one, so I don't believe we would find enough people for this. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On Fri, Mar 02, 2012 at 10:20:10AM +, Jóhann B. Guðmundsson wrote: I am a feature owner for a feature that involves components in the hundreds and is heavily depended on maintainers responsiveness. For me to start enacting the non responsive maintainers policy is a tremendous work thus I'm wondering if there is something preventing us from automating the non responsive maintainer policy? An bugzilla script that acts something like if maintainer has not responded to a bug report with the status new in a week ( or some other time ) the non responsive maintainers policy automatically starts taking effect. What's your project boy? .. create a huge collection of dirty words? ;-) IMHO it's bad idea. Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On Fri, Mar 02, 2012 at 13:55:11 +, \Jóhann B. Guðmundsson\ johan...@gmail.com wrote: I'm not a packager already nor can I become one since I dont want to maintain a single package in the distribution since it does not scratch my ich but I would like to be able to fix things if I do come across them at least with regards to spec files changes. ( There is atleast one feature ( systemd preset ) on the horizon that might require spec file changes and that in turn means spec file changes for the equal amount packages that are daemon/services in the distribution and somebody will have to do that work ) That's going to be difficult. Essentially you are asking to jump from non-packager directly to proven packager. What you you could do is post patches needed to do your suggested updates in bugzilla for packagers to apply. In theory this process should work well, as the packages just need to review what you did and then apply it rather than doing a lot of background study on systemd before being able to write their own patches to do the same thing. But as things are now I cant become a proven packager since I'm not already an packager and I never will become a packager since I dont want to be maintaining a package in the distribution so really there is no place for people like me that want to fix things without having to maintaining an package in the distribution first... Well 'never' may be a bit extreme. I think there is a place for people like this (specialist in some area that works with that specialty on a lot of packages). But figuring out how to demonstrate that expertise and general judgement will take some work. It may not be worth doing this if the specialty is really only needed for a transition and wouldn't really be used much after the transition was complete. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Reindl Harald h.rei...@thelounge.net To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 2:09:00 PM Subject: Re: Automating the NonResponsiveMaintainers policy Am 02.03.2012 13:00, schrieb Matthias Runge: On 02/03/12 12:52, Aleksandar Kurtakov wrote: If a maintainer doesn't respond to a bug repord with the status new in a week - give commit rights to the reporter in pkgdb so he/she can fix it himself. I kind a' like this proposal. You're speaking of current package maintainers getting commit rights automatically after a timespan, right? What about bug reporter being unable to fix the mentioned bug? And does the bug-reporter get his right revoked after a time (automatically?) you are missing the differences between ignored, assigend and fixed where did you see a line that a bug must be fixed in whatever time? you did not because it is not there the point is that if a reporter takes time to file a bugreport he can expect any response - this response may be change status from new to assigend even without any comment if you now saying that a maintainer has not the time to do this simple step realize that the reporter in the future has no time to report any bugs for nothing and that if the assigned is tto much work the maintainer has really other problems and appearently no time to maintain the package any longer So are you saying that every one that finds a bug will obey and report that bug? Once someone manages to enforce this he/she can try to give orders to others about their workflow. Let's agree on that - there are different people with different workflows and etc. If the packager has no rights to say how/when/what will be tested and used I don't see a reason why the reported should be able to give this orders to the packager. It's evolutionary - this way the good packages with good maintainers will survive by people either moving to such packages or becoming maintainers. Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Am 02.03.2012 16:47, schrieb Karel Zak: On Fri, Mar 02, 2012 at 10:20:10AM +, Jóhann B. Guðmundsson wrote: I am a feature owner for a feature that involves components in the hundreds and is heavily depended on maintainers responsiveness. For me to start enacting the non responsive maintainers policy is a tremendous work thus I'm wondering if there is something preventing us from automating the non responsive maintainer policy? An bugzilla script that acts something like if maintainer has not responded to a bug report with the status new in a week ( or some other time ) the non responsive maintainers policy automatically starts taking effect. What's your project boy? .. create a huge collection of dirty words? ;-) systemd so you should not call the appearently only one in the whole distribution careing about not have in 10 years still sysv services boy what are all these maintainers doing? it takes exactly 5 minutes to write a systemd-unit for most services like postfix/dbmail and nothing happens, even not if the one you called boy submits patches, unit-files and pinging maintainers since 3 releases with the result get ignored sad enough that he still needs to ping a single maintainer after systemd introduced in F15 - look when it was released __ in F16 postfix is still a sysv-daemon a maintainer who is not able to pack the few lines below over releases can be called NonResponsiveMaintainers [root@srv-rhsoft:~]$ cat /lib/systemd/system/postfix.service [Unit] Description=Postfix MTA After=network.target dovecot.service mysqld.service [Service] Type=forking ExecStart=/usr/sbin/postfix -c /etc/postfix start ExecStop=/usr/sbin/postfix -c /etc/postfix stop ExecReload=/usr/sbin/postfix -c /etc/postfix reload Restart=always RestartSec=1 [Install] WantedBy=multi-user.target signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 03:47 PM, Karel Zak wrote: What's your project boy? .. create a huge collection of dirty words?;-) Sorry not following where you are going with this? IMHO it's bad idea. Why do you think it's a bad idea automating a process that is now done manually? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On Fri, Mar 02, 2012 at 01:09:00PM +0100, Reindl Harald wrote: you are missing the differences between ignored, assigend and fixed where did you see a line that a bug must be fixed in whatever time? you did not because it is not there the point is that if a reporter takes time to file a bugreport he can expect any response - this response may be change status It seems that you expect professional support service from volunteers. Please, use an enterprise Linux distro if you have such expectations. I have no clue why we should guarantee you any response time. from new to assigend even without any comment For example I usually use assigned only if I'm sure that the report is real issue and I'm able to fix it. if you now saying that a maintainer has not the time to do this simple step realize that the reporter in the future has no time to report any bugs for nothing and that if the assigned is tto much work the maintainer has really other problems and appearently no time to maintain the package any longer Freedom is about responsibility. I believe that Fedora maintainers love freedom. The idea that responsibility is possible to replaced with bureaucracy, processes and meetings is old, unoriginal and wrong. Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 03:45 PM, Marcela Mašláňová wrote: You are looking for re-review of packages mentioned many times before. But we have problems to find reviewers for new one, so I don't believe we would find enough people for this. If it's an manual process sure I can understand why it's hard to recruit people to do that stuff. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Am 2. März 2012 16:56 schrieb Reindl Harald h.rei...@thelounge.net: what are all these maintainers doing? it takes exactly 5 minutes to write a systemd-unit for most services Some packages need a bit more love, especially when the sysv init scripts did more than just starting / stopping a service., e.g. creating / migrating databases. You need to convert that functionality to separate scripts, put those somewhere (/usr/sbin? /usr/libexec/package?), decide whether to let the user start them manually (which is a big step back in user experience), or let systemd run them e.g. via ExecStartPre, and test the whole thing. And then debug and test again. Not a 5 minute job. Just my 2ct - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On Fri, Mar 02, 2012 at 04:13:44PM +, Jóhann B. Guðmundsson wrote: Why do you think it's a bad idea automating a process that is now done manually? because: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers * After 2 attempts of no contact, the reporter asks if anyone knows how to contact the maintainer. * After another 7 days, the reporter posts a formal request to the fedora-devel list with the bug link. * If at least one FESCo member approves the takeover and no one objects within 3 days, the requester may take over the package. Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 04:23 PM, Thomas Moschny wrote: Am 2. März 2012 16:56 schrieb Reindl Haraldh.rei...@thelounge.net: what are all these maintainers doing? it takes exactly 5 minutes to write a systemd-unit for most services Some packages need a bit more love, especially when the sysv init scripts did more than just starting / stopping a service., e.g. creating / migrating databases. You need to convert that functionality to separate scripts, put those somewhere (/usr/sbin? /usr/libexec/package?), decide whether to let the user start them manually (which is a big step back in user experience), or let systemd run them e.g. via ExecStartPre, and test the whole thing. And then debug and test again. Not a 5 minute job. It takes at least an half an hour per systemd unit file with each migration and that's the time is for well written and well behaving daemon and well written legacy sysv init script to migrate, performed by a man experienced in migrating this... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Reindl Harald h.rei...@thelounge.net To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 5:56:10 PM Subject: Re: Automating the NonResponsiveMaintainers policy Am 02.03.2012 16:47, schrieb Karel Zak: On Fri, Mar 02, 2012 at 10:20:10AM +, Jóhann B. Guðmundsson wrote: I am a feature owner for a feature that involves components in the hundreds and is heavily depended on maintainers responsiveness. For me to start enacting the non responsive maintainers policy is a tremendous work thus I'm wondering if there is something preventing us from automating the non responsive maintainer policy? An bugzilla script that acts something like if maintainer has not responded to a bug report with the status new in a week ( or some other time ) the non responsive maintainers policy automatically starts taking effect. What's your project boy? .. create a huge collection of dirty words? ;-) systemd so you should not call the appearently only one in the whole distribution careing about not have in 10 years still sysv services boy what are all these maintainers doing? it takes exactly 5 minutes to write a systemd-unit for most services like postfix/dbmail and nothing happens, even not if the one you called boy submits patches, unit-files and pinging maintainers since 3 releases with the result get ignored Sure, everyone is free to come and show me how a random bug is fixable in 5 minutes. fedpkg clone; fedpkg prep; git am (if you're lucky) ; fedpkg local; yum localinstall; TEST_IT; git commit; git push; fedpkg build Anyone wanting to do that in 5 minutes? be my guest Alex sad enough that he still needs to ping a single maintainer after systemd introduced in F15 - look when it was released __ in F16 postfix is still a sysv-daemon a maintainer who is not able to pack the few lines below over releases can be called NonResponsiveMaintainers [root@srv-rhsoft:~]$ cat /lib/systemd/system/postfix.service [Unit] Description=Postfix MTA After=network.target dovecot.service mysqld.service [Service] Type=forking ExecStart=/usr/sbin/postfix -c /etc/postfix start ExecStop=/usr/sbin/postfix -c /etc/postfix stop ExecReload=/usr/sbin/postfix -c /etc/postfix reload Restart=always RestartSec=1 [Install] WantedBy=multi-user.target -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 04:29 PM, Karel Zak wrote: On Fri, Mar 02, 2012 at 04:13:44PM +, Jóhann B. Guðmundsson wrote: Why do you think it's a bad idea automating a process that is now done manually? because: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers * After 2 attempts of no contact, the reporter asks if anyone knows how to contact the maintainer. * After another 7 days, the reporter posts a formal request to the fedora-devel list with the bug link. * If at least one FESCo member approves the takeover and no one objects within 3 days, the requester may take over the package. Yes the automation would just automate these steps ending with posting the formal request to devel for fesco to pick up. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 10:04 PM, Jóhann B. Guðmundsson wrote: Yes the automation would just automate these steps ending with posting the formal request to devel for fesco to pick up. The best way to convince people is to actually just do it. Post a script and show that it can be done. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 04:42 PM, Rahul Sundaram wrote: Yes the automation would just automate these steps ending with posting the formal request to devel for fesco to pick up. The best way to convince people is to actually just do it. Post a script and show that it can be done. Do we have access bugzilla to test this against? I'm pretty sure the answer here is no since last time I checked you cant even get your username migrated or deleted. So in this case consciousness needs to be reached first then you can start writing and convince whomever are behind the Red Hat bugzilla to be allowed to do this. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Am 02.03.2012 17:20, schrieb Karel Zak: On Fri, Mar 02, 2012 at 01:09:00PM +0100, Reindl Harald wrote: you are missing the differences between ignored, assigend and fixed where did you see a line that a bug must be fixed in whatever time? you did not because it is not there the point is that if a reporter takes time to file a bugreport he can expect any response - this response may be change status It seems that you expect professional support service from volunteers. Please, use an enterprise Linux distro if you have such expectations. I have no clue why we should guarantee you any response time. i expect only the same i do since years for all things if i take resposibility i answer requests or do not take over resposibility paid and not is irrelevant here this has NOTHING to do with enterprise do you pay the reporter for his time? no? so do not spit in his face by ignore him! there are people contributing with their time writing a bugreport - this is in the interest of ALL from new to assigend even without any comment For example I usually use assigned only if I'm sure that the report is real issue and I'm able to fix it. for the example if you make a single comment thank you for your report, i am currently busy whatever phrase you will not fall from your throne and give the reporter a nice and acceptable feedback Freedom is about responsibility. I believe that Fedora maintainers love freedom. The idea that responsibility is possible to replaced with bureaucracy, processes and meetings is old, unoriginal and wrong responsibility is the right word but missing in fedora often everybody is free to do everything or nothing i agree this is good - but it does not work in the real world because this needs people showing responsibility in the way how tey are acting and not only using the word it does simply not matter if someoney doing things for free or for money - if someone does for money i would even understand the no-response-attitude, if someone says he do things because he likes them no understanding for this one point of responsibility is taking some seconds of your time to give ANY response after people spent time and decided try to help making things better or they will sooner or later deicde no longer waste their time! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Am 02.03.2012 17:23, schrieb Thomas Moschny: Am 2. März 2012 16:56 schrieb Reindl Harald h.rei...@thelounge.net: what are all these maintainers doing? it takes exactly 5 minutes to write a systemd-unit for most services Some packages need a bit more love, especially when the sysv init scripts did more than just starting / stopping a service., e.g. creating / migrating databases. agreed - but this no argument for the ones needing only 5 minutes and are ignored since months, so i guess you did not read the word most signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Am 02.03.2012 17:35, schrieb Aleksandar Kurtakov: it takes exactly 5 minutes to write a systemd-unit for most services like postfix/dbmail and nothing happens, even not if the one you called boy submits patches, unit-files and pinging maintainers since 3 releases with the result get ignored Sure, everyone is free to come and show me how a random bug is fixable in 5 minutes where did i say fix a random bug in 5 minutes? this postfix-update was before F16 release there were more postfix updates in the timeframe http://koji.fedoraproject.org/koji/buildinfo?buildID=263131 * writing the systemd-unit takes 2 minutes for postfix * no need for package anything, install put it locally in /etc/systemd/system * so testing takes another 3 minutes, no compile needed and now explain me what a maintainer knowing that the change to systemd was done with F15 is thinking by ship the package with F16 again as sysv-service while users partly converted 20 different services in /ect/systemd/system/ hallelujha, in F17 postfix has a systemd-unit read the changelog who is responsible for this and compare the name with the tread-starter, take a deep breath and think about how fursutrated it must be for him running behinfd maintainers from one release to the next signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 10:15 PM, Jóhann B. Guðmundsson wrote: On 03/02/2012 04:42 PM, Rahul Sundaram wrote: Yes the automation would just automate these steps ending with posting the formal request to devel for fesco to pick up. The best way to convince people is to actually just do it. Post a script and show that it can be done. Do we have access bugzilla to test this against? What access do you need? If you need something to test and you don't have access, run your own instance. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 6:45:24 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 03/02/2012 04:42 PM, Rahul Sundaram wrote: Yes the automation would just automate these steps ending with posting the formal request to devel for fesco to pick up. The best way to convince people is to actually just do it. Post a script and show that it can be done. Do we have access bugzilla to test this against? I'm pretty sure the answer here is no since last time I checked you cant even get your username migrated or deleted. So in this case consciousness needs to be reached first then you can start writing and convince whomever are behind the Red Hat bugzilla to be allowed to do this. There is https://partner-bugzilla.redhat.com/ and I'm pretty sure that one can get better permissions on it. Alex JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Reindl Harald h.rei...@thelounge.net To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: Aleksandar Kurtakov akurt...@redhat.com Sent: Friday, March 2, 2012 6:45:14 PM Subject: Re: Automating the NonResponsiveMaintainers policy Am 02.03.2012 17:35, schrieb Aleksandar Kurtakov: it takes exactly 5 minutes to write a systemd-unit for most services like postfix/dbmail and nothing happens, even not if the one you called boy submits patches, unit-files and pinging maintainers since 3 releases with the result get ignored Sure, everyone is free to come and show me how a random bug is fixable in 5 minutes where did i say fix a random bug in 5 minutes? this postfix-update was before F16 release there were more postfix updates in the timeframe http://koji.fedoraproject.org/koji/buildinfo?buildID=263131 * writing the systemd-unit takes 2 minutes for postfix * no need for package anything, install put it locally in /etc/systemd/system * so testing takes another 3 minutes, no compile needed and now explain me what a maintainer knowing that the change to systemd was done with F15 is thinking by ship the package with F16 again as sysv-service while users partly converted 20 different services in /ect/systemd/system/ hallelujha, in F17 postfix has a systemd-unit read the changelog who is responsible for this and compare the name with the tread-starter, take a deep breath and think about how fursutrated it must be for him running behinfd maintainers from one release to the next Have you ever thought that for number of people this systemd units might be something they know nothing about and they need to spend time on it? That's why I say random bug. If this issue is not random for you it doesn't mean that's the same for everyone else. Have you ever thought that different people might have different priorities? If someone wants something to happen - step in and do it. Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 10:15 PM, Reindl Harald wrote: * writing the systemd-unit takes 2 minutes for postfix * no need for package anything, install put it locally in /etc/systemd/system * so testing takes another 3 minutes, no compile needed This timeline is not reasonable. It typically takes half an hour to an hour to write and test it properly if you are not already familiar with systemd. For most packages, I would consider this a low priority item because systemd has compatibility built-in. Remember that many maintainers deal with more than one package and several of them have other projects including upstream development to take care of. If you think you are more efficient at it, you are welcome to sign up as package maintainer and demonstrate that. Talk is cheap. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 04:49 PM, Rahul Sundaram wrote: What access do you need? If you need something to test and you don't have access, run your own instance. Here you assume that people have enough hw or vm capable hardware to do so which is not in my case. And this only requires copying the current EOL script and make the necessary changes in use so the can be done on technical level if consciousness is reached for this. Thus if people agree on this I shall put work on getting it done but before hand forget it. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Am 02.03.2012 17:55, schrieb Aleksandar Kurtakov: Have you ever thought that for number of people this systemd units might be something they know nothing about and they need to spend time on it? have you ever thought that i wrote the systemd-units for nearly all relevant services on my personal and business machines in a few days also with know nothing about while i expexted this is what package maintainers are for? systemd was planned for F14, dealyed for F15 so please do not tell me there was not enough time for maintainers usualy not the owner of hundret service-packages to take a look what is coming in the next release and start preparing their packages within a full year signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 04:55 PM, Rahul Sundaram wrote: This timeline is not reasonable. It typically takes half an hour to an hour to write and test it properly Add another half an hour for an individual not familiar with the spec file making the necessary adjustments to the spec file and test rebuild it... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On Fri, Mar 02, 2012 at 03:27:24PM +, Jóhann B. Guðmundsson wrote: On 03/02/2012 03:21 PM, Toshio Kuratomi wrote: Process looks like this: * Guidelines updated * Someone notices that the package does not follow the guidelines (Note that this step does not require that the Guidelines were updated... the packaging bug could have been missed during review or been introduced later). * That person files a bug. * If the maintainer chooses to ignore the bug or refuse to fix it then the matter is escalated. - In an ideal world, it would probably go to FPC as a can we change the guidelines? I have this special case which I don't think you intended. - In a less ideal world, or in the case where the FPC has already made clear that they did intend it to apply in that case, it would fall on FESCo to enforce the decision. How would fesco enforce the decision? That would depend on the arguments being made and the maintainer attitude. For instance, if the maintainer said, I simply don't have time to fix this, enforcement would probably that someone would fix it for them and apply the patch to the spec file. OTOH, if the maintainer decided that they were going to revert any change made to the package to fix the issue, FESCo would have to remove the maintainer from the package and tell them they could not be a committer on that package for a period of time. They might even remove the packager from the packager group if the maintainer was uncooperative enough.enough. Does FPC have any process to measure how many packages are affected by a single change made to guidelines? If so is it hard to implement the process I mentioned which hopefully should keep packages according to guidelines and up to date? There is no one method for the FPC. When we pass guidelines we usually do think about how many packages are affected but there's no general method that we follow. However, for most (not all but most) guideline changes, we don't tell people that there's a hurry to fix things. They can be fixed as people file bugs and propose patches. There are a few changes that are fixes that we feel are necessary enough that we want to be proactive about fixing when the guidelines change. For those we are more strict about figuring out how much work is involved. -Toshio pgpKUIV8B94kl.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
- Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: devel@lists.fedoraproject.org Sent: Friday, March 2, 2012 6:56:47 PM Subject: Re: Automating the NonResponsiveMaintainers policy On 03/02/2012 04:49 PM, Rahul Sundaram wrote: What access do you need? If you need something to test and you don't have access, run your own instance. Here you assume that people have enough hw or vm capable hardware to do so which is not in my case. And this only requires copying the current EOL script and make the necessary changes in use so the can be done on technical level if consciousness is reached for this. Thus if people agree on this I shall put work on getting it done but before hand forget it. Running the NonResponsiveMaintainers automatically based on single bug report is something that shouldn't be even discussed! If something like this should be discussed it should have a lot different constraints: * way longer period - (Eclipse.org marks people as not active after 9 months.) - at least 3 months * not a single bugzilla - at least 3 bugzillas * no commits in these 3 months * no builds in these 3 months And all of these should happen in the very same 3 months period to mark a person as inactive. Alex JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 10:26 PM, Jóhann B. Guðmundsson wrote: On 03/02/2012 04:49 PM, Rahul Sundaram wrote: What access do you need? If you need something to test and you don't have access, run your own instance. Here you assume that people have enough hw or vm capable hardware to do so which is not in my case. And this only requires copying the current EOL script and make the necessary changes in use so the can be done on technical level if consciousness is reached for this. Thus if people agree on this I shall put work on getting it done but before hand forget it. Again, what access do you need and who have you asked for it? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/02/2012 10:45 PM, Reindl Harald wrote: for a simple service like postfix or dbmail? surely not! I disagree. i even sent a bunlde of systemd-units to the devel-list As I informed you at that time, sending a bundle is not very useful. You need to file individual bug reports and if you want to go further, sign up as a package maintainer, get commit access and do the work yourself. Rahul -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPUQJqAAoJELauRe7G9dGMzUAIALSCES0QxwWutRFn4wDzpiT4 tREn9YJWHo90S0/NGrQDX6G/n3DmArEsSdJq7R9tn55KnmMTTSUGRfzLGHdBUKQ8 +DlR5WL8rM4BvU6AXr//EtpJM+s7/WRaufMZCK6UZNfxhRe2YjiHRc5PVuXmOG2/ 3QQWZdPoNejqdjTnqy0comrT6blqM3D7L2sggiUrvTVLY/fBXmsSrjKpRYOWjETB dlIho3YZjatlSnJxAypX1++8KxNHtPRUf/eHSjaRbqAIa6n4nWXtRM3JcRTQo/vK mJhCxiG0tEPG2jVS/Cjeo9M2TXTJm8Ub7wIMAIyeqkkf3dqMUPKVbM2h7hoYK/0= =vUtN -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 05:10 PM, Rahul Sundaram wrote: Again, what access do you need and who have you asked for it? It's pretty obvious that this is a proposal I made today thus I have asked no one for it nor can I since infrastructure has made it clear to me when I asked them to fix my user accounting mess that I found myself into that they do not handle bugzilla that is Red Hat only territory. Secondly first we need to reach conscious about the proposal in general then if reached settle on a time frame for the automatic process to start taking place as Aleksandar and other have pointed out. I'm not sure how you do things in your part of the world but usually here on top of the world we dont start building houses without knowing first how they should look like... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 10:53 PM, Jóhann B. Guðmundsson wrote: On 03/02/2012 05:10 PM, Rahul Sundaram wrote: Again, what access do you need and who have you asked for it? It's pretty obvious that this is a proposal I made today thus I have asked no one for it nor can I since infrastructure has made it clear to me when I asked them to fix my user accounting mess that I found myself into that they do not handle bugzilla that is Red Hat only territory. I think you need to ask for access that you need rather than assume you don't get it because of something unrelated in the past. It is not clear to me what access do you need beyond what you already have to write a test script. I'm not sure how you do things in your part of the world but usually here on top of the world we dont start building houses without knowing first how they should look like... That was completely uncalled for. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 05:29 PM, Rahul Sundaram wrote: That was completely uncalled for. I disagree I know for a fact that you are well aware of the EOL and other script that is used with bugzilla so you were well aware this was technically achievable and you then your self go about asking me to start writing stuff without people having reached consciousness if we should do that in the first place. So this was completely called for by your own doing with I might add and I quote you The best way to convince people is to actually just do it. Post a script and show that it can be done. The question here is not if it can be done the question here is should it be done in the first place. If the outcome is yes we should then we can start working on how we should go about doing that and yes then I will start looking into how to do it. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On Friday, March 2, 2012, 12:23:51 PM, Jóhann wrote: On 03/02/2012 05:10 PM, Rahul Sundaram wrote: Again, what access do you need and who have you asked for it? It's pretty obvious that this is a proposal I made today thus I have asked no one for it nor can I since infrastructure has made it clear to me when I asked them to fix my user accounting mess that I found myself into that they do not handle bugzilla that is Red Hat only territory. Secondly first we need to reach conscious about the proposal in general then if reached settle on a time frame for the automatic process to start taking place as Aleksandar and other have pointed out. I'm not sure how you do things in your part of the world but usually here on top of the world we dont start building houses without knowing first how they should look like... Perhaps one factor is that what you are trying to build may not be right for the problem at hand, and a new solution is required for a different sort of problem? Or perhaps the issue is that we only have one sort of tool/process, and you are attempting to solve your problem with that tool when a better solution would be to propose a new tool. The NonResponsiveMaintainer process is designed to remove all packages from a maintainer who has gone missing, and is no longer able to take care of their duties as a Fedora package owner. It seems to me that many who object to using this large hammer to solve what some view (correctly or incorrectly) as one minor packaging issue of many. Perhaps it would be better to view this as something more akin to the FTBFS (fails to build from source) process, where regular attempts are made to build packages from source, and those failures tracked. That and the follow-up process are more of an action required by maintainer type of process than a fix it now or else process. I would suggest that you might be better to propose a generalized FTFPG (fails to follow packaging guidelines) process, of which one of the first regular automated checks would be to discover and track packages that are not enabled for systemd. This would expand over time to check for other packages which violate other guidelines for which automated checks can be created. Automation would include creating bugs, tracking reports, and should have exception lists to support known/approved exceptions. By the way, that automation would need to be in a package... which might well be suitable to be your one/only Fedora package. 8^) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 11:20 PM, Jóhann B. Guðmundsson wrote: On 03/02/2012 05:29 PM, Rahul Sundaram wrote: That was completely uncalled for. I disagree Let me put in another way then. Cut that out. Talking about your world vs my world makes it personal not to mention sarcastic there is zero room for that in a technical discussion. I know for a fact that you are well aware of the EOL and other script that is used with bugzilla so you were well aware this was technically achievable and you then your self go about asking me to start writing stuff without people having reached consciousness if we should do that in the first place. You will never reach consensus on these matters as you should know by now having started many such discussions which has resulted in nothing. Some people will agree and others disagree and nothing will get done. If that's how you want to roll, feel free. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Lets drop this subthread please? I don't think it's doing anyone any good to see you two hitting back and forth. If you must, take it to private email? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On Fri, Mar 02, 2012 at 10:20:10AM +, Jóhann B. Guðmundsson wrote: An bugzilla script that acts something like if maintainer has not responded to a bug report with the status new in a week ( or some other time ) the non responsive maintainers policy automatically starts taking effect. It's the same problem as email: anyone could push 'todo' items onto anyone else's plate. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
Karel Zak (k...@redhat.com) said: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers * After 2 attempts of no contact, the reporter asks if anyone knows how to contact the maintainer. * After another 7 days, the reporter posts a formal request to the fedora-devel list with the bug link. * If at least one FESCo member approves the takeover and no one objects within 3 days, the requester may take over the package. So, trying to get some progress here, I see two issues: 1) It's all manual. Ideally, there would be a way to pull this information, rather than relying on manual pokes and collecting the results of said pokes, even if we didn't change the policy at all. 2) It doesn't solve the problem of a non-responsive maintainer where the requester *DOESN'T* want to take over the package. For example, just because I might have a an issue getting a needed change into glibc doesn't mean I would want take over glibc. Of course, without a willing maintainer to take over in this case, you're still stuck. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On Fri, Mar 02, 2012 at 13:53:55 -0500, Bill Nottingham nott...@redhat.com wrote: 2) It doesn't solve the problem of a non-responsive maintainer where the requester *DOESN'T* want to take over the package. For example, just because I might have a an issue getting a needed change into glibc doesn't mean I would want take over glibc. Of course, without a willing maintainer to take over in this case, you're still stuck. Yeah, I have seen similar cases where it seemed like people thought that somehow another maintainer would get assigned or that the current maintainer should be punished. I tried to point out, that just removing a current maintainer from a package doesn't actually help get things fixed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On Fri, 2 Mar 2012 13:53:55 -0500 Bill Nottingham nott...@redhat.com wrote: Karel Zak (k...@redhat.com) said: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers * After 2 attempts of no contact, the reporter asks if anyone knows how to contact the maintainer. * After another 7 days, the reporter posts a formal request to the fedora-devel list with the bug link. * If at least one FESCo member approves the takeover and no one objects within 3 days, the requester may take over the package. So, trying to get some progress here, I see two issues: 1) It's all manual. Ideally, there would be a way to pull this information, rather than relying on manual pokes and collecting the results of said pokes, even if we didn't change the policy at all. 2) It doesn't solve the problem of a non-responsive maintainer where the requester *DOESN'T* want to take over the package. For example, just because I might have a an issue getting a needed change into glibc doesn't mean I would want take over glibc. Of course, without a willing maintainer to take over in this case, you're still stuck. Related to this, Pierre-YvesChibon wrote a tool to check a bunch of things for a fedora account, so you could at least see if someone was still active in some areas while not in others: https://github.com/pypingou/fedora-active-user If you are running into no reply from a bug, you could run this and see if the maintainer has been active in other areas, or just appears to be gone. Might help before determining if you should start the inactive process. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
2012/3/2 Jóhann B. Guðmundsson johan...@gmail.com: I am a feature owner for a feature that involves components in the hundreds and is heavily depended on maintainers responsiveness. For me to start enacting the non responsive maintainers policy is a tremendous work thus I'm wondering if there is something preventing us from automating the non responsive maintainer policy? An bugzilla script that acts something like if maintainer has not responded to a bug report with the status new in a week ( or some other time ) the non responsive maintainers policy automatically starts taking effect. To get out of that automatic non responsive process the maintainer would have to comment on the bug and set it's status assigned ( or something similar ). I understand that this is frustrating to you but your solution is just wrong IMO. We don't have infinite resources so throwing people out just because they did not respond withing a week is a bad joke. The better fix here is ... you want to do the change file a bug wait for $x amount of time ... no response - go ahead an commit. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 07:34 PM, Kevin Fenzi wrote: Related to this, Pierre-YvesChibon wrote a tool to check a bunch of things for a fedora account, so you could at least see if someone was still active in some areas while not in others: https://github.com/pypingou/fedora-active-user If you are running into no reply from a bug, you could run this and see if the maintainer has been active in other areas, or just appears to be gone. Might help before determining if you should start the inactive process. Thanks for that I'll have a look at this. I should also mention if we implement an automated non responsive process we should do the same for NEEDINFO from reporters as in if an reporter has not responded in a month ( or some other time ) the bug should be closed as INSUFFICIENT DATA. I would think that's only fair... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On 03/02/2012 07:54 PM, drago01 wrote: I understand that this is frustrating to you but your solution is just wrong IMO. We don't have infinite resources so throwing people out just because they did not respond withing a week is a bad joke. The better fix here is ... you want to do the change file a bug wait for $x amount of time ... no response - go ahead an commit. The week was just a sample time and it would be week + the NonResponsiveMaintainers policy process time with an confirmation required from FESCO as the policy dictates. Some people seem to be confusing this like this would instantly take effect which is not the case here. We are just talking about automating the NonResponsiveMaintainers policy as is so instead of an reporter to manually perform these steps ( which they can perform at any time now btw ) those steps would be automated... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On Friday, March 2, 2012, 4:21:13 PM, Jóhann wrote: Some people seem to be confusing this like this would instantly take effect which is not the case here. We are just talking about automating the NonResponsiveMaintainers policy as is so instead of an reporter to manually perform these steps ( which they can perform at any time now btw ) those steps would be automated... It really _is_ quite different. The trigger for NonResponsiveMaintainers now is an actual person with a real problem that they need solving. People understand this trigger. An automated trigger has to be something substantial, a tuned heuristic based on actual outstanding bugs in specific states. Triggering too often, or without clear justification will result in the automated emails being ignored as spam. Triggering the process purely based on lack of activity is one of the cases that isn't reasonable. The maintainer's packages could all be very mature, and need no rebuilding and infrequent updates (because upstream only releases every couple of years). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
