New bugzilla.org website!

As mentioned the other day, in my previous post, the mozilla.org website got redone again the other day, just a few weeks after we updated bugzilla.org to match their previous look and feel.

Well Mike Morgan has done it again, and updated bugzilla.org to match.

4 Replies to “New bugzilla.org website!”

  1. I see a Bugzilla Countdown that says:
    7 days until 2.20 Feature Freeze
    What this means?
    There are only 7 days to add new features
    to 2.20 of Bugzilla?

    In company where I’m working
    I extended Bugzilla 2.18rc1 and 2.18rc2
    in order to be able to associate Milestones
    and/or Versions to components (and not only
    to products).

    We already used successfully this new feature.

    My idea was to wait 2.18 final (when it will be ready?)
    and then I will port my changes from 2.18rc2
    to 2.18 final and I will be able to pushish them
    to Mozilla org.

    I think that this new feature will be great
    also for other people…

    The Countdown previous mentioned (7 days
    to 2.20) means that I have only 7 days
    to publish my work?

  2. 2.18 already had its feature freeze back in March. It’s taken so long to get a final version released because it’s been so long since 2.16 was released and there was a lot of time for things to slip in that needed to be cleaned up.

    2.20 is scheduled to freeze on September 15. 2.18 final won’t be out by then, which makes things really weird, but that’s how it worked out. 🙂 There is a bunch of major new stuff in 2.19/2.20 already that’s not in 2.18.

    The 2.18 branch will be around and supported for at least a year (possibly a year and a half – that hasn’t been worked out for sure yet).

    If you have major stuff based on it that you wanted to get landed upstream, that ran out last March if you wanted it in 2.18. 🙂 If you want it in 2.20, that runs out on the 15th this month. If you want it in 2.22, you have about 6 months 🙂

    1. I customized Bugzilla 2.18rc2 for my company needs.
      We made a lot of changes:
      – Milestones/Versions associated both to components and products
      – Target Version associated to each bug
      – Many other…

      The first mentioned change (Mil/Vers associated to Prod/Comp)
      is the biggest one: It takes me 8 working days
      to change the Perl code and to test everything
      before releasing my work to my colleagues.
      Not a single bug was then found on this change
      from my colleagues in the next 30 days of use.

      Now I have a 2.18rc2 source code with embedded
      many changes for all the new features we add to Bugzilla.

      I will wait the 2.18 final to move all my changes to 2.18 final.
      After that (i.e. after I have a 2.18 modified
      with all our new features well working on 2.18 final)
      I will be able to extract only the source code related
      to "Mil/Vers associated to Prod/Comp"
      and to publish it to mozilla.org (if someone want
      to use it).

      I think that this will happen 20-30 days
      after the 2.18 final release date.

      Probably at that time my best option to publish
      my work is just to enter an enhancement
      to bugzilla tracking system <http://bugzilla.mozilla.org&gt;
      and attach the source code to it.

      Is this the right way to do?

      1. Yep, that is correct. I think there may already be a bug for that particular idea though… if you can hunt it down, add your patch to the existing bug. If you can’t find it, go ahead and make a new one.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.