Migrating to our own bugzilla instance.

[Jóhann B. Guðmundsson]

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

[Pierre-Yves Chibon]

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

[Tristan Santore]

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(a)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

-- 

Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile [phone]
Tristan.Santore(a)internexusconnect.net

Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)

For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org

[Jóhann B. Guðmundsson]

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

[Pierre-Yves Chibon]

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

[Anshu Prateek]

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...





On Tue, Sep 17, 2013 at 4:07 PM, "Jóhann B. Guðmundsson" <johannbg(a)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_tracker<h...
> >
>
>  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.org&lt;infrastructure(a)lists.fedoraproject.org&gt;
>
> https://admin.fedoraproject.**org/mailman/listinfo/**infrastructure<ht...
>

[Christopher Meng]

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?

[Jóhann B. Guðmundsson]

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

[Miroslav Suchý]

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

[Jeff Sheltren]

On Tue, Sep 17, 2013 at 7:37 AM, "Jóhann B. Guðmundsson" <johannbg(a)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

[Jóhann B. Guðmundsson]

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

[inode0]

On Wed, Sep 18, 2013 at 9:27 AM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com&gt; 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

[Jóhann B. Guðmundsson]

On 09/18/2013 02:36 PM, inode0 wrote:
>  On Wed, Sep 18, 2013 at 9:27 AM, "Jóhann B. Guðmundsson"
>  <johannbg(a)gmail.com&gt; 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

[Kevin Fenzi]

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

[Jóhann B. Guðmundsson]

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

[Stephen John Smoogen]

On 18 September 2013 11:45, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com&gt;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.

[Jóhann B. Guðmundsson]

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

[Emmanuel Seyman]

* "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

[Jóhann B. Guðmundsson]

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

[Emmanuel Seyman]

* "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

[Jóhann B. Guðmundsson]

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

[Emmanuel Seyman]

* "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

[Jóhann B. Guðmundsson]

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

[T.C. Hollingsworth]

On Wed, Sep 18, 2013 at 3:05 PM, Emmanuel Seyman <emmanuel(a)seyman.fr&gt; 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.

[Jóhann B. Guðmundsson]

On 09/18/2013 10:41 PM, T.C. Hollingsworth wrote:
>  On Wed, Sep 18, 2013 at 3:05 PM, Emmanuel Seyman
> <emmanuel(a)seyman.fr&gt; 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

[Kevin Fenzi]

On Wed, 18 Sep 2013 17:45:01 +0000
"Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; 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

[Jóhann B. Guðmundsson]

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

[Bill Nottingham]

"Jóhann B. Guðmundsson" (johannbg(a)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

[Jóhann B. Guðmundsson]

On 09/18/2013 04:14 PM, Bill Nottingham wrote:
>  "Jóhann B. Guðmundsson" (johannbg(a)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

[Bill Nottingham]

(getting far afield of bugzilla)

"Jóhann B. Guðmundsson" (johannbg(a)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

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Wed, 18 Sep 2013 16:41:56 +0000
"Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; escribió:
>  On 09/18/2013 04:14 PM, Bill Nottingham wrote:
>  > "Jóhann B. Guðmundsson" (johannbg(a)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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.21 (GNU/Linux)
>
> iEYEARECAAYFAlI8n7QACgkQkSxm47BaWfdEbQCdHiCrLLdTHlUu0g2TCbdkCV9e
> 5bkAn2bAbiGb4bay6GUKOUiYp02q1B90
> =bKOg
> -----END PGP SIGNATURE-----
>

[Jóhann B. Guðmundsson]

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

[Tristan Santore]

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.
>  
>  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
>  
>  _______________________________________________
>  infrastructure mailing list
>  infrastructure(a)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


-- 

Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile [phone]
Tristan.Santore(a)internexusconnect.net

Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)

For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org

[Jóhann B. Guðmundsson]

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

[Kevin Fenzi]

On Mon, 23 Sep 2013 22:51:55 +0000
"Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; 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

[Dennis Gilmore]

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(a)scrye.com&gt; wrote:
> On Mon, 23 Sep 2013 22:51:55 +0000
> "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; 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(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Jóhann B. Guðmundsson]

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

[Kevin Fenzi]

On Mon, 23 Sep 2013 21:36:51 +0000
"Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; 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" ? 

>  1. 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. 

>  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. 
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

[Matthew Miller]

On Mon, Sep 23, 2013 at 09:36:51PM +0000, "Jóhann B. Guðmundsson" wrote:
>  1. 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.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Emmanuel Seyman]

* "Jóhann B. Guðmundsson" [23/09/2013 21:36] :
>  1. 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.

>  2. 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

[Miroslav Suchý]

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

[Jóhann B. Guðmundsson]

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

[Miroslav Suchý]

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