Bug 584948 - 3.8, 3.9, 3.10: Source repository integration
3.8, 3.9, 3.10: Source repository integration
Status: CLOSED CURRENTRELEASE
Product: Bugzilla
Classification: Community
Component: Creating/Changing Bugs (Show other bugs)
3.6
All Linux
low Severity medium (vote)
: ---
: ---
Assigned To: Simon Green
Lukáš Petrovický
contractor
:
Depends On:
Blocks: JIRABZ 725872
  Show dependency treegraph
 
Reported: 2010-04-22 15:07 EDT by David Lawrence
Modified: 2014-10-12 18:46 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-20 00:26:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Lawrence 2010-04-22 15:07:22 EDT
JIRA Requirements: 3.8, 3.9, 3.10 

The JIRA development team use a third party plugin for JIRA that allows integration with their SCM repository. The plugin called Fisheye (http://www.atlassian.com/software/fisheye/) requires
access to the SCM itself to allow linking of patches, viewing of source code changes, etc. Currently our infrastructure is not setup to allow access to our CVS/SVN/Git repositories used
for RHEL development. 

Release Engineering does have some hooks/triggers in place that do certain changes to bug reports if it sees a properly formatted bug id in the commit message. We also have
several web front ends to the SCM repos that allow viewing of the source code, commits, and patch diffs.

From further investigation, Fisheye does have a REST API so it seems it may be possible to search for committed patch sets that contain a Bugzilla ID and display details about those patches
in the Bugzilla bug view. Will need to see how much more above this that the JIRA guys would need.

Possible Solution(s):

 * Create an extension for Bugzilla that gives similar functionality to the JIRA Fisheye plugin and displays source code information along side the bug report when the bug is linked to sections of code or patches via bug ids inserted into the commit messages. This would require that Bugzilla have some or all access to the Fisheye server to obtain the data that it needs.
 * Update the hooks/triggers to send more data to Bugzilla to store in a table or two so that Bugzilla can display the information needed without having to have direct access to the SCM repositories of Fisheye server. Data would be duplicted and redundant possibly.
 * Update the hooks/triggers to send links to the relevant web front ends internally instead and have those links display in bug comments or special reference bug fields created for that purpose. Then a user can simply click on the link to go to the proper page in the SCM's web front end.
 * Possibility of using SCMBug or other available Bugzilla extensions.
Comment 1 Max Kanat-Alexander 2010-05-26 17:43:23 EDT
  Okay, I don't understand what the actual requirement is, here. What are the actual specific, exact things that the JIRA-using development team *require* Fisheye for? How are they using it currently, and what is the minimal functionality required for them to migrate to Bugzilla and maintain their development processes effectively?
Comment 2 David Lawrence 2010-05-27 17:31:13 EDT
One simple usage case is that when people commit changes to the SVN repo they use which contain references to specific JIRA issues in the commit log, JIRA has a way to show a table of commits in the actual issue that match. JIRA uses a plugin that accesses a Fisheye API to get the commit information. Fisheye from what I can tell is similar to loggerhead, cvsview, etc. but exports an API (REST and XMLRPC) that allows for searching and retrieving information.

Here is the link to the Fisheye product:
http://www.atlassian.com/software/fisheye/tour/

And more details about the JIRA->Fisheye plugin:
https://studio.plugins.atlassian.com/wiki/display/FISH/JIRA+FishEye+Plugin

As you can see it adds a new tab to the JIRA issue display that lists the changesets committed that matches the JIRA issue id. They are separated by individual changesets and show each file affected and the commit log text.

They can then click through to the Fisheye serve itself for more information or to perform other actions.

Here is a link to the REST/XMLRPC API documentation for Fisheye.

From what I can tell from our meetings with the JIRA folks, the information displayed in the tab would be sufficient for now to get them going. 

A good example of a JBoss issue:

https://jira.jboss.org/browse/SOA-1255 (click on the Subversion Commits tab).
https://jira.jboss.org/browse/JBPAPP-4359

Dave
Comment 3 Max Kanat-Alexander 2010-05-27 19:00:02 EDT
Okay, sure. So all we'd have to do is look for commits that contain the phrase "bug 12345" in them and link them to the bug, displaying info about the commits? Easy enough.

VCI (a CPAN module that I wrote) can read any modern, popular open-source VCS and get that information.

Would they retain fisheye, and we would just link to that, as the repository browser? (For linking the commit ID and the file names.)

To link the commits to the bugs, we'd probably just add an SVN hook written in Perl that called a custom Bugzilla RPC function. The RPC function would just take a commit id, and parse the commit message for Bug IDs to add it to, and then attempt to map the SVN user to a particular Bugzilla user, falling back to a default user if the mapping failed. I assume that Subversion user names mostly map back exactly to Bugzilla user accounts (email addresses)?

It looks like we will also need to retain a mapping table of JIRA Bug IDs to Bugzilla Bug IDs, in order to be able to link old JIRA-tagged commits to Bugzilla bugs.
Comment 4 Max Kanat-Alexander 2010-05-27 19:02:01 EDT
  Even simpler would be just having a list of commit IDs and linking them directly to Fisheye or whatever repository browser they wanted. That would skip us having to write the VCI code, for the most part, or display info about the commit itself in Bugzilla. However, if they want the info about the commit in Bugzilla itself, it would certainly be fun to write (though considerably more work, since we have to have a new UI, and so on).
Comment 5 David Lawrence 2010-06-01 17:06:51 EDT
(In reply to comment #4)
>   Even simpler would be just having a list of commit IDs and linking them
> directly to Fisheye or whatever repository browser they wanted. That would skip
> us having to write the VCI code, for the most part, or display info about the
> commit itself in Bugzilla. However, if they want the info about the commit in
> Bugzilla itself, it would certainly be fun to write (though considerably more
> work, since we have to have a new UI, and so on).    

Currently I am not sure how it is being stored in the JIRA system except of some mention that the SVN commits are being indexed in the background by searching the SVN repo directly for JIRA issue ids and/or the searching the Fisheye viewer for the same. According to the docs, it does it once an hour or so and then stores some meta data locally in a cache on the filesystem. Then the "Subversion Commits" tab reads the data for the current JIRA id and displays the recent changeset info.

We could either do one of the following:

1. Have some SVN hooks as you mentioned that parse out bug ids from the SVN commit messages and sends some data to Bugzilla to be stored in a table for viewing from show_bug.cgi 

2. Have Bugzilla periodically check Fisheye for any changesets mentioning bug id's for all JIRA bugs and store the data in a Bugzilla table for viewing inside show_bug.cgi

3. Have show_bug.cgi query Fisheye in realtime when the bug is displayed rendering a table showing the changeset info.

Option 1 sounds more feasible as due to infrastructure challenges, number 2 and 3 may take some more effort or may not be possible at all. The SVN repos are internally located inside the firewall and not accessible directly by Bugzilla. The Fisheye server is located in the colocation facility where Bugzilla is located so could be easier to get to with some networking config changes. But Number 3 could be slow and would need to be done in such a way to not hamper the display of the show_bug.cgi page. Number 2 could be slow as well and add extra load to the server as it 
would need to go through all bugs one at a time querying Fisheye and then do it all over again after a certain amount of time.
Comment 6 David Lawrence 2010-06-01 17:12:44 EDT
(In reply to comment #3)
> Okay, sure. So all we'd have to do is look for commits that contain the phrase
> "bug 12345" in them and link them to the bug, displaying info about the
> commits? Easy enough.
> 
> VCI (a CPAN module that I wrote) can read any modern, popular open-source VCS
> and get that information.
> 
> Would they retain fisheye, and we would just link to that, as the repository
> browser? (For linking the commit ID and the file names.)

Yes, we could take some path information stored in the Bugzilla table, and prepend the fisheye server address to it allowing linking to the changeset in fisheye from Bugzilla.

> To link the commits to the bugs, we'd probably just add an SVN hook written in
> Perl that called a custom Bugzilla RPC function. The RPC function would just
> take a commit id, and parse the commit message for Bug IDs to add it to, and
> then attempt to map the SVN user to a particular Bugzilla user, falling back to
> a default user if the mapping failed. I assume that Subversion user names
> mostly map back exactly to Bugzilla user accounts (email addresses)?

Not necessarily mapped. We use kerberos based auth internally for internal services such as SVN, email, etc. Bugzilla is using the their email address as a login and doesn't always map to their kerb id + @redhat.com. May have to just a take
a simple approach initially and just store the kerb id in a plain text field for display in show_bug.cgi. We could eventually set up something internally that pushes kerb ids to Bugzilla and stores them in the extern_id field.

> It looks like we will also need to retain a mapping table of JIRA Bug IDs to
> Bugzilla Bug IDs, in order to be able to link old JIRA-tagged commits to
> Bugzilla bugs.    

FWIW, during the migration when an issue is moved to Bugzilla, I am putting the old JIRA id in the alias field of the bug. The JIRA id being in the form of KEY-ID such as JBIDE-2047. I believe that is what they have been putting in their commit messages and is the standard way of referencing an issue.
Comment 7 Max Kanat-Alexander 2010-06-01 17:50:28 EDT
Okay, cool on the aliases, that will work.

The reason I need a login name is that Bugzilla needs to store who is making the change, in bugs_activity. And if the integration is going to add a comment, the comment needs to come from somebody.

We could add a field in the profiles table (and in the Name and Account section of userprefs.cgi) for a user's kerb id, and they could fill it in themselves. Then, if we find a valid kerb user, we note that as the user who made the comment or added the change. Otherwise we use a generic account like "svn@redhat.com".

Alternately, you could change Bugzilla to login using LDAP,DB and then users would log in using their LDAP name and it would be stored in the extern_id field of the profiles table.

I agree that using the SVN hooks is the best idea.

What I want to know is if just displaying a list of commit IDs in Bugzilla is an acceptable UI. That is, that would be the only UI, and each commit ID would be a link back to Fisheye.
Comment 8 David Lawrence 2010-06-01 18:03:00 EDT
(In reply to comment #7)
> We could add a field in the profiles table (and in the Name and Account section
> of userprefs.cgi) for a user's kerb id, and they could fill it in themselves.
> Then, if we find a valid kerb user, we note that as the user who made the
> comment or added the change. Otherwise we use a generic account like
> "svn@redhat.com".

If we export a RPC method to update this field I can run something from inside the firewall to update these values. I will need to figure out how to find someone's Bugzilla email address to kerb mapping internally but we have some orgchart systems that may have that already.
 
> Alternately, you could change Bugzilla to login using LDAP,DB and then users
> would log in using their LDAP name and it would be stored in the extern_id
> field of the profiles table.

Would that need access to the LDAP/kerb server directly? If yes then no-go.
  
> What I want to know is if just displaying a list of commit IDs in Bugzilla is
> an acceptable UI. That is, that would be the only UI, and each commit ID would
> be a link back to Fisheye.    

They basically said to me they want to do similar activities from Bugzilla that they do now in JIRA so I have had to go by my own interpretation from looking at various sample JIRA issues.

From the requirements document we have:

 3.8 	 Source repository commits must be reflected in updates to the affected issues (by keyword in the commit message). Links to the commits must be added to the issue.

I can go back to the JIRA stake holders and ask for clarification.
Dave
Comment 9 Max Kanat-Alexander 2010-06-01 18:20:40 EDT
(In reply to comment #8)
> If we export a RPC method to update this field I can run something from inside
> the firewall to update these values. I will need to figure out how to find
> someone's Bugzilla email address to kerb mapping internally but we have some
> orgchart systems that may have that already.

  Okay. In that case, I suppose the method will have to simply be something like RedHat.add_commit_ids_to_bug or something.

> > Alternately, you could change Bugzilla to login using LDAP,DB and then users
> > would log in using their LDAP name and it would be stored in the extern_id
> > field of the profiles table.
> 
> Would that need access to the LDAP/kerb server directly? If yes then no-go.

  It would need access to the LDAP server. But it doesn't need that many attributes; you could perhaps mirror the LDAP server.

>  3.8   Source repository commits must be reflected in updates to the affected
> issues (by keyword in the commit message). Links to the commits must be added
> to the issue.
> 
> I can go back to the JIRA stake holders and ask for clarification.

  Okay. If that's the whole requirement, it sounds like we can just have links to Fisheye in Bugzilla. That's considerably less complex than implementing something like the JIRA FishEye plugin.
Comment 10 David Lawrence 2010-06-02 17:38:47 EDT
(In reply to comment #9)
> > > Alternately, you could change Bugzilla to login using LDAP,DB and then users
> > > would log in using their LDAP name and it would be stored in the extern_id
> > > field of the profiles table.
> > 
> > Would that need access to the LDAP/kerb server directly? If yes then no-go.
> 
>   It would need access to the LDAP server. But it doesn't need that many
> attributes; you could perhaps mirror the LDAP server.

Okay I can mirror the kerb ids into the profiles.extern_id field using a script attached to an internal ldap directory. I don't feel like we need to mirror the whole directory necessarily if we already have the kerb id and the Bugzilla login info unless I am missing some other necessary attribute.
 
> >  3.8   Source repository commits must be reflected in updates to the affected
> > issues (by keyword in the commit message). Links to the commits must be added
> > to the issue.
> > 
> > I can go back to the JIRA stake holders and ask for clarification.
> 
>   Okay. If that's the whole requirement, it sounds like we can just have links
> to Fisheye in Bugzilla. That's considerably less complex than implementing
> something like the JIRA FishEye plugin.    

I think at a minimum we will need 

Repo name
Commit id or revision number
Date
Author
Commit message
Files affected

Do you think just creating a single table to cache this info would be sufficient?

Dave
Comment 11 Max Kanat-Alexander 2010-06-07 11:42:57 EDT
  We could create a table, but *where in the UI* would all that information go? If it's going to go on a separate page, why not just link to a page in Fisheye with that same information?
Comment 12 David Lawrence 2010-06-08 15:52:23 EDT
Currently we have a 'table-data' hook in out edit.html.tmpl that displays the external bug references table below the attachments table. We could add another data table there except have it hidden by default. I would use some jscript to create an arrow that when clicked displays the full table. Otherwise it just shows some type of brief stats such as number of commits for this bug, etc.

Another option would be to have a separate view similar to show_activity.cgi that is another screen altogether. In JIRA the SVN commits are in a separate tab but we do not have tabbed views in show_bug.cgi yet. 

As for just having a link to fisheye, do you mean not cache the data at all and just have a link to a Fisheye query page that populates the bug id in the query? I think they want to actually know that commits have occurred from the looking at the show_bug.cgi page without having to go to Fisheye to find out first.

Or are you talking about still storing minimal commit data in Bugzilla's db and then show some simple stats with links to the actual commits in Fisheye?

Dave
Comment 13 Max Kanat-Alexander 2010-06-09 01:57:44 EDT
  What I'm talking about is this:

  Commits: 1234, 4567, 3245, 5436

  And then each of those numbers is a link to Fisheye. Perhaps also with a hover-over including the checkin mesage?
Comment 14 David Lawrence 2010-06-09 12:43:20 EDT
(In reply to comment #13)
>   What I'm talking about is this:
> 
>   Commits: 1234, 4567, 3245, 5436
> 
>   And then each of those numbers is a link to Fisheye. Perhaps also with a
> hover-over including the checkin mesage?    

I will need to also run this by the developers. In our preliminary discussions we just assumed when they wanted similar functionality that they would want to be able to view the same amount of detail in Bugzilla as they can do in JIRA. I admit that it would be cleaner to just show the commit id's and some simple message on mouseover. Let me see what they think.

Dave
Comment 15 David Lawrence 2010-06-14 17:32:09 EDT
I have asked some of the developers to come to this bug and comment to see if what we have discussed will be sufficient.
Comment 16 Max Kanat-Alexander 2010-06-19 02:15:21 EDT
Any response from the developers?
Comment 17 David Lawrence 2010-06-21 17:27:47 EDT
Sorry for the lack of response. People are busy these days I suppose. I am adding tkirby@redhat.com as well to this bug.

Trevor, you mentioned in the JIRA migration requirements table that fisheye integration was a high priority. Can you comment on what Max and I have discussed thus far and let us know if what is proposed will be sufficient.

Basically we are proposing placing triggers/hooks in the different SVN repositories and when a commit message contains a formatted bug id, send the commit data to a table in Bugzilla via XMLRPC. Then from the show_bug.cgi page
we can display the commit information and link it directly to the Fisheye
pages.

How is this sounding so far?

Dave
Comment 18 Max Kanat-Alexander 2010-06-21 17:42:24 EDT
tkirby: In particular, see comment 13.
Comment 19 trev 2010-06-23 11:26:23 EDT
(In reply to comment #18)
> tkirby: In particular, see comment 13.    

Max Anderson should also be included in this conversation. He's in Boston this week so you might not get his answers for a week.

Our use of fisheye is limited by the fact it is only available on jboss.org and not svn.devel.redhat.com where the SOA repo is. This means we can only use it for tracking dependant projects at the momentand not changes in the SOA build system.

The way we use fisheye on .org at the moment is to look at the code changes associated with a particular jira and more importantly which branches that change has ended up in.

From the above it implies that only the files affected will be recorded and not the actual diffs, also  we will not be able to see which other branches are affected.

As Max does not have the svn.devel.redhat.com restriction, he uses this functionality much more than we do so he will probably have extra use cases.

 Trev
Comment 20 Max Kanat-Alexander 2010-06-23 17:19:08 EDT
(In reply to comment #19)
> From the above it implies that only the files affected will be recorded and not
> the actual diffs, also  we will not be able to see which other branches are
> affected.

  Hey Trev. Actually, in the current plan, all that will be directly obvious in the UI will be the commit ids. Then you can hover over those commit ids to get more information, or click on them to go to Fisheye. As to what "more information" would be displayed on hover-over, we haven't decided.

  Instead of just the commit id, we could display some sort of branch identifier (perhaps the path to the branch) and then a commit id. Or, depending on how important that information is, we could just display it in the tooltip.

  The important thing for us is that we want to be sure that there's a clean UI implementation that doesn't interfere with projects that aren't using this feature, but that provides enough information for you guys to continue to operate your processes smoothly.
Comment 21 David Lawrence 2010-06-25 16:27:21 EDT
(In reply to comment #20)
> (In reply to comment #19)
> > From the above it implies that only the files affected will be recorded and not
> > the actual diffs, also  we will not be able to see which other branches are
> > affected.
> 

Trevor, I cannot tell by looking at several JIRA issues where the diffs are displayed in the issue itself without clicking on the link to direct you to the
fisheye server. So I would definitely rather not duplicate that much detail on the Bugzilla side and just let that information be displayed from Fisheye.

>   Hey Trev. Actually, in the current plan, all that will be directly obvious in
> the UI will be the commit ids. Then you can hover over those commit ids to get
> more information, or click on them to go to Fisheye. As to what "more
> information" would be displayed on hover-over, we haven't decided.

I think a minimum we would have the commit id, date, the repo, who, maybe an abbreviated commit message, and the file path.
 
>   Instead of just the commit id, we could display some sort of branch
> identifier (perhaps the path to the branch) and then a commit id. Or, depending
> on how important that information is, we could just display it in the tooltip.
>

Wouldn't the branch information be in the file path itself anyway?
 
>   The important thing for us is that we want to be sure that there's a clean UI
> implementation that doesn't interfere with projects that aren't using this
> feature, but that provides enough information for you guys to continue to
> operate your processes smoothly.    

Max, I think in this case we would just check in the template that if there are zero commits, then omit the entire block. That should keep this from affect any other products that are not using the functionality.

Dave
Comment 22 David Lawrence 2010-06-25 16:33:47 EDT
Oops, should have had Max Anderson earlier on the cc list so adding him now.

Max, can you please comment on what has been proposed so far and if we need to add more, please give us some usage cases on why more is needed.

Thanks
Dave
Comment 23 Max Andersen 2010-07-01 09:43:11 EDT
Sorry for late answer, but were busy in Boston at JBoss World.

A typical example of where we benefit greatly from the fisheye/svn integration is https://jira.jboss.org/browse/JBIDE-6468?page=com.atlassian.jirafisheyeplugin%3Afisheye-issuepanel#issue-tabs

I'm not sure why we actually have both a "Subversion Commits" and "Source" tab but it's definitely the "Source" tab that has the best/most concise information.

If you look at the above jira tab I can instantly see the following (without having to hover any mouse (useless on phones and other non-mouse devices anyway) nor click any links and wait even longer to know the answer):

1) Who did the commit (with a link back to his jira profile)

2) What changeset/revision number (with a link back to fisheye changeset page)

3) Which repo (with a link back to the fisheye repo)

4) How many files were changed (an absolute number)

5) Time for when it happened (one big minus in jira is the lack of proper timezone support, but it at least give an approximate date/time)

6) The commit message (any short named links to mentioned jira's are linked to the proper jira, other links also just works)

7) A list (which gets shortened when above 5 items and the last line says how many other changed files there are) showing the path to the changed files and a summary of the deltas. (with links to show the individual parts)

Now I guess you would like to know which information of these we use the most ?

1) Crucial to know who actually did it, since sometimes you need to follow up/review if it is someone new or not known in that code base.

2) The revision number is used to know what came before/after others, the link is though the important one to be able to see the actual changeset.

3) Secondary/non-crucial to know which repo assuming some of the other path info is going to show up.

4) Crucial information if we don't get something like #7 which gives another visual indicator of how "big" the change is/was.

5) Secondary/background info in most cases - can be viewed more precisly on fisheye. Nice to have.

6) Important since these often outline the actual changes in a short form or reason for why the commit were done in that specific branch.

7) This is the most important part to have access to since it gives visual indicaiton of big a changeset and you can see which parts of the SVN tree is touched (trunk, branch, workspace, etc.) It also gives direct access to the subparts of the relevant commits but assuming fisheye is not utterly slow to rrespond to the changeset link then just knowing the number of actual lines and svn locations would be enough.

The goal is to avoid having to go to another subsystem to know the basics of what changed, a revision number does not really provide any info - I would have to *always* click the link to get even the basic details.

A click and a long wait is really not acceptable when you are reviwing hundreds of bugs.
Comment 24 Max Kanat-Alexander 2010-07-01 13:15:45 EDT
  Thank you, this information is really helpful!

(In reply to comment #23)
> I'm not sure why we actually have both a "Subversion Commits" and "Source" tab
> but it's definitely the "Source" tab that has the best/most concise
> information.

  Okay. And you're reasonably certain that all the developers require the information from the Source tab instead of the Subversion Commits tab for efficient use of their workflow?

> If you look at the above jira tab I can instantly see the following (without
> having to hover any mouse (useless on phones and other non-mouse devices
> anyway) nor click any links and wait even longer to know the answer):

  That's a reasonable point about the hover, but Bugzilla is not very usable on a mobile device in any case. (There are clients for both the iPhone and Android, though.) Your point below about reviewing hundreds of bugs helps me understand why you don't want any additional delay, though.

  So, with all of the information you've provided, I have another idea for a UI.

  As you can see in Bugzilla, show_bug.cgi's fields essentially have two columns, right and left. We could put a "Commits:" item in the right column, that was a <ul> with items that look roughly like the following:

  * <a href="fisheye">12345</a> by <a mailto?>Some Dude</a> on 2010-05-04 12:51 PM PST

  Then you could click on it, and it would do some AJAX-y thing to show more info about the commit below the item, including the files changed and the commit message. We don't *have* to rely on Fisheye--I wrote a whole framework for Perl for interacting with version control systems, so we can use that or Fisheye, whatever is easiest.

  Would that work for you?
Comment 25 Max Andersen 2010-07-02 02:58:03 EDT
> (In reply to comment #23)
> > I'm not sure why we actually have both a "Subversion Commits" and "Source" tab
> > but it's definitely the "Source" tab that has the best/most concise
> > information.
> 
>   Okay. And you're reasonably certain that all the developers require the
> information from the Source tab instead of the Subversion Commits tab for
> efficient use of their workflow?

As far as I can see "Subversion" tab is a subset of what is in "Source".
 
> > If you look at the above jira tab I can instantly see the following (without
> > having to hover any mouse (useless on phones and other non-mouse devices
> > anyway) nor click any links and wait even longer to know the answer):
> 
>   That's a reasonable point about the hover, but Bugzilla is not very usable on
> a mobile device in any case. (There are clients for both the iPhone and
> Android, though.) 

What clients are that (iphone in particular) ? All those I could find were extremely limited and seemed to only expose a subset of the info on the bugzilla's I tried to view.

Any new things we add here I don't expect them to be able to see or ?

> Your point below about reviewing hundreds of bugs helps me
> understand why you don't want any additional delay, though.

:)

>   So, with all of the information you've provided, I have another idea for a
> UI.
> 
>   As you can see in Bugzilla, show_bug.cgi's fields essentially have two
> columns, right and left. We could put a "Commits:" item in the right column,
> that was a <ul> with items that look roughly like the following:
> 
>   * <a href="fisheye">12345</a> by <a mailto?>Some Dude</a> on 2010-05-04 12:51
> PM PST
> 
>   Then you could click on it, and it would do some AJAX-y thing to show more
> info about the commit below the item, including the files changed and the
> commit message. We don't *have* to rely on Fisheye--I wrote a whole framework
> for Perl for interacting with version control systems, so we can use that or
> Fisheye, whatever is easiest.
> 
>   Would that work for you?    

From your description this sounds ok, the only concern is the loss of "linkability", i.e. I can link to the specific tabs in jira to share info with others.

Could that be accomodated somehow ?
Comment 26 Max Kanat-Alexander 2010-07-02 16:47:37 EDT
(In reply to comment #25)
> What clients are that (iphone in particular) ? All those I could find were
> extremely limited and seemed to only expose a subset of the info on the
> bugzilla's I tried to view.

  Hmm, really? I haven't actually used any of them--I generally like to dogfood Bugzilla's own interfaces as much as possible. But I think a search on "Bugzilla" in the app store shows up all three of them. (I seem to recall there are three.)

> Any new things we add here I don't expect them to be able to see or ?

  Yeah, Red Hat's Bugzilla is pretty extensively customized.

> From your description this sounds ok, the only concern is the loss of
> "linkability", i.e. I can link to the specific tabs in jira to share info with
> others.
> 
> Could that be accomodated somehow ?    

  Well, it will just be on show_bug.cgi (this page we're looking at now). We could put an anchor above the Commits field, though, if you want, so you could focus people's attention specifically on it.
Comment 27 Max Kanat-Alexander 2010-08-20 09:07:57 EDT
Is it critically important to show the number of lines changed in each file, in the Bugzilla UI? I could make certain parts of the extension a hundred times faster if I didn't have to do that.
Comment 28 David Lawrence 2010-08-20 12:07:25 EDT
(In reply to comment #27)
> Is it critically important to show the number of lines changed in each file, in
> the Bugzilla UI? I could make certain parts of the extension a hundred times
> faster if I didn't have to do that.

Max (Andersen), would you be able to answer this question please?

Dave
Comment 29 Max Rydahl Andersen 2010-09-16 07:08:31 EDT
(In reply to comment #28)
> (In reply to comment #27)
> > Is it critically important to show the number of lines changed in each file, in
> > the Bugzilla UI? I could make certain parts of the extension a hundred times
> > faster if I didn't have to do that.
> 
> Max (Andersen), would you be able to answer this question please?
> 
> Dave

Sorry been on vacation.

My first hunch is yes, its important to know the size of the change but
is it possible to get a screenshot of what is there now or try it out ?
Comment 31 Simon Green 2011-02-23 07:58:43 EST
The svn logs show changes relating to this bug was committed on October 4th 2010. Are the required changes implemented, or does some more work need to be done?

  -- simon
Comment 32 Mike Harvey 2011-03-09 08:43:24 EST
This bz cannot be tested yet, so I'm moving it back to ON_DEV.
<sgreen_wfh> Short answer: No. Eng-ops have a ticket to discuss the security issues of this. Work won't be done on it until they have responded.
Comment 37 Simon Green 2011-04-04 21:29:43 EDT
Okay. Things are a lot clearer now thanks to ggillies, jfearn and aj.

Currently fisheye gets its information from the SCMs (which is why rel-eng could not find a script).

The only thing I need is (at this stage) is confirmation that all commits that need to be logged are done in Red Hat subversion (svn) and Red Hat git servers.
Comment 41 Max Rydahl Andersen 2011-04-06 18:29:22 EDT
(In reply to comment #37)
> Okay. Things are a lot clearer now thanks to ggillies, jfearn and aj.
> 
> Currently fisheye gets its information from the SCMs (which is why rel-eng
> could not find a script).
> 
> The only thing I need is (at this stage) is confirmation that all commits that
> need to be logged are done in Red Hat subversion (svn) and Red Hat git servers.

If this means that its all on the vpn only svn and git servers then that is not the case at all.

it's mostly on svn.jboss.org; SOA being on the vpn svn is an exception.
Comment 45 Lukáš Petrovický 2011-05-11 02:47:03 EDT
Does this still work? After following comment 44 instructions, I get this:

[lpetrovi@steam svnrepo]$ svn commit -m "Bug 713079 - testing commit to verify Bug 584948"
root@dell-pe1950-1.rhts.eng.rdu.redhat.com's password: 
Sending        aliases
Transmitting file data .
Committed revision 9.

However, the following bug shows no commit info:
https://bz-web2-test.devel.redhat.com/show_bug.cgi?id=713079

Need additional info. If this is a bug, feel free to set this back to ASSIGNED, Simon.
Comment 47 Lukáš Petrovický 2011-05-11 06:57:01 EDT
It works now. Nice!

Note You need to log in before you can comment on or make changes to this bug.