Some question\Ideas Wiki Admin?
This didn't seem to fit the trac-ticket system. Some question\Ideas Following on member(s) that may have left the project and\or sub-group(s). I am getting delivery failure on *@fp.o email aliases. Is that a good indicator of someone having left the fp.o? How can it be made certain\ is certainty possible? If so, are they auto removed from fp.o Old wiki user pages? Content can be cleared, can old stuff be deleted? There appears to be many such "needs love" pages. Came across: https://www.mediawiki.org/wiki/Extension:DeleteBatch -- Regards, Frank I now wear a mask to breathe at night www.frankly3d.com ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Some question\Ideas Wiki Admin?
On Wed, Sep 18, 2013 at 10:35:49AM +0100, Frank Murphy wrote: > This didn't seem to fit the trac-ticket system. > > Some question\Ideas > > Following on member(s) that may have left the project > and\or sub-group(s). > > I am getting delivery failure on *@fp.o email aliases. > Is that a good indicator of someone having left the fp.o? It only indicates that the email the fp.o alias points to is not valid the question being is this a definite state or just a hick up of the mail server. > How can it be made certain\ is certainty possible? The only way would be to manage to contact the person by another way (other email or other mean) to ask them, but that's not an easy thing to do. The account can then be marked as inactive in FAS (we do not delete accounts). > If so, are they auto removed from fp.o > Old wiki user pages? > Content can be cleared, > can old stuff be deleted? There is no automated way to do them and to there are a number of case where I am not sure we would like to. I do not see the harm in keeping old user pages. Outdated content can be updated/adjusted as needed, being old isn't a valid reason to delete a page though (imho). Just my thoughts :) Pierre ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Some question\Ideas Wiki Admin?
On Wed, 18 Sep 2013 12:31:02 +0200 Pierre-Yves Chibon wrote: > > > The only way would be to manage to contact the person by another > way (other email or other mean) to ask them, but that's not an easy > thing to do. The account can then be marked as inactive in FAS (we > do not delete accounts). > Do I open ticket on track to get marked inactive as necessary. with those who would be in freemedia only? and who *@.some.isp bounce back to me, The error that the other server returned was: 550 "Unknown User" > > If so, are they auto removed from fp.o > > Old wiki user pages? > > Content can be cleared, > > can old stuff be deleted? > > There is no automated way to do them and to there are a number of > case where I am not sure we would like to. > I do not see the harm in keeping old user pages. > Outdated content can be updated/adjusted as needed, By who? Are pages delegated to the sub-projects that create them. > being old isn't > a valid reason to delete a page though (imho). It is if none steps up to look after it, Lawn vs jungle. -- Regards, Frank I now wear a mask to breathe at night www.frankly3d.com ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 09/17/2013 04:37 PM, "Jóhann B. Guðmundsson" wrote: You do realize that Fedora != RHEL right so it and it's business needs which includes EPEL ( which has absolutely nothing to do with Fedora ) should be run in an entire separated infrastructure from Fedora. /me mumbles something about sharing. If we can share code (as OSS) why we could not share some infrastructure (especially BZ). -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 09/17/2013 12:37 PM, "Jóhann B. Guðmundsson" wrote: since my frustration level with RH bugzilla has grown to an all time high due to frequent collision with internal RH administrative policy's that nobody in the community knows exactly which are, Can you please elaborate which Red Hat policy collide with Fedora needs? I did not have such experience, so I'm really curious. frequent RH employement mistakes in bug handling between Fedora and RHEL That is because those people work on RHEL and Fedora. And they will continue on that even if you split BZ into two instances. It will be still those same humans and they will be making same mistakes. I doubt that having two instances will help here. as well as several other issue we are faced with it in the QA community and the hindrance it serves to the growth to our community and Can you be specific here, please? the fact we cant hack in it directly to make ours as well as other processes work smoothly which makes everybody's life easier. But it give fedora infrastructure team more free time, which you can spend on some other projects (and we have plenty of them). If you want to hack BZ, you can hack it in upstream: http://www.bugzilla.org/ all changes done there will land in bugzilla.redhat.com sooner or later. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On Tue, Sep 17, 2013 at 7:37 AM, "Jóhann B. Guðmundsson" wrote: > > You do realize that Fedora != RHEL right so it and it's business needs > which includes EPEL ( which has absolutely nothing to do with Fedora ) > should be run in an entire separated infrastructure from Fedora. > > I'm totally on board with moving away from Bugzilla if there are serious issues with using it. However, EPEL is a Fedora SIG, not something run by RHEL. And I would totally expect it to be supported by the Fedora Project. -Jeff ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Summary/Minutes from today's Fedora Infrastructure meeting (2013-09-12)
On 09/16/2013 04:58 PM, Kevin Fenzi wrote: When we first setup our cloud, we setup the storage for volumes on just the head node. The other 5 nodes in the mix also have storage. Over time we added another nodes storage to it, but haven't done anything with the other 4. Thats a bit spread out however, volumes can only be on one of them, so while it allows for more volumes, it doesn't allow for one really large volume. Ideal setup for GlusterFS, I would say. Our cloud setup is isolated from the rest of the network in the datacenter it's at. So, for example it couldn't talk to any of our netapp storage or the like. :( -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 09/18/2013 01:23 PM, Miroslav Suchý wrote: On 09/17/2013 12:37 PM, "Jóhann B. Guðmundsson" wrote: since my frustration level with RH bugzilla has grown to an all time high due to frequent collision with internal RH administrative policy's that nobody in the community knows exactly which are, Can you please elaborate which Red Hat policy collide with Fedora needs? Provide me that policy list and I will point them out. frequent RH employement mistakes in bug handling between Fedora and RHEL That is because those people work on RHEL and Fedora. And they will continue on that even if you split BZ into two instances. It will be still those same humans and they will be making same mistakes. I doubt that having two instances will help here. Yes it will and RHEL != Fedora so stop acting like it does. JBG ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 09/18/2013 01:24 PM, Jeff Sheltren wrote: I'm totally on board with moving away from Bugzilla if there are serious issues with using it. However, EPEL is a Fedora SIG, not something run by RHEL. And I would totally expect it to be supported by the Fedora Project. All the packages already exist and are available in Fedora Epel has nothing to do with Fedora absolutely nothing. It's an extra package repository for RHEL it belongs with RHEL or in it's own separated EPEL infrastructure with it's own policy's and aligned with RHEL and or some of it's clones ( SL/Centos/Oracle etc ). JBG ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On Wed, Sep 18, 2013 at 9:27 AM, "Jóhann B. Guðmundsson" wrote: > On 09/18/2013 01:24 PM, Jeff Sheltren wrote: >> >> >> I'm totally on board with moving away from Bugzilla if there are serious >> issues with using it. However, EPEL is a Fedora SIG, not something run by >> RHEL. And I would totally expect it to be supported by the Fedora Project. > > > All the packages already exist and are available in Fedora > > Epel has nothing to do with Fedora absolutely nothing. > > It's an extra package repository for RHEL it belongs with RHEL or in it's > own separated EPEL infrastructure with it's own policy's and aligned with > RHEL and or some of it's clones ( SL/Centos/Oracle etc ). If you want the Fedora Project to be something larger than a desktop then please stop trying to throw out things that lots of people in the Fedora community create that isn't a desktop. While EPEL has nothing to do with Fedora's traditional product, it has a lot to do with the Fedora community building new and useful things for both the Fedora Project to use as well as those outside the immediate Fedora community. Since *we* use EPEL, it clearly has something to do with *us*. John ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 09/18/2013 04:20 PM, "Jóhann B. Guðmundsson" wrote: On 09/17/2013 12:37 PM, "Jóhann B. Guðmundsson" wrote: since my frustration level with RH bugzilla has grown to an all time high due to frequent collision with internal RH administrative policy's that nobody in the community knows exactly which are, Can you please elaborate which Red Hat policy collide with Fedora needs? Provide me that policy list and I will point them out. :) Red Hat have policies only for Red Hat products. Red Hat have no policy for Fedora. So I'm really curious what happened to you (or somebody else) that you are saying you are frustrated. There must be some story behind, right? frequent RH employement mistakes in bug handling between Fedora and RHEL That is because those people work on RHEL and Fedora. And they will continue on that even if you split BZ into two instances. It will be still those same humans and they will be making same mistakes. I doubt that having two instances will help here. Yes it will and RHEL != Fedora so stop acting like it does. I did not said that they are equal! I said that a lot of Red Hat people spend a lot of their time working on Fedora. And if developer maintain some package in some Red Hat product, in Fedora and in EPEL (which is part of Fedora) - I can imagine that if you have same BZ opened to all three products and I you want to flip BZ to different state, developer can make error and make it for different product (but same component) than you intended. This can happen. And having this scenario on my mind I do not know how different instance of BZ would help this. But maybe you have different scenario on your mind. So can you elaborate on "frequent RH employement mistakes in bug" please? -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Maintaining decorum on Ask Fedora: suspensions/bans
On Wed, 18 Sep 2013 10:34:15 +1000 Ankur Sinha wrote: > Hi, > > The person here[1]: > > - is hot tempered > - rants more than he provides information > - has used abusive language > > On #fedora, such behaviour gets a quiet/temporary ban/permanent ban in > that order. How is this to be applied to Ask Fedora? > > I had really hoped that users would have the common sense to maintain > decorum on ask, but we will come across the isolated case from time to > time. So, I'd like to document the decorum policies and suspension > criteria etc. for the future. > > * At the moment, the only accounts I block are spammers. Well, I would say the code of conduct should be the guide. If they don't follow it and refuse to, banning them should be fine, IMHO. Obviously in that case they are upset because things aren't going well. Another thing that can help in that case is to ask them to take a break or come back and rephrase their question. kevin signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 09/18/2013 02:36 PM, inode0 wrote: On Wed, Sep 18, 2013 at 9:27 AM, "Jóhann B. Guðmundsson" wrote: On 09/18/2013 01:24 PM, Jeff Sheltren wrote: I'm totally on board with moving away from Bugzilla if there are serious issues with using it. However, EPEL is a Fedora SIG, not something run by RHEL. And I would totally expect it to be supported by the Fedora Project. All the packages already exist and are available in Fedora Epel has nothing to do with Fedora absolutely nothing. It's an extra package repository for RHEL it belongs with RHEL or in it's own separated EPEL infrastructure with it's own policy's and aligned with RHEL and or some of it's clones ( SL/Centos/Oracle etc ). If you want the Fedora Project to be something larger than a desktop then please stop trying to throw out things that lots of people in the Fedora community create that isn't a desktop. ? Fedora is already much larger then desktop there are just certain people in our community that have Gnome tunnel vision and cant see beyond that and have for years. While EPEL has nothing to do with Fedora's traditional product, it has a lot to do with the Fedora community building new and useful things for both the Fedora Project to use as well as those outside the immediate Fedora community. Since *we* use EPEL, it clearly has something to do with *us*. Excuse me but I think we in Fedora as an community should be focusing on delivering one LTS release even if it is just to bridge the cap and it only exist between RHEL releases. Now since RH does not want that or atleast not support that I have to ask what carrot does RH throw to the EPEL maintainers to keep them carrying the bits they dont want to maintain themselves? The bottom line is that EPEL is not part of Fedora in any other way then to consume our infrastructure resources, slowing down the rest of the project doing so and bring unnecessary complication to our spec files as well as keep them fairly outdated. JBG ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
"Jóhann B. Guðmundsson" (johan...@gmail.com) said: > On 09/18/2013 01:24 PM, Jeff Sheltren wrote: > > > >I'm totally on board with moving away from Bugzilla if there are > >serious issues with using it. However, EPEL is a Fedora SIG, not > >something run by RHEL. And I would totally expect it to be > >supported by the Fedora Project. > > All the packages already exist and are available in Fedora Not entirely, there are some packages that are only in EPEL. Aside from that... > Epel has nothing to do with Fedora absolutely nothing. If I'm understanding you, you're claiming it *should* have nothing to do with Fedora. However, it clearly does currently - it was started as a Fedora project in 2007. It uses the Fedora infrastructure *intentionally* as an easy way to share resources, share packaging information, share accounts for packagers, share certain policies, etc. Changing this state and severing the relationship would seem to imply 1) telling the EPEL community they're no longer welcome 2) describing how they could do something better by separating. I've not seen a compelling argument for #2 yet, nor a reason the currently relationship is holding back progress in a way that would require the drastic measures of #1. Bill ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 09/18/2013 04:14 PM, Bill Nottingham wrote: "Jóhann B. Guðmundsson" (johan...@gmail.com) said: On 09/18/2013 01:24 PM, Jeff Sheltren wrote: I'm totally on board with moving away from Bugzilla if there are serious issues with using it. However, EPEL is a Fedora SIG, not something run by RHEL. And I would totally expect it to be supported by the Fedora Project. All the packages already exist and are available in Fedora Not entirely, there are some packages that are only in EPEL. Aside from that... Epel has nothing to do with Fedora absolutely nothing. If I'm understanding you, you're claiming it *should* have nothing to do with Fedora. However, it clearly does currently - it was started as a Fedora project in 2007. It uses the Fedora infrastructure *intentionally* as an easy way to share resources, share packaging information, share accounts for packagers, share certain policies, etc. I can see how and why it had been started as Fedora project for and at the convenience of RH ( and it's clones ) as opposed to actually get the EPEL maintainers to maintain that same component for a longer period of time in Fedora as an part of an LTS release. Changing this state and severing the relationship would seem to imply 1) telling the EPEL community they're no longer welcome 2) describing how they could do something better by separating. I've not seen a compelling argument for #2 yet, nor a reason the currently relationship is holding back progress in a way that would require the drastic measures of #1. Given that you could not see a compelling argument changing the command prompt to long hostname for the benefit of administrators or if as you expressed it would take up to much rel-estate space and then propose to do the opposite and remove the short hostname for it, which would have in turn removed the confusing part that the short hostnames are and in turn forced administrators to run command to realise which host they are working ( which they have to do anyway with regards to short hostnames ) I can understand why that you dont see a compallance in the argument I'm making but that wont change the fact that the spec file are being cluttered for epel or rhel compatibility, something those maintainers should be keep in a separated branch away from Fedora. Btw it makes perfect sense that EPEL and RHEL share the same bugzilla instance but not Fedora. JBG ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
EPEL is a valid subproject/SIG of Fedora, and any changes we propose need to take it into account, just like any other part of Fedora we are currently supporting. To get back to the actual subject of this thread, the current status of running our own bugzilla is that we decided that we don't currently have resources or desire to do so, and wanted to try and work with existing bugzilla maintainers to try and address our concerns. If there's things that change, we can change our plan. So, constructive things to do moving forward: * Clearly enumerate the issues with the current bugzilla and we can ask the bugzilla team to see if they can address them. If they do, then things will be better for us all. If they don't, we will know what items are causing problems and we need to specifically address in any solution we run ourselves. The wiki page is a good place to add/note those. * Convince us that something has changed that would make running our own more attractive. For me at least, those would include: More people committed to helping, people with lots of bugzilla, perl or db knowledge committed to helping, some vastly better option than bugzilla appears, bugzilla itself becomes easier/better for our needs upstream, promise of more hardware to run our own on, serious issues unaddressed by current bugzilla admins, etc etc. Just my 2 cents. kevin signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 09/18/2013 05:37 PM, Kevin Fenzi wrote: EPEL is a valid subproject/SIG of Fedora, and any changes we propose need to take it into account, just like any other part of Fedora we are currently supporting. Well can we then make them clean up their spec file changes and keep them in separated branch? To get back to the actual subject of this thread, the current status of running our own bugzilla is that we decided that we don't currently have resources or desire to do so, and wanted to try and work with existing bugzilla maintainers to try and address our concerns. If there's things that change, we can change our plan. So, constructive things to do moving forward: * Clearly enumerate the issues with the current bugzilla and we can ask the bugzilla team to see if they can address them. If they do, then things will be better for us all. If they don't, we will know what items are causing problems and we need to specifically address in any solution we run ourselves. The wiki page is a good place to add/note those. * Convince us that something has changed that would make running our own more attractive. For me at least, those would include: More people committed to helping, people with lots of bugzilla, perl or db knowledge committed to helping, some vastly better option than bugzilla appears, bugzilla itself becomes easier/better for our needs upstream, promise of more hardware to run our own on, serious issues unaddressed by current bugzilla admins, etc etc. Just my 2 cents. So the freedom for us to administrate and hack on our own instance is not good enough and you play the resource card? JBG ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 18 September 2013 11:45, "Jóhann B. Guðmundsson" wrote:
> On 09/18/2013 05:37 PM, Kevin Fenzi wrote:
>
>> EPEL is a valid subproject/SIG of Fedora, and any changes we propose
>> need to take it into account, just like any other part of Fedora we are
>> currently supporting.
>>
>
> Well can we then make them clean up their spec file changes and keep them
> in separated branch?
>
>
Wat? They are in their own branches. Now if you are saying that maintainers
should not have %{epel} in a fedora spec file.. well that is between you
and FESCO or you and the maintainer.
>
>
>> To get back to the actual subject of this thread, the current status of
>> running our own bugzilla is that we decided that we don't currently
>> have resources or desire to do so, and wanted to try and work with
>> existing bugzilla maintainers to try and address our concerns.
>>
>> If there's things that change, we can change our plan.
>>
>> So, constructive things to do moving forward:
>>
>> * Clearly enumerate the issues with the current bugzilla and we can ask
>>the bugzilla team to see if they can address them. If they do, then
>>things will be better for us all. If they don't, we will know what
>>items are causing problems and we need to specifically address in any
>>solution we run ourselves. The wiki page is a good place to add/note
>>those.
>>
>> * Convince us that something has changed that would make running our
>>own more attractive. For me at least, those would include: More
>>people committed to helping, people with lots of bugzilla, perl or db
>>knowledge committed to helping, some vastly better option than
>>bugzilla appears, bugzilla itself becomes easier/better for our needs
>>upstream, promise of more hardware to run our own on, serious
>>issues unaddressed by current bugzilla admins, etc etc.
>>
>> Just my 2 cents.
>>
>
> So the freedom for us to administrate and hack on our own instance is not
> good enough and you play the resource card?
>
>
1) Any bugzilla would require a lot of hardware/software. The current
bugzilla runs with multiple front ends (2-4) and multiple back end database
servers (somewhere between 7 and 10). We are one of the largest users of
the Red Hat bugzilla so we would not be needing anything less because they
aren't there for storage as much as scalability so that is a starting
project price of $70->$120k not including power, cooling, storage,
bandwidth and maintenance. (fast storage may make it much more). From talks
with other large sites using Jira, Mantis, etc this will not change on
which bug system we use because it is the nature of the number of bugs,
lookups, updates, etc. If Fedora QA is interested in it, we can look at
requesting from Red Hat that in the next fiscal year.
2) The large bug bases require at least 2 full time people dealing with
them. Most volunteers are part-time people who tend to start them up, burn
out, get replaced with new volunteers who reimplement, etc. Volunteers are
useful if a full time people are around.
3) We would need a complete bug day for any bug system we would use because
existing bugs rely on lots of internal sql code which would be stuff Johann
wants to remove for either slowness or not Fedora specific calls. Removing
them might lower the number of scaling systems but most of the bug people
have said you just replace them quickly with new items which remove any
savings.
Final point, EPEL is not just for RHEL. EPEL is what brings a lot of
people into Fedora because they see a need for a package they want in RHEL
and find out that they need to help it in Fedora before they can get it in
EPEL. Also the number of systems using EPEL is 10x the number of Fedora
users. So trying to get rid of EPEL is cutting off ones nose to spite ones
face. If you do not like Red Hat is the primary sponsor for Fedora, then I
am sorry, but there isn't anything that I or anyone else here on this list
can do.
--
Stephen J Smoogen.
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Freeze Break Request: bodhi masher update
There's a bug in the bodhi masher that is allowing for duplicate notices to appear in the updateinfo.xml, which causes annoying yum warnings. https://bugzilla.redhat.com/show_bug.cgi?id=960642 I wish to update the bodhi masher with a small change that may potentially fix the issue, but also adds more debugging messages to help us track it down if it is still an problem. https://github.com/fedora-infra/bodhi/commit/42adfc63bb5335479a26087589d82e30ee12428d Thanks, luke pgppBaGgbaqJK.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 09/18/2013 06:16 PM, Stephen John Smoogen wrote:
Wat? They are in their own branches. Now if you are saying that
maintainers should not have %{epel} in a fedora spec file.. well that
is between you and FESCO or you and the maintainer.
The %{epel} along with RHEL and related If's in a Fedora spec file.
I'm not sure if you are aware of it but as soon as we start cleaning up
core/baseOS as well as anything that comes on top of that be it products
or something else we need to clean and macronize as much in the process
to make ourselves more flexible to adapting to changes in the IT
environment ( as well as being able to integrate features at faster pace ).
1) Any bugzilla would require a lot of hardware/software. The current
bugzilla runs with multiple front ends (2-4) and multiple back end
database servers (somewhere between 7 and 10). We are one of the
largest users of the Red Hat bugzilla so we would not be needing
anything less because they aren't there for storage as much as
scalability so that is a starting project price of $70->$120k not
including power, cooling, storage, bandwidth and maintenance. (fast
storage may make it much more). From talks with other large sites
using Jira, Mantis, etc this will not change on which bug system we
use because it is the nature of the number of bugs, lookups, updates,
etc. If Fedora QA is interested in it, we can look at requesting from
Red Hat that in the next fiscal year.
Encase you have not noticed our QA has shrunken quite a bit at least
from the point I started working on the systemd integration ( with
bugzappers and proven packager dying off in that time ) and essentially
with me being the only one and the Red Hat's QA team on blocker bug
meetings and go/no-go.
Now Red Hat's take on that is invent more QA community manager
position pick them off the street and dump them into the community or
the other magic solution "let's automate everything! While the fact is
we ( as in QA ) quite frankly desperately need to find a way to mobilize
people from my point of view since in the end of the day we will always
need human beings testing to certain extent. ( or as some people want
have everything users do report to bugzilla which quickly just becomes
noise in maintainers ears, which means more bugs being ignored )
One such way is for us to take advantage of "badges" which will allows
to atleast have a carrot out there until the individual realize he can
never be on the top, and to do so we need hacking access to bugzilla
which we are not allowed since it's shared with RHEL and there is always
that risk that something slips out from there that should be slip.
2) The large bug bases require at least 2 full time people dealing
with them. Most volunteers are part-time people who tend to start them
up, burn out, get replaced with new volunteers who reimplement, etc.
Volunteers are useful if a full time people are around.
Perhaps infrastructure wize to certain extent but otherwise I disagree
with you. I've gone through couple of RH employees that have burned out
or simply changes jobs or focus within RH, so employees are affected by
this as well and arguably in a shorter time then the volunteer.
3) We would need a complete bug day for any bug system we would use
because existing bugs rely on lots of internal sql code which would be
stuff Johann wants to remove for either slowness or not Fedora
specific calls. Removing them might lower the number of scaling
systems but most of the bug people have said you just replace them
quickly with new items which remove any savings.
Final point, EPEL is not just for RHEL. EPEL is what brings a lot of
people into Fedora because they see a need for a package they want in
RHEL and find out that they need to help it in Fedora before they can
get it in EPEL. Also the number of systems using EPEL is 10x the
number of Fedora users. So trying to get rid of EPEL is cutting off
ones nose to spite ones face. If you do not like Red Hat is the
primary sponsor for Fedora, then I am sorry, but there isn't anything
that I or anyone else here on this list can do.
Well we can always try to find other ways to finance ourselves but I
dont mind RH being our primary sponsor ( I would like to see more
companies in the role of primary ) but I really much dislike certain
disrespect RH shows the community by tearing us a new one like they did
recently in QA community or for example with the WG nomination where RH
employees had already signed without the community even knowing if it's
existence or that Gnome tunnel vision and the discrimination it brings
against other contributors and their work .
JBG
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Freeze Break Request: bodhi masher update
On 18 September 2013 13:46, Luke Macken wrote: > There's a bug in the bodhi masher that is allowing for duplicate notices > to appear in the updateinfo.xml, which causes annoying yum warnings. > > https://bugzilla.redhat.com/show_bug.cgi?id=960642 > > I wish to update the bodhi masher with a small change that may > potentially fix the issue, but also adds more debugging messages to help > us track it down if it is still an problem. > > > https://github.com/fedora-infra/bodhi/commit/42adfc63bb5335479a26087589d82e30ee12428d > > Thanks, > > reviewed patch and understand logic of change +1. > luke > > ___ > infrastructure mailing list > infrastructure@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/infrastructure > -- Stephen J Smoogen. ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Freeze Break Request: bodhi masher update
+1 kevin signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
New Contributor Loïc Maury
Hello, My name is Loïc Maury, and I have just registered to the fedora project for contribute to infrastructure. I use Fedora since five years now, and I am very enthusiastic to contribute. I am particularly interested by project idea for infrastructure and by functional programming (Haskell, Erlang, Lisp). Thank you Loïc ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
* "Jóhann B. Guðmundsson" [18/09/2013 17:45] : > > So the freedom for us to administrate and hack on our own instance > is not good enough and you play the resource card? Note that other distributions have, in the past, gone down the "let's hack Bugzilla to death" path and paid a heavy price for it. Doing this ourselves really REALLY doesn't sound like a good idea unless you have a 4-5 person team to back it up with. Emmanuel ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 09/18/2013 09:09 PM, Emmanuel Seyman wrote: > >So the freedom for us to administrate and hack on our own instance >is not good enough and you play the resource card? Note that other distributions have, in the past, gone down the "let's hack Bugzilla to death" path and paid a heavy price for it. Doing this ourselves really REALLY doesn't sound like a good idea unless you have a 4-5 person team to back it up with. Well if maintaining this is such an headache and we are so dry on resources why not just move the entire stuff under their own projects in github and we just have reporters just report issues there? JBG ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On Wed, 18 Sep 2013 17:45:01 + "Jóhann B. Guðmundsson" wrote: > On 09/18/2013 05:37 PM, Kevin Fenzi wrote: > > EPEL is a valid subproject/SIG of Fedora, and any changes we propose > > need to take it into account, just like any other part of Fedora we > > are currently supporting. > > Well can we then make them clean up their spec file changes and keep > them in separated branch? To what gain? This seems off topic to the question of bugzilla. > So the freedom for us to administrate and hack on our own instance is > not good enough and you play the resource card? Everything in life is tradeoffs. The yummy to trouble ratio. I do not currently find the advantage of being able to 'hacking on our own instance' to outweigh the people and resource costs it would take to do so. This might change though reasonable debate or changing conditions. kevin signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 09/18/2013 09:18 PM, Kevin Fenzi wrote: I do not currently find the advantage of being able to 'hacking on our own instance' to outweigh the people and resource costs it would take to do so. This might change though reasonable debate or changing conditions. Well I'm being serious about the previous mentioned github proposal not being funny or anything . Think about it since we are so scarce on resources having the entire distro on github which makes it more uniq and more first then the entire rings to rule them all proposal. And we just sync the bits to the place they are needed. JBG ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
* "Jóhann B. Guðmundsson" [18/09/2013 21:21] : > > Well if maintaining this is such an headache and we are so dry on > resources why not just move the entire stuff under their own > projects in github and we just have reporters just report issues > there? Well, github's bugtracker is not free, AFAIK, so that's a bit of a problem. There's also the fact that it kind of sucks (github became popular thanks to git, not thanks to its bug tracker). You're going to need to invest heavy manpower to get it to a usable state for Fedora. Emmanuel ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 09/18/2013 09:34 PM, Emmanuel Seyman wrote: : > >Well if maintaining this is such an headache and we are so dry on >resources why not just move the entire stuff under their own >projects in github and we just have reporters just report issues >there? Well, github's bugtracker is not free, AFAIK, so that's a bit of a problem. There's also the fact that it kind of sucks (github became popular thanks to git, not thanks to its bug tracker). You're going to need to invest heavy manpower to get it to a usable state for Fedora. Clarify why JBG ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
* "Jóhann B. Guðmundsson" [18/09/2013 21:40] : > > Clarify why * no dependencies/blocks * no flags * markdown parsing makes it easy to privilege noise over signal * no shared bug lists * no dashboard * status and resolution are conflated Emmanuel ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 09/18/2013 10:05 PM, Emmanuel Seyman wrote: * "Jóhann B. Guðmundsson" [18/09/2013 21:40] : Clarify why * no dependencies/blocks * no flags * markdown parsing makes it easy to privilege noise over signal * no shared bug lists * no dashboard * status and resolution are conflated I would consider that an acceptable loss compared to tapping into one of the largest social networking coding place on the planet as well as the cost saving we of course would as well move fedorahosted up there and drop it from our infrastructure. We want code contributors there they are. We want new and existing project there they are. All we have to do is to sync our upstream into github repository if they dont already exist there then we suck the bits down to us and create rpm packages and spit out products from the sub-community surrounding the collection of those bits. I'm pretty sure we in QA can get by code some web app against http://developer.github.com/v3/issues/ I'm pretty sure the money people can calculate the TCO of doing that way compare to the current way of doing things as well as their think tanks to look further into this You may think i'm crazy proposing but sometimes crazy is needed to do ground breaking things... JBG ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On Wed, Sep 18, 2013 at 3:05 PM, Emmanuel Seyman wrote: > * "Jóhann B. Guðmundsson" [18/09/2013 21:40] : >> >> Clarify why > > * no dependencies/blocks > * no flags > * markdown parsing makes it easy to privilege noise over signal > * no shared bug lists > * no dashboard > * status and resolution are conflated * no way to move bugs from one package to another * no sane way to migrate bugs from other trackers * no way to CC individual bugs without adding a comment * much more limited e-mail options in general Also, if the reason we're switching bug trackers is the belief that the maintainers of it aren't being responsive to Fedora's needs, it makes zero sense to switch to something whose maintainers couldn't care less about us at all. (We're definitely not their target market.) -T.C. ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Plan for tomorrow's Fedora Infrastructure meeting (2013-09-18)
The infrastructure team will be having it's weekly meeting tomorrow, 2013-09-18 at 19:00 UTC in #fedora-meeting on the freenode network. Suggested topics: #topic New folks introductions and Apprentice tasks. If any new folks want to give a quick one line bio or any apprentices would like to ask general questions, they can do so in this part of the meeting. Don't be shy! #topic Applications status / discussion Check in on status of our applications: pkgdb, fas, bodhi, koji, community, voting, tagger, packager, dpsearch, etc. If there's new releases, bugs we need to work around or things to note. #topic Sysadmin status / discussion Here we talk about sysadmin related happenings from the previous week, or things that are upcoming. #topic Upcoming Tasks/Items https://apps.fedoraproject.org/calendar/list/infrastructure/ #topic Open Floor Submit your agenda items, as tickets in the trac instance and send a note replying to this thread. More info here: https://fedoraproject.org/wiki/Infrastructure/Meetings#Meetings Thanks kevin signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Migrating to our own bugzilla instance.
On 09/18/2013 10:41 PM, T.C. Hollingsworth wrote: On Wed, Sep 18, 2013 at 3:05 PM, Emmanuel Seyman wrote: * "Jóhann B. Guðmundsson" [18/09/2013 21:40] : Clarify why ug * no dependencies/blocks * no flags * markdown parsing makes it easy to privilege noise over signal * no shared bug lists * no dashboard * status and resolution are conflated * no way to move bugs from one package to another * no sane way to migrate bugs from other trackers * no way to CC individual bugs without adding a comment * much more limited e-mail options in general Also, if the reason we're switching bug trackers is the belief that the maintainers of it aren't being responsive to Fedora's needs, it makes zero sense to switch to something whose maintainers couldn't care less about us at all. (We're definitely not their target market.) Well there have been several voices within our community wanting us to report directly upstream as opposed to be using bugzilla in the first place and at the same time the project is dire need for more contributors so to me the solution to both these problem is to find a way to bring the community closer to upstream as opposed to us trying to convince upstream come to down to us ( Which we have been trying for years in competition with other distro's ) JBG ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
