Migrating to our own bugzilla instance.

Pierre-Yves Chibon pingou at pingoured.fr
Tue Sep 17 11:54:51 UTC 2013


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


More information about the infrastructure mailing list