Bugzilla:Roadmap: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
== Bugzilla Roadmap ==
= Bugzilla Roadmap =
=== Introduction ===
The trunk is open for development for ~6 months, meaning that we accept bug fixes, enhancements, new features and risky code changes during this time. But 6 months is a ''short'' period and if we want something to be done on time when we freeze for the next release, some coordination is required.


The roadmap below is an attempt to outline what the objectives of the core Bugzilla team are for the next release. We will probably be late and we are probably too optimistic, but this gives enough work to everyone who wants to contribute.
== legend ==


A very important note is that both the User Interface (UI) and the code need some cleanup, and so even if you are not familiar with Bugzilla in general or with Perl in particular, there is still enough work for you here.
* [p1] Most Important
* [p4] Least Important


=== So why this roadmap? ===
== API ==
Well, to quickly summarize the main reasons, we could say:
* There is nothing more frustrating than working on a patch which will get no attention and will remain in the review queue for months, if not for years. Having clear objectives about what we want in the coming months will permit us to avoid such unfortunate situations. If we want something, we won't let it languish in the queue for months.
* Everyone is busy, but everyone wants to see things being done, and preferably as quickly as possible. Having clear objectives will make our work more efficient, as we know where the few free hours we have for writing patches will be most useful. This follows closely from the previous point, and we mention it here because we want to use our precious free time efficiently.
* Having deadlines and assigned developers will also offer a better coordination between developers. Working on some fields which conflict with someone else's work is again a waste of time, and having to unbitrot patches may take as long as writing the patch for the first time. Also, having an assigned developer per field should help in getting the work done, especially if this developer is a reviewer too. Indeed, ''assigned'' doesn't mean that he has to do the job alone, but that he is the person to contact when someone is interested in helping. He should also be able to say what work remains in the area of responsibility, and how far we are along in the process.


== The Roadmap ==
* [p2] rest redesign
=== Note ===
** redesign endpoints, drawing heavily from bzapi's design
This list is subject to change at any time, depending on progress we will made and on people working on the different fields.
** investigate using oauth with api-keys instead of user/pass


Latest news and summaries of [[Bugzilla:Meetings | Bugzilla meetings]] are also available. That is also the place where you can add your own suggestions to be discussed at our next meeting(s).
== UI/UX ==


You can also look at the old [[Bugzilla:Roadmap_3.0 | roadmap for Bugzilla 3.0]] and the [[Bugzilla:Roadmap_3.2 | roadmap for Bugzilla 3.2]].
* [p3] responsive design
** tables for layout --> divs
** show_bug only
* [p3] user roles / show_bug alternatives
** required: responsive design
** initially javascript to hide/show selected fields
* [p3] migrate from yui2 to yui3 or jquery
** propose splitting the bug and work:
*** a line-for-line yui2 --> yui3 migration
*** then change to more modern js (csp, etc)
* [p4] show/edit mode
** requires: responsive design
** default to show
** hide fields without values set
** edit to show all fields
* [p4] markdown support
** requires custom markdown library
** limited markdown code only (no html, no image embedding)
** glob has a functional POC
* migrate sandstone skin upstream, make default
** split to match upstream css assets
** replace mozilla branding
** license?
** retain skin specific header and footer, or rework all skins to use sandstone's html?


=== Our priorities ===
== Performance ==
Here is what you were waiting for: the roadmap for Bugzilla 3.4 and beyond. Tasks reported in the table are not ordered by priority as some of them may be relatively independent. The first Bugzilla version which has the corresponding features implemented is also indicated.


{| class="fullwidth-table" border="1" cellpadding="10" cellspacing="0"
* [p1] memcached
!Task
* [p1] api throttling
!Related bugs
** required: memcache
!Fully implemented on
** cache REST requests with memcache
!Assigned developer(s)
** prevent too-frequent polling with identical requests, and accidental DDOS
!Requirements
** a 5 minute cache of duplicate bzapi requests would have a 25% hit rate
|-
** [p2] new relic integration
! colspan="5" | Bugzilla 3.4
* build standard system for logging
|-
** currently just write to apache's error log, access via syslog
| <span id="timezone">Allow users to choose what time zone to display times in</span>
** need to log all api calls, which aren't currently visible (POSTs)
| <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=182238 Bug&nbsp;182238]</strike>
** log to database table, in background process?
| August 26, 2008
* [p4] explore consolidation of stylesheets at checksetup time, minimising javascript
| LpSolit
** requires an "is development" setting in localconfig
| none
 
|-
== Push BMO Customisations into Upstream Bugzilla ==
| <span id="webservices">Implement Bug.search() for WebServices</span>
* [p1] inline history
| <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=398281 Bug&nbsp;398281]</strike>
* [p1] component watching
| January 22, 2009
* [p2] securemail
| mkanat
* [p2] user activity report
| none
** needs a webservice endpoint
|-
* [p2] patchreader
| <span id="custom">Ability to restrict custom fields to products (like flags)</span>
** uninit warnings need to be resolved first
| <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=371995 Bug&nbsp;371995]</strike>
* [p3] profile.creation_ts
| February 8, 2009
* [p3] administration reports and tools
| mkanat
* [p4] migrate tools from command line scripts to cgi
| none
** create an "admin's toolbox"?
|-
* [p4] project honeypot integration
| <span id="enter_bug">Improvements for enter_bug's UI</span>
* [p4] anti-spam
| <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=376673 Bug&nbsp;376673]</strike>
 
| February 11, 2009
== Community Engagement / Ecosystem ==
| mkanat
* focus on documentation
| none
* identify a point of contact for new contributors (mentors)
|-
* reach out to known contributors
! colspan="5" | Bugzilla 3.6
* clearly set expectations (code review times, etc)
|-
* regular meetings with agendas and summaries
| <span id="set_flag">Implement $bug->set_flags() and $attachment->set_flags()</span>
* code review guidelines, especially with regards to new contributors
| <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=415541 Bug&nbsp;415541]</strike>
* extensions and dashboards database
| August 5, 2009
** proper database app, with filters etc
| LpSolit
* investigate migrating off mod_perl to fastcgi
| none
** revisit plack
|-
* documentation
! colspan="5" | Bugzilla 4.0
** separation of documentation into target audiences (user guide, admin/install guide, hacking guide, api consumer guide)
|-
** hosting of both upstream and site specific docs
| <span id="query">Simplify the query.cgi UI</span>
 
| <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=450301 Bug&nbsp;450301]</strike>
 
| June 6, 2010
You can also look at the old roadmaps for Bugzilla [[Bugzilla:Roadmap_3.0|3.0]], [[Bugzilla:Roadmap_3.2|3.2]], and [[Bugzilla:Roadmap_4.2|4.2]].
| pyrzak
| none
|-
| <span id="bug.pm">Use Bug.pm to write changes and new bugs to the database</span>
| <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=122922 Bug&nbsp;122922]</strike> <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=418342 Bug&nbsp;418342]</strike>
| June 18, 2010
| mkanat
| <strike>Implement $bug->set_flag() and $attachment->set_flag()</strike>
|-
| <span id="ws-bugupdate">Bug.update support in WebServices</span>
| <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=415813 Bug&nbsp;415813]</strike>
| July 12, 2010
| mkanat, dkl
| <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=418342 Bugzilla::Bug::set_all]</strike>
|-
! colspan="5" | Bugzilla 4.2
|-
| <span id="search.pm">Search.pm should not depend on the CGI</span>
| <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=398308 Bug&nbsp;398308]</strike>
| July 15, 2010
| mkanat
| none
|-
| <span id="retire">Retire old versions, components and milestones</span>
| <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=77193 Bug&nbsp;77193]</strike>
| August 30, 2010
| dkl
| none
|-
! colspan="5" | Bugzilla 4.next
|-
| <span id="object.pm">Most Bugzilla modules should use Object.pm</span>
| [https://bugzilla.mozilla.org/show_bug.cgi?id=355838 Bug&nbsp;355838] [https://bugzilla.mozilla.org/show_bug.cgi?id=297791 Bug&nbsp;297791]
| ---
| LpSolit, mkanat
| <strike>[[#bug.pm|Use Bug.pm to write changes and new bugs to the database]]</strike>
|-
| <span id="webservices">Improvements to WebServices</span>
| [https://bugzilla.mozilla.org/show_bug.cgi?id=278032 Bug&nbsp;278032]
| ---
| Noura
| [[#object.pm|Most Bugzilla modules should use Object.pm]]
|-
| <span id="branches">Bugzilla needs to deal better with branches</span>
| [https://bugzilla.mozilla.org/show_bug.cgi?id=55970 Bug&nbsp;55970]
| ---
| mkanat
| none
|-
| <span id="hci">Improve Bugzilla usability</span>
| [https://bugzilla.mozilla.org/show_bug.cgi?id=490786 Bug&nbsp;490786]
| ---
| ---
| none
|-
| <span id="mssql">MS-SQL Support</span>
| [https://bugzilla.mozilla.org/show_bug.cgi?id=285122 Bug&nbsp;285122]
| ---
| mockodin
| none
|-
| <span id="inter-bugzilla">Inter-Bugzilla Integration Capabilities</span>
| [https://bugzilla.mozilla.org/show_bug.cgi?id=123130 Bug&nbsp;123130]<br> [https://bugzilla.mozilla.org/show_bug.cgi?id=134294 Bug&nbsp;134294]
| ---
| alexeiser, dkl
| <strike>[[#bug.pm|Use Bug.pm to write changes and new bugs to the database]]</strike><br>[[#webservices|Improvements to WebServices]]
|-
| <span id="index.cgi">Make Bugzilla's index.cgi (home page) useful for logged-in users</span>
| [https://bugzilla.mozilla.org/show_bug.cgi?id=130835 Bug&nbsp;130835]
| ---
| pyrzak
| none
|-
| <span id="openid">Support OpenID as a an account source and login verification method</span>
| [https://bugzilla.mozilla.org/show_bug.cgi?id=294608 Bug&nbsp;294608]
| ---
| dwm
| none
|-
| <span id="tokens">Use tokens to authenticate email senders</span>
| [https://bugzilla.mozilla.org/show_bug.cgi?id=419203 Bug&nbsp;419203]
| ---
| LpSolit
| none
|-
| <span id="bugmail">Refactor Bugzilla::Bugmail into real objects</span>
| [https://bugzilla.mozilla.org/show_bug.cgi?id=301447 Bug&nbsp;301447]
| ---
| manu
| none
|-
| <span id="defaults">Ability to specify defaults for custom fields</span>
| [https://bugzilla.mozilla.org/show_bug.cgi?id=351899 Bug&nbsp;351899]
| ---
| mkanat
| none
|}


[[category:Bugzilla|R]]
[[category:Bugzilla|R]]

Revision as of 02:14, 22 April 2014

Bugzilla Roadmap

legend

  • [p1] Most Important
  • [p4] Least Important

API

  • [p2] rest redesign
    • redesign endpoints, drawing heavily from bzapi's design
    • investigate using oauth with api-keys instead of user/pass

UI/UX

  • [p3] responsive design
    • tables for layout --> divs
    • show_bug only
  • [p3] user roles / show_bug alternatives
    • required: responsive design
    • initially javascript to hide/show selected fields
  • [p3] migrate from yui2 to yui3 or jquery
    • propose splitting the bug and work:
      • a line-for-line yui2 --> yui3 migration
      • then change to more modern js (csp, etc)
  • [p4] show/edit mode
    • requires: responsive design
    • default to show
    • hide fields without values set
    • edit to show all fields
  • [p4] markdown support
    • requires custom markdown library
    • limited markdown code only (no html, no image embedding)
    • glob has a functional POC
  • migrate sandstone skin upstream, make default
    • split to match upstream css assets
    • replace mozilla branding
    • license?
    • retain skin specific header and footer, or rework all skins to use sandstone's html?

Performance

  • [p1] memcached
  • [p1] api throttling
    • required: memcache
    • cache REST requests with memcache
    • prevent too-frequent polling with identical requests, and accidental DDOS
    • a 5 minute cache of duplicate bzapi requests would have a 25% hit rate
    • [p2] new relic integration
  • build standard system for logging
    • currently just write to apache's error log, access via syslog
    • need to log all api calls, which aren't currently visible (POSTs)
    • log to database table, in background process?
  • [p4] explore consolidation of stylesheets at checksetup time, minimising javascript
    • requires an "is development" setting in localconfig

Push BMO Customisations into Upstream Bugzilla

  • [p1] inline history
  • [p1] component watching
  • [p2] securemail
  • [p2] user activity report
    • needs a webservice endpoint
  • [p2] patchreader
    • uninit warnings need to be resolved first
  • [p3] profile.creation_ts
  • [p3] administration reports and tools
  • [p4] migrate tools from command line scripts to cgi
    • create an "admin's toolbox"?
  • [p4] project honeypot integration
  • [p4] anti-spam

Community Engagement / Ecosystem

  • focus on documentation
  • identify a point of contact for new contributors (mentors)
  • reach out to known contributors
  • clearly set expectations (code review times, etc)
  • regular meetings with agendas and summaries
  • code review guidelines, especially with regards to new contributors
  • extensions and dashboards database
    • proper database app, with filters etc
  • investigate migrating off mod_perl to fastcgi
    • revisit plack
  • documentation
    • separation of documentation into target audiences (user guide, admin/install guide, hacking guide, api consumer guide)
    • hosting of both upstream and site specific docs


You can also look at the old roadmaps for Bugzilla 3.0, 3.2, and 4.2.

Retrieved from "https://wiki.allizom.org/index.php?title=Bugzilla:Roadmap&oldid=967253"