Greetings
I think it's time that we start putting some effort into both discussing and migrating away from sharing bugzilla instance with Red Hat.
For the first should we migrate all issues from the RH bugzilla to keep history or should we simply declare a flag day and from that point on everybody will be using the new bug tracker
Secondly do people have any option on which bug tracker we should migrate to as in should we stick to mozilla's bugzilla or should we use something else?
JBG
On Tue, Sep 17, 2013 at 08:24:58AM +0000, "Jóhann B. Guðmundsson" wrote:
Greetings
I think it's time that we start putting some effort into both discussing and migrating away from sharing bugzilla instance with Red Hat.
This is indeed a big question that has been in the air for some time without any real conclusion reached. Since you're speaking about, I assume you know about: https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker
If you have any inputs/ideas feel free to share them, we have already discussed more than once about it but so far the disadvantages and work implied have out-weight the advantages.
One of the big point being the definition of who is "we" in your sentence.
For the first should we migrate all issues from the RH bugzilla to keep history or should we simply declare a flag day and from that point on everybody will be using the new bug tracker
Secondly do people have any option on which bug tracker we should migrate to as in should we stick to mozilla's bugzilla or should we use something else?
You do realize that here you're speaking about migration w/o knowing to what will be the migration? Seems like the reverse order to me.
Pierre
On 17/09/13 10:44, Pierre-Yves Chibon wrote:
On Tue, Sep 17, 2013 at 08:24:58AM +0000, "Jóhann B. Guðmundsson" wrote:
Greetings
I think it's time that we start putting some effort into both discussing and migrating away from sharing bugzilla instance with Red Hat.
This is indeed a big question that has been in the air for some time without any real conclusion reached. Since you're speaking about, I assume you know about: https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker
If you have any inputs/ideas feel free to share them, we have already discussed more than once about it but so far the disadvantages and work implied have out-weight the advantages.
One of the big point being the definition of who is "we" in your sentence.
For the first should we migrate all issues from the RH bugzilla to keep history or should we simply declare a flag day and from that point on everybody will be using the new bug tracker
Secondly do people have any option on which bug tracker we should migrate to as in should we stick to mozilla's bugzilla or should we use something else?
You do realize that here you're speaking about migration w/o knowing to what will be the migration? Seems like the reverse order to me.
Pierre _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Question is, why even bother ? I have yet to see one argument why this would be better. Just making broad statements as such, is not an argument for actually doing it.
I for one, see benefits in keeping it there, because when I search for issues, I sometimes come across a similar issue in rhel5/rhel6, which then allows me to fix or find the issue, that I need to report, so upstream/package maintainer can fix it.
So, I am a bit dubious about this suggestion.
Any enlightenment would be welcome.
Regards,
Tristan
On 09/17/2013 09:44 AM, Pierre-Yves Chibon wrote:
On Tue, Sep 17, 2013 at 08:24:58AM +0000, "Jóhann B. Guðmundsson" wrote:
Greetings
I think it's time that we start putting some effort into both discussing and migrating away from sharing bugzilla instance with Red Hat.
This is indeed a big question that has been in the air for some time without any real conclusion reached. Since you're speaking about, I assume you know about: https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker
No I was unaware of that but skimming over it this "cannot clone bugs over to rhel packages/products easily." is irrelevant point in that discussion + which instance it should be should be decide in good collaboration with the QA community since we are arguably the largest userbase of it.
If you have any inputs/ideas feel free to share them, we have already discussed more than once about it but so far the disadvantages and work implied have out-weight the advantages.
One of the big point being the definition of who is "we" in your sentence.
The project/community in whole but as I have mentioned to Kevin atleast on one occasion if it boils down to it I will personally put my free time in running and administrative that instance 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,frequent RH employement mistakes in bug handling between Fedora and RHEL 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 the fact we cant hack in it directly to make ours as well as other processes work smoothly which makes everybody's life easier.
For the first should we migrate all issues from the RH bugzilla to keep history or should we simply declare a flag day and from that point on everybody will be using the new bug tracker
Secondly do people have any option on which bug tracker we should migrate to as in should we stick to mozilla's bugzilla or should we use something else?
You do realize that here you're speaking about migration w/o knowing to what will be the migration? Seems like the reverse order to me.
Not really we can reach the decision based upon if we would like to migrate "older" bugs to keep history or if we would skip that step and choose to use a fresh deployment and simply use the RH bugzilla instance strictly for historic lookup in bugs purpose for EOL releases.
JBG
On Tue, Sep 17, 2013 at 10:37:57AM +0000, "Jóhann B. Guðmundsson" wrote:
On 09/17/2013 09:44 AM, Pierre-Yves Chibon wrote:
On Tue, Sep 17, 2013 at 08:24:58AM +0000, "Jóhann B. Guðmundsson" wrote:
I think it's time that we start putting some effort into both
The project/community in whole but as I have mentioned to Kevin atleast on one occasion if it boils down to it I will personally put my free time in running and administrative that instance 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,frequent RH employement mistakes in bug handling between Fedora and RHEL 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 the fact we cant hack in it directly to make ours as well as other processes work smoothly which makes everybody's life easier.
For the first should we migrate all issues from the RH bugzilla to keep history or should we simply declare a flag day and from that point on everybody will be using the new bug tracker
Secondly do people have any option on which bug tracker we should migrate to as in should we stick to mozilla's bugzilla or should we use something else?
You do realize that here you're speaking about migration w/o knowing to what will be the migration? Seems like the reverse order to me.
Not really we can reach the decision based upon if we would like to migrate "older" bugs to keep history or if we would skip that step and choose to use a fresh deployment and simply use the RH bugzilla instance strictly for historic lookup in bugs purpose for EOL releases.
Migrating is always possible, it just requires more or less work according to the solution we choose. So it might be an argument in favor of one or another and thus should be considered but not necessarily something to agree on beforehand.
Pierre
hi Johann,
I can empathise with you on the frustration that comes from a certain feature or ease not available to Fedora community due to non-alignment or low priority against RH business needs.
Since this issue has apparently been discussed for a while, one thing that I find amiss from the doc that pingou mentioned is the 'Why' ? I will suggest you add the problems you face to that doc. So when we revisit the page, the list of "whys" over there make it easy to make a decision. (You did mention the whys in the mail response, but would make it better to note and keep adding in the doc).
The first two points on problems/issues over in the doc would be my biggest concern (resource scarcity). Though I agree that cannot assign to rhel would be a trivial one.
https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker#Why_does_Fe...
On Tue, Sep 17, 2013 at 4:07 PM, "Jóhann B. Guðmundsson" <johannbg@gmail.com
wrote:
On 09/17/2013 09:44 AM, Pierre-Yves Chibon wrote:
On Tue, Sep 17, 2013 at 08:24:58AM +0000, "Jóhann B. Guðmundsson" wrote:
Greetings
I think it's time that we start putting some effort into both discussing and migrating away from sharing bugzilla instance with Red Hat.
This is indeed a big question that has been in the air for some time without any real conclusion reached. Since you're speaking about, I assume you know about: https://fedoraproject.org/**wiki/Infrastructure_Fedora_**bug_trackerhttps://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker
No I was unaware of that but skimming over it this "cannot clone bugs over to rhel packages/products easily." is irrelevant point in that discussion + which instance it should be should be decide in good collaboration with the QA community since we are arguably the largest userbase of it.
If you have any inputs/ideas feel free to share them, we have already discussed more than once about it but so far the disadvantages and work implied have out-weight the advantages.
One of the big point being the definition of who is "we" in your sentence.
The project/community in whole but as I have mentioned to Kevin atleast on one occasion if it boils down to it I will personally put my free time in running and administrative that instance 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,frequent RH employement mistakes in bug handling between Fedora and RHEL 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 the fact we cant hack in it directly to make ours as well as other processes work smoothly which makes everybody's life easier.
For the first should we migrate all issues from the RH bugzilla to
keep history or should we simply declare a flag day and from that point on everybody will be using the new bug tracker
Secondly do people have any option on which bug tracker we should migrate to as in should we stick to mozilla's bugzilla or should we use something else?
You do realize that here you're speaking about migration w/o knowing to what will be the migration? Seems like the reverse order to me.
Not really we can reach the decision based upon if we would like to migrate "older" bugs to keep history or if we would skip that step and choose to use a fresh deployment and simply use the RH bugzilla instance strictly for historic lookup in bugs purpose for EOL releases.
JBG
______________________________**_________________ infrastructure mailing list infrastructure@lists.**fedoraproject.orginfrastructure@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/**infrastructurehttps://admin.fedoraproject.org/mailman/listinfo/infrastructure
Hello,
I just added buggenie and it's based on PHP. I can see "Some other systems that don't really fit:" which included php based mantis, too.
Can anyone tell me if it's ok to deploy PHP stuffs?
On 09/17/2013 02:20 PM, Anshu Prateek wrote:
hi Johann,
I can empathise with you on the frustration that comes from a certain feature or ease not available to Fedora community due to non-alignment or low priority against RH business needs.
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 even go so far to say we should clean up all our ks files from all those bit and those bits be carried by RH themselves in a form of patches to the spec files along with any other distro that might be based off Fedora, just like we as an project have to carry our own distribution specific patches to various upstream that make up the distribution in the first place.
JBG
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).
On Tue, Sep 17, 2013 at 7:37 AM, "Jóhann B. Guðmundsson" <johannbg@gmail.com
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
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
On Wed, Sep 18, 2013 at 9:27 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com 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
On 09/18/2013 02:36 PM, inode0 wrote:
On Wed, Sep 18, 2013 at 9:27 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com 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
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
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
On 18 September 2013 11:45, "Jóhann B. Guðmundsson" johannbg@gmail.comwrote:
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.
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 ).
- 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.
- 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.
- 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
* "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
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
* "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
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
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
On Wed, Sep 18, 2013 at 3:05 PM, Emmanuel Seyman emmanuel@seyman.fr 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.
On 09/18/2013 10:41 PM, T.C. Hollingsworth wrote:
On Wed, Sep 18, 2013 at 3:05 PM, Emmanuel Seyman emmanuel@seyman.fr 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
On Wed, 18 Sep 2013 17:45:01 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com 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
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
"Jóhann B. Guðmundsson" (johannbg@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
On 09/18/2013 04:14 PM, Bill Nottingham wrote:
"Jóhann B. Guðmundsson" (johannbg@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
(getting far afield of bugzilla)
"Jóhann B. Guðmundsson" (johannbg@gmail.com) said:
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.
I don't recall any discussions of EPEL being used as this sort of trojan to prevent a Fedora LTS, but it's possible I missed something.
Is your suggestion that instead of building packages to help uesrs who wanted software available for *EL that Fedora should have told those users that they should be helping us make a Fedora LTS instead, I guess that's an option, but it is somewhat hostile to our downstream distributions, and actually makes the individual packager work harder.
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.
The packagers use those *because* it makes their jobs easier when they want a package to be buildable for both EL5, EL6, and various Fedoras.
Why would the packagers want to make their lives harder for something that isn't exposed in any way to make the user's lives better?
There's certainly arguments about simplifying the packaging, but at a certain point you just start looking about how to rip out rpmbuild and spec files entirely in favor of something better.
Bill
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Wed, 18 Sep 2013 16:41:56 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com escribió:
On 09/18/2013 04:14 PM, Bill Nottingham wrote:
"Jóhann B. Guðmundsson" (johannbg@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.
Actually Mike Mcgrath and I started it to support and share what we needed for use in Infrastructure and we wanted to share that work, we also saw that there was a general need for something like it for general use.
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.
I can't say I see a compelling reason for long hostnames, administrators can use config management to set it if they choose. As to spec files a large part of the value for everyone is that the spec files work between Fedora, RHEL and its clones.
but that's off topic, I really dont see any compelling reasons to move off of Red Hats bugzilla today. Down the road that may change. Which doesn't mean we shouldn't keep an eye on the options. We should also document the pain points, and try to get them fixed. I really don't think there is a better option out there than bugzilla, Maybe we can work with other distros/projects and start a new one from the ground up, but that would be a massive undertaking.
Dennis
On 09/20/2013 07:19 PM, Dennis Gilmore wrote:
I really dont see any compelling reasons to move off of Red Hats bugzilla today.
After bit of discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from hosting our own and probably is the correct way forward for us.
1. Generic attitude of many maintainers is that either they go to the correct place ( upstream ) or they get their bugzilla ignored. 2. More often than not downstream maintainer as in packager does not know the code at all so filling the bug downstream makes no sense.
JBG
On 23/09/13 22:36, "Jóhann B. Guðmundsson" wrote:
On 09/20/2013 07:19 PM, Dennis Gilmore wrote:
I really dont see any compelling reasons to move off of Red Hats bugzilla today.
After bit of discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from hosting our own and probably is the correct way forward for us.
- Generic attitude of many maintainers is that either they go to the
correct place ( upstream ) or they get their bugzilla ignored. 2. More often than not downstream maintainer as in packager does not know the code at all so filling the bug downstream makes no sense.
JBG
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Wrong! it pre-filters bug reports, to make sure there is all the valid information, leaving code maintainers to get on with it!
And as to regarding point 1 you make, I have never heard so much rubbish in my life. Every time I filed a bug report the package maintainers have done their best. Sometimes I request or point out an issue and code versions get bumped up by the package maintainer.
Maybe your experience varies, but mine is I just pointed out.
I am starting to wonder if you are on some kind of anti Red Hat hate mission, as I have yet to see any full discussion about this issue.
No pros no cons.
This is not how one makes an argument!
Please also note, I do NOT work for Red Hat! Just in case you think I am some kind of fan boy/employee.
Give some good points, maybe I will change my mind. For instance that the bugzilla is a bit slow at times, which is a bit annoying. But that is still not a reason to throw something that works, out of the window.
So, PLEASE! Where are the arguments for and against this proposal.
Regards,
Tristan
On 09/23/2013 10:19 PM, Tristan Santore wrote:
So, PLEASE! Where are the arguments for and against this proposal.
Actually there have been many RH developers as well as other upstream ones in our community requesting this for many years but just go through the devel list archives or the desktop list archives for the previous discussion and at the same time you will also noticed me being the nr.1 individual arguing against this route however times are changing and after a brief discussion with couple of upstream on irc tonight I have reached the conclusion that this is the best way forward from every angle ( including the one for infrastructure ) thus I will be joining the voices of our upstream developers and pushing hard for this change as well as making that transaction go as smooth as possible in the process.
And quite frankly I doubt that any of the infrastructure team that has been here long enough disagrees with this being the right course of action.
JBG
On Mon, 23 Sep 2013 22:51:55 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
...snip...
And quite frankly I doubt that any of the infrastructure team that has been here long enough disagrees with this being the right course of action.
Well, I do... or at least I don't find it to be any kind of super clear and compelling argument so far.
kevin
Considering I've been involved with infrastructure since at least 2004. I think I classify as one of the long term infrastructure guys and I do not agree with you. There is possibly some cases where it's better to just report upstream. How would we document and make sure that the message got out. There are many more times that the bug only belongs in fedora. I strongly believe fedora developers should be the gateway and the people with the relationship to upstream. It is right to require our users to possible have to create multiple bug reporting accounts in multiple upstreams? I personally do not think so.
Kevin Fenzi kevin@scrye.com wrote:
On Mon, 23 Sep 2013 22:51:55 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
...snip...
And quite frankly I doubt that any of the infrastructure team that has been here long enough disagrees with this being the right course of action.
Well, I do... or at least I don't find it to be any kind of super clear and compelling argument so far.
kevin
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On 09/23/2013 11:12 PM, Dennis Gilmore wrote:
Considering I've been involved with infrastructure since at least 2004. I think I classify as one of the long term infrastructure guys and I do not agree with you. There is possibly some cases where it's better to just report upstream.
If we want the bugs to be fixed it's best to directly file them upstream ourselves.
How would we document and make sure that the message got out.
The how to debug and how to test process I started many years ago in QA.
There are many more times that the bug only belongs in fedora. I strongly believe fedora developers should be the gateway and the people with the relationship to upstream.
Well I thought our goal was to have as many upstreams contributing to Fedora not as many people acting as liasons between upstream and Fedora?
It is right to require our users to possible have to create multiple bug reporting accounts in multiple upstreams? I personally do not think so.
That argument goes both ways you can just as well say should upstream have gazillion downstream distribution bugzilla accounts?
There are two ways this can be solved which works both in favour of upstream and reporters one is to have bugzilla instance communicate between themselves and that concept that breaks immediately since there are various different bugzilla instance in usage as there are upstreams and the other approach to have single large bugzilla instance that all major distribution maintain and use together with specific distribution component ( which infra claims not having resources to do anyway ).
JBG
On Mon, 23 Sep 2013 21:36:51 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 09/20/2013 07:19 PM, Dennis Gilmore wrote:
I really dont see any compelling reasons to move off of Red Hats bugzilla today.
After bit of discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from hosting our own and probably is the correct way forward for us.
"us" ?
- Generic attitude of many maintainers is that either they go to the
correct place ( upstream ) or they get their bugzilla ignored.
citation needed. There are surely components where this is the case, but many others where it's not.
Personally, I help/answer bugzilla bugs, when/if they become clearly a upstream issue I ask the reporter if they would like to file it upstream or would like me to.
- More often than not downstream maintainer as in packager does not
know the code at all so filling the bug downstream makes no sense.
It does in many cases.
* It's a packaging bug.
* It's a request for a version update or something like that.
* It's something related to interaction between packages.
* It's something that is already fixed upstream and the Fedora package simply needs to add the patch.
etc etc.
kevin
On Mon, Sep 23, 2013 at 09:36:51PM +0000, "Jóhann B. Guðmundsson" wrote:
- Generic attitude of many maintainers is that either they go to
the correct place ( upstream ) or they get their bugzilla ignored.
I think this is the problem to fix, actually.
* "Jóhann B. Guðmundsson" [23/09/2013 21:36] :
- Generic attitude of many maintainers is that either they go to
the correct place ( upstream ) or they get their bugzilla ignored.
Note that this is going to annoy a LOT of upstreams. Several of mine have requested that bugs in their code be reported to them but that bugs specific to Fedora (packaging bugs, ...) not be forwarded to them.
Note also that bugzilla.redhat.com is the upstream for several packages in Fedora so this will not make us move away from it.
- More often than not downstream maintainer as in packager does not
Jóhann, can you supply the dataset that you used to deduce that "More often than not"?
know the code at all so filling the bug downstream makes no sense.
This is the real problem and you should fix it instead of implementing hacky workarounds like this proposal.
Emmanuel
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.
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
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?
infrastructure@lists.fedoraproject.org
-
Anshu Prateek -
Bill Nottingham -
Christopher Meng -
Dennis Gilmore -
Emmanuel Seyman -
inode0 -
Jeff Sheltren -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Matthew Miller -
Miroslav Suchý -
Pierre-Yves Chibon -
Stephen John Smoogen -
T.C. Hollingsworth -
Tristan Santore