Hi JD,

First, thanks for your interest in the BIRT Community. For users of BIRT, the BIRT newsgroup/forum is the place where all the action happens. You can access it here:

http://www.eclipse.org/forums/index.php/f/2/

As you will see, this is a very active forum (one of the most active in the Eclipse ecosystem). Community members and the BIRT team try to respond as quickly as possible to questions in that forum.

When a question comes in on the mailing lists, it is typically a user question and we (usually myself) re-direct the poster to the forum. I occasionally miss one, which is probably what happened to the one on Jan 8. Hopefully that person posted to the forum anyway. FWIW, some users also post to other areas such as Stack Overflow, BIRT-Exchange and other community forums – we try to monitor those as well and post responses there when questions come up.

For developers of BIRT, the mailing lists are not used much for development discussions – more as a news channel for builds. Any technical discussion happens in the context of specific Bugzilla items when needed.

Hope this helps.

Paul.

From: birt-pmc-bounces@xxxxxxxxxxx [mailto:birt-pmc-bounces@xxxxxxxxxxx] On Behalf Of Joseph D Carroll Jr
Sent: Wednesday, May 08, 2013 7:52 AM
To: BIRT PMC communications (including coordination, announcements, and Group discussions)
Subject: Re: [birt-pmc] Separate bug tracker?

I’m glad to see that the repo was updated again yesterday (after a 10 day delay), but it still looks like various things are missing, as shown in the following bug reports, which were closed as fixed without (AFAICS) the corresponding commits being present in the public repo.

https://bugs.eclipse.org/bugs/buglist.cgi?bug_id=403861%2C404037%2C403637%2C403862%2C330993%2C402587%2C403864&bug_id_type=anyexact&query_format=advanced&list_id=5403538

To make sure there is no misunderstanding, the Eclipse repository has been and always is the primary repository for the BIRT project.        

Wenfeng

I’m not Wayne or Mike, but as I understand the situation... A local git repo is fine, as long as it is automatically mirroring the public one at git.eclipse.org (baring connectivity problems like cable cuts). That should resolve any performance or reliability concerns. The problem was having the primary repository be a non-public, non-Eclipse-hosted one, and having the Eclipse repo only get infrequent, batched commits long after the actual work was first done. That would not be an issue if the local repo was being automatically kept in sync with the git.eclipse.org one.

Hopefully that will clarify things?

Jesse (no i) Weinstein

From Wayne and Jessie's email ,  I gather that any local git repo is not recommended.   All committers should be  using the git.eclipse.org directly.  

Wayne,  after our subnet is white-listed I have not heard the access deny problem anymore.  On the other hand, the longest period of not being able to access Eclipse servers was due to a under-sea internet cable was cut.  Nothing webmaster or us can do anything about it. 

I will talk to all committers at Actuate to connect to git.eclipse.org directly.   I expect  that the same  concern of  performance, reliability, etc would be raised.   But I will convey the message that this is Eclipse's recommendation: Actuate should not be providing a local git repo behind the firewall.     If needed for Kepler release, Actuate can  keep  the local git repo until  Kepler is done.  But definitely stop after that.

Wenfeng

The webmaster's email log shows that--in most cases--the problems were caused by repeated authentication problems causing our intrusion detection logic to blacklist the subnet. He tells me that the subnet has been whitelisted, so as long as your committers know their login credentials they should be able to access git.eclipse.org directly.

If problems persist, we need to know about them so that they can be addressed.

I am concerned about the authentication problem. What could be causing multiple authentication failures? Are committers forgetting their credentials? Or was this just a point-in-time problem?

Do these problems persist today?

Wayne

If the branches are all in the same central server and if the central server is not accessible, then users of the git system are stuck.  This is what I meant not fully leveraging the distributed model of git.    

 

We can go back to check the historic data, you can also check with Eclipse web masters.  As I recalled in the previous email, there were cases we don't have access for Eclipse servers for days and at one case for weeks.

 

Wenfeng

 

 

 

From: birt-pmc-bounces@xxxxxxxxxxx [mailto:birt-pmc-bounces@xxxxxxxxxxx] On Behalf Of Wayne Beaton
Sent: Monday, April 29, 2013 8:40 AM
To: birt-pmc@xxxxxxxxxxx
Subject: Re: [birt-pmc] BIRT Git repository may be out of date.

 

Git is a distributed development model. There is no cloud magic that automatically makes merging distributed Git repositories any easier than just merging against git.eclipse.org. If I'm wrong, please let me know. Be specific.

How long does a pull/push combination take? How often does it fail?

Using branches, including the notion of a main "development" branch and individual committer branches is how Git is intended to be used. Using branches does fully leverage the distributed model of Git.

http://nvie.com/posts/a-successful-git-branching-model/

We have many projects with very distributed teams. The Eclipse project, for example, has developers working in shared repositories from China, Europe, and America.

If there are specific impediments to making this work, please let me know. We can try to work them out here, or we can open bugs to get Webmaster assistance.

Wayne

On 04/29/2013 02:46 AM, Wenfeng Li wrote:

There are two issues I think we need solutions: distributed development model and globally reliable infrastructure.  Using branches might be able to support distributed development model to some degree, but with only servers at NA, we don't have the distributed infrastructure.   Also, I think branching approach is not fully leveraging the distributed model of git.

 

Wenfeng

 

---

From: birt-pmc-bounces@xxxxxxxxxxx [birt-pmc-bounces@xxxxxxxxxxx] On Behalf Of Wayne Beaton [wayne@xxxxxxxxxxx]
Sent: Sunday, April 28, 2013 6:37 PM
To: birt-pmc@xxxxxxxxxxx
Subject: Re: [birt-pmc] BIRT Git repository may be out of date.

AFAIK, anybody with write access can create a branch in a git.eclipse.org repository. There may be a setting that prevents this, but the webmaster can help you sort that out.

Many projects work this way today. Creating branches is easy. I know that some projects make it hard to delete branches (again, I think that this is a setting) and will involve the webmaster to delete branches to reduce the opportunities for errors.

If this is what's stopping BIRT committers from working directly in the git.eclipse.org repository, then we can work this out.

The ideal situation is that BIRT developers regularly commit their ongoing work into the master repository at git.eclipse.org. It is perfectly valid for them to be pushing into separate feature-specific branches, but those branches really need to be in the master repository.

Developers forking the master repository in a GitHub context is a non-starter. Yes, these forked repositories would be publicly accessible, but hunting them down and identifying which ones are eclipse.org forks would be a problem pushed on the community. IMHO, this would be far more confusing than having development branches in the main repository.

Wayne

On 04/28/2013 02:20 AM, Wenfeng Li wrote:

 

Yes, we could have used a feature branch.  It is what we used to do with CVS.   The down side is that someone needs to manage the creation/deletion/build/testing of branches.  I think git, as distributed tool, can help us save such work, as well as give everyone more freedom to work on the code without touching the master-git, which is always more involved and perceived risky.

 

Github like model is different from creating branches in the master git, because a developer or team of developers doesn't need to ask the master git owner to create branches for them.  They can just start working on the code as they wish.   I think it will encourage more developers to experiment or play with the project code, and then contribute to the master-git code base when they are ready or let the community to test the features before adding them to master git.  There is already people use github to work on Eclipse code base, but I think it would  have been better (at least IP wise) that Eclipse hosts those codes.  I think such model will help Eclipses to get more contributions from the community than everything in the master-git model.

 

In addition to the distributed development model,   I think we shall also have the distributed infrastructure so that  all committers around the globe can  rely on the Eclipse servers, would it be better to leverage the cloud than having our own data center?

 

Lastly,  I think the  issue of this email thread probably wasn't about our different view of what  the development model should be.  The issue was about if the local git should be behind the fire-wall.  I think we are all in agreement that the desire is to have it on  a public server.  With current infrastructure, we can try push more often but we don't have the ability to make a public "local" git.  I wish that EMO can help.  .  It would be even better if Eclipse can consider supporting the distributed github model as well as a cloud based infrastructure for global access. 

 

 

Wenfeng

 

 

 

From: birt-pmc-bounces@xxxxxxxxxxx [mailto:birt-pmc-bounces@xxxxxxxxxxx] On Behalf Of Wayne Beaton
Sent: Saturday, April 27, 2013 9:25 PM
To: birt-pmc@xxxxxxxxxxx
Subject: Re: [birt-pmc] BIRT Git repository may be out of date.

 

Working on a feature in a local repo and then pushing the commits for that feature to the master repo is a reasonable way of working. In my definition, however, a "feature" represents a handful of commits over a half-day or so of work (based on the agile concept of a feature). I assume that you're using "feature" in a much broader sense of the word.

The synchronization with git.eclipse.org has to happen more frequently. If not automatically, then you'll have to work regular manual synchronization into your development plan. Frankly, I agree that doing it automatically won't work in the general case: if the project has committers working outside of the Actuate infrastructure, the opportunity for merge conflicts will grow.

The git.eclipse.org repository has to be treated as the master repository. You can't treat the master repository as some protected thing that you only ever push complete work to. Incomplete work needs to be in the repository as well: perhaps in separate branches, but most certainly in the master repository. It's okay to be a few commits behind here-and-there, but the master repository needs to contain the ongoing work.

Perhaps you might consider creating feature-specific branches for ongoing development of features that you aren't ready to merge into master or one of the version-specific branches .

I don't understand how working with GitHub would be any different than working directly with git.eclipse.org. You'd still have to be regularly pushing to a publicly-accessible repository. If you can do this against GitHub, why not git.eclipse.org? Any global distributed cloud-based infrastructure that I can envision is still going to have a merge conflict/resolution problem to solve.

Git is our distributed infrastructure. At this point in time, we have no plans (or motivation) to invest in an alternative solution.

Wayne

On 04/27/2013 11:36 PM, Wenfeng Li wrote:

Why it is not possible for any other committers to push local git to Eclipse master git?    Actuate's repo is not the "master" copy, Eclipse one is.   Any other committer's local repo can be merged to the Eclipse master copy. 

 

"Thrown over the wall" is  not accurate nor a fair characterization of the contribution of our team.  I am disappointed on the use of such words.   If a feature required changes from several people, having a local repo to test the integration before merging to the master repo is a better process than automatically throw over the code to master repo without integration testing first. 

 

I am open to suggestions.  But I think automatic merge is not the solution.

 

What do you think about the gitHub model?  All committers can have a "local"/"personal" git, and merge to the master repo when a feature is completed/tested.   

 

If you agree with such model, is it possible for Eclipse to setup a global distributed gitHub equivalent for the Eclipse community?  With that, we will be able to get out of the work to maintain a local behind the firewall git which I also agree that is not a good situation.

 

Wenfeng

 

 

From: birt-pmc-bounces@xxxxxxxxxxx [mailto:birt-pmc-bounces@xxxxxxxxxxx] On Behalf Of Wayne Beaton
Sent: Friday, April 26, 2013 8:52 PM
To: birt-pmc@xxxxxxxxxxx
Subject: Re: [birt-pmc] BIRT Git repository may be out of date.

 

Synchronizing multiple distributed repositories is one of the key values provided by Git. Git is designed to solve the distribution, replication, and merge problems. Git, when used properly, is the cloud-based solution that you think you need.

Having the main project content being developed in a Git repository that is "thrown over the wall" every month or week or so is effectively a private project. For all practical purposes, it is impossible to contribute to BIRT so long as the active repository is hidden away where it is inaccessible to the community. If only Actuate employees have any hope of contributing to the project repository, then it is effectively an Actuate project.

Do you encounter specific, real problems when doing a Git push to git.eclipse.org? Let's work them out. Git is designed to make this work, let's make it work.

Wayne

On 04/26/2013 10:00 PM, Wenfeng Li wrote:

I agree with Mike that a public accessible local git is more transparent.  Hence the proposal for the foundation to set up more "local" git servers globally.

 

On the other hand, having a behind the firewall local git doesn't mean the project is Actuate's only,  all committers can set up their own local git and push to the same master git at Eclipse.   This is the distributed nature of Git.

 

As for the suggestion of automatically push local change,    one issue needs to resolve is how to resolve conflicts if there are changes from different "local" git?  

 

An ideal situation is that committers don't need to worry about the source control system and build servers.  A public, reliable, fast, cloud based global solution would be great.

 

Wenfeng

 

 

 

 

 

From: birt-pmc-bounces@xxxxxxxxxxx [mailto:birt-pmc-bounces@xxxxxxxxxxx] On Behalf Of Mike Milinkovich
Sent: Friday, April 26, 2013 5:49 PM
To: BIRT PMC communications; birt-pmc@xxxxxxxxxxx
Subject: Re: [birt-pmc] BIRT Git repository may be out of date.

 

 

I am not sure that even this would be acceptable. The problem with doing development behind the firewall is that it means that the project is Actuate's, not Eclipse's. How can someone from any other company participate equally on the project if the main development and the 'stable ' builds all happen behind a firewall? 

 

What do you think? 

Mike Milinkovich
mike.milinkovich@xxxxxxxxxxx
+1.613.220.3223

From: Wayne Beaton Sent: Friday, April 26, 2013 8:24 PM To: birt-pmc@xxxxxxxxxxx Reply To: BIRT PMC communications (including coordination, announcements, (including coordination, announcements,>) Subject: Re: [birt-pmc] BIRT Git repository may be out of date.

 

Git is by its very nature a distributed system. Investing in something like AWS for this makes no sense.

We have no issue with a project team working from a local clone. Some amount of latency is expected, but a full month is too much for a project that is expected to working in an open and transparent manner. It is basically impossible for anybody else to participate in the project if the repository is always days, weeks, or months out-of-date.

The pushes back to eclipse.org have to be done more frequently.

At a minimum, you should be able to very quickly set up a cron job that forces a push to eclipse.org every day, or--even better--a few times a day (every hour). This should literally require a one-liner cron entry.  I can help if necessary.

Your developers shouldn't even notice the push is happening. Even better would be some kind of commit hook that does the push (as Jesse suggests). If a single push fails, the next one will do the job. That's how Git works.

This needs to be automatic.

Please make this happen as soon as possible.

Wayne

On 04/26/2013 04:59 PM, Wenfeng Li wrote:

Wayne

 

Is it your recommendation that projects should not use a local git depot, instead all should just use the Eclipse master git depot?

 

We had run into network and accessibility issue to the Eclipse server in the past that causing delay of work and risking not meeting the simultaneous  release schedule.  There were many times, developers can't do work for a several hours to a couple of day.  And there were one time when the whole team was shut down for a week due to a undersea cable was cut between North America and Asia.    

 

One possible solution is for Eclipse foundation to create a distributed git service around the world (using AWS?), it will allow committers to remove the need of local gits.

 

For now, with distributed git, there is a question of how often you push the local copy to the master copy.  It is a matter of someone needs to do the work.  The more often the push, the more work.  On the other hand, we understand we don't want to have a big gap.    so our plan is to push after every stable build since we expect most users would only be using stable builds.

 

In short, I agree that we need to push the code now, since it has been too long since last push.  The intention was to push at least once a month if not more often after each stable build.

 

br,

 

Wenfeng

 

 

 

 

 

From: birt-pmc-bounces@xxxxxxxxxxx [mailto:birt-pmc-bounces@xxxxxxxxxxx] On Behalf Of Wayne Beaton
Sent: Friday, April 26, 2013 10:20 AM
To: birt-pmc@xxxxxxxxxxx
Subject: [birt-pmc] BIRT Git repository may be out of date.

 

I'm moving this discussion out of bugzilla an onto the PMC list.

I assume that you mean "Git" rather than "GitHub".

How often does this push happen?

AFAICT, there hasn't been an commit against BIRT since March 18. But there are bugs that indicate that some work has occurred in the interim. For example:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=404105
https://bugs.eclipse.org/bugs/show_bug.cgi?id=403857
https://bugs.eclipse.org/bugs/show_bug.cgi?id=403860
https://bugs.eclipse.org/bugs/show_bug.cgi?id=399055
https://bugs.eclipse.org/bugs/show_bug.cgi?id=403864

I am very concerned that the public repo is very far behind. This makes it difficult for others to participate, solicit contributions, and grow diversity in the project.

Is it true that there hasn't been a commit against the BIRT Git repository in more than a month?

Wayne


-------- Original Message --------

Subject:	[Bug 402274] Wrapped texts when export to ODP
Date:	Fri, 26 Apr 2013 01:25:51 +0000
From:	bugzilla-daemon@xxxxxxxxxxx
To:	wayne@xxxxxxxxxxx

 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=402274

Product/Component: BIRT / Report Engine

--- Comment #7 from Wenfeng Li <wli@xxxxxxxxxxx> ---

(In reply to comment #6)

> (In reply to comment #5)

> > you should wait until next open source version published.

> 

> Aren't all versions of BIRT open source?

Actuate has a local gitHub that will push to master github after a stable

build.

-- 

You are receiving this mail because:

You are on the CC list for the bug.

 

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects

 

 

_______________________________________________

birt-pmc mailing list

birt-pmc@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/birt-pmc

 

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects

 

 

_______________________________________________

birt-pmc mailing list

birt-pmc@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/birt-pmc

 

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects

 

_______________________________________________

birt-pmc mailing list

birt-pmc@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/birt-pmc

 

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects

 

_______________________________________________

birt-pmc mailing list

birt-pmc@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/birt-pmc

 

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects

 

_______________________________________________

birt-pmc mailing list

birt-pmc@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/birt-pmc

 

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects

 

_______________________________________________

birt-pmc mailing list

birt-pmc@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/birt-pmc

Thank you for the reply.

Regarding the repo syncing – it’s now 10 days out-of-date. That’s more than a week. And (unless you are doing something very strange with your git set-up), syncing, while manual, requires nothing more than running a single command: “git push”. I’m puzzled as to why that would be so difficult.

Wayne, Jesse,

In addition to the testing that happens in the community for open source BIRT, we also do a lot of testing of BIRT in the context of our commercial products. As we encounter issues in our commercial products we track these in our commercial bug tracking system. In some cases, we then narrow the bug down to an issue in the open source code base – in which case, two things happen:

1.       We open a bug in Eclipse Bugzilla to ensure the issue is visible to the community.

2.       We fix the bug in the open source code base.

For #2, the developer may sometimes reference the commercial bug number in the code (that is what the Txxxxxx numbers are). They should reference the Bugzilla number and we will remind them to do so.

Wayne,

Regarding the repository syncing, as Wenfeng indicated in one of the emails last week we plan to move back to direct checkins to the Eclipse git. However, we do not want to make that switch mid-stream for our Kepler development. In the interim, we are now syncing once a week. We realize that ideally it would be more frequently but this is currently a manual process.

Paul.

I would very much like an answer to this question.

Also... the repository is now six days out of date. I understand that making changes takes time. While you are sorting out how, exactly, you're going to change the way BIRT does things, you're going to need to do something stopgap to keep the repository at least sort-of up-to-date.

Thanks,

Wayne

I noticed the "Txxxx" numbers some time ago. I swear that I posted a question about them on a bug, but I can't find it now.

What does the "T56886" in "[BZ]TimeZone is not passed to ScriptContext(T56886)" mean?

Wayne

On 04/29/2013 01:42 PM, Jesse Weinstein wrote:

<snip>

 

 

Regarding the 2^nd point, about public bug reports – here are some examples of commit messages that appear to refer to a private, non-Eclipse-hosted bug tracking system:

https://git.eclipse.org/c/birt/org.eclipse.birt.git/commit/?id=956ee36d507d5ce4a32e5a35adf15fb6355301a8

[BZ]TimeZone is not passed to ScriptContext(T56886)

https://bugs.eclipse.org/bugs/show_bug.cgi?id=56886 is a Platform bug closed in 2006.

While the actual bugzilla entry is https://bugs.eclipse.org/bugs/show_bug.cgi?id=399055

 

https://git.eclipse.org/c/birt/org.eclipse.birt.git/commit/?id=b6947ee83cbe29242645b36670b211f697b4849a

            Fix NPE is thrown out when insert chart into list #59066

            https://bugs.eclipse.org/bugs/show_bug.cgi?id=59066 is a JDT duplicate closed in 2004.

 

There are many other instances visible in https://git.eclipse.org/c/birt/org.eclipse.birt.git/log/

 

 

 

 

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects

_______________________________________________

birt-pmc mailing list

birt-pmc@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/birt-pmc

Wayne, Jesse,

In addition to the testing that happens in the community for open source BIRT, we also do a lot of testing of BIRT in the context of our commercial products. As we encounter issues in our commercial products we track these in our commercial bug tracking system. In some cases, we then narrow the bug down to an issue in the open source code base – in which case, two things happen:

1.       We open a bug in Eclipse Bugzilla to ensure the issue is visible to the community.

2.       We fix the bug in the open source code base.

For #2, the developer may sometimes reference the commercial bug number in the code (that is what the Txxxxxx numbers are). They should reference the Bugzilla number and we will remind them to do so.

Wayne,

Regarding the repository syncing, as Wenfeng indicated in one of the emails last week we plan to move back to direct checkins to the Eclipse git. However, we do not want to make that switch mid-stream for our Kepler development. In the interim, we are now syncing once a week. We realize that ideally it would be more frequently but this is currently a manual process.

Paul.

I would very much like an answer to this question.

Also... the repository is now six days out of date. I understand that making changes takes time. While you are sorting out how, exactly, you're going to change the way BIRT does things, you're going to need to do something stopgap to keep the repository at least sort-of up-to-date.

Thanks,

Wayne

I noticed the "Txxxx" numbers some time ago. I swear that I posted a question about them on a bug, but I can't find it now.

What does the "T56886" in "[BZ]TimeZone is not passed to ScriptContext(T56886)" mean?

Wayne

On 04/29/2013 01:42 PM, Jesse Weinstein wrote:

<snip>

 

 

Regarding the 2^nd point, about public bug reports – here are some examples of commit messages that appear to refer to a private, non-Eclipse-hosted bug tracking system:

https://git.eclipse.org/c/birt/org.eclipse.birt.git/commit/?id=956ee36d507d5ce4a32e5a35adf15fb6355301a8

[BZ]TimeZone is not passed to ScriptContext(T56886)

https://bugs.eclipse.org/bugs/show_bug.cgi?id=56886 is a Platform bug closed in 2006.

While the actual bugzilla entry is https://bugs.eclipse.org/bugs/show_bug.cgi?id=399055

 

https://git.eclipse.org/c/birt/org.eclipse.birt.git/commit/?id=b6947ee83cbe29242645b36670b211f697b4849a

            Fix NPE is thrown out when insert chart into list #59066

            https://bugs.eclipse.org/bugs/show_bug.cgi?id=59066 is a JDT duplicate closed in 2004.

 

There are many other instances visible in https://git.eclipse.org/c/birt/org.eclipse.birt.git/log/

 

 

 

 

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects

_______________________________________________

birt-pmc mailing list

birt-pmc@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/birt-pmc

It is important to get an answer to Wayne’s question:

What does the "T56886" in "[BZ]TimeZone is not passed to ScriptContext(T56886)" mean?

Having transparency in the bug tracker is as important as having transparency in the code repository.

I also note that the git repo hasn’t been updated since Saturday. There haven’t been many bugs modified in that time (the only one I found was https://bugs.eclipse.org/bugs/show_bug.cgi?id=402798 ) but if there have been changes, please do run a `git push` so the rest of the world can see them.

Here are some more problematic commit messages from back in 2008.

https://git.eclipse.org/c/birt/org.eclipse.birt.git/commit/?id=32828bb5c998ca7fc6f158e316863458f4daecec

                Fix bug 100623: High increase in generation time of rpt500 PDF format in A10M5(Linux).

                https://bugs.eclipse.org/bugs/show_bug.cgi?id=100623 -> Platform/Team bug.

https://git.eclipse.org/c/birt/org.eclipse.birt.git/commit/?id=40b14b296ff2ce6c5e67f0248dd2d42b838e6b10

                Refactoring code for project903(TED7495)

https://git.eclipse.org/c/birt/org.eclipse.birt.git/commit/?id=a6a394248632d59d5854aa38644bd02934a0953a

                PDF layout refactor (T8037)

                https://bugs.eclipse.org/bugs/show_bug.cgi?id=8037 -> Platform/SWT bug.

I noticed the "Txxxx" numbers some time ago. I swear that I posted a question about them on a bug, but I can't find it now.

What does the "T56886" in "[BZ]TimeZone is not passed to ScriptContext(T56886)" mean?

Wayne

<snip>

 

 

Regarding the 2^nd point, about public bug reports – here are some examples of commit messages that appear to refer to a private, non-Eclipse-hosted bug tracking system:

https://git.eclipse.org/c/birt/org.eclipse.birt.git/commit/?id=956ee36d507d5ce4a32e5a35adf15fb6355301a8

[BZ]TimeZone is not passed to ScriptContext(T56886)

https://bugs.eclipse.org/bugs/show_bug.cgi?id=56886 is a Platform bug closed in 2006.

While the actual bugzilla entry is https://bugs.eclipse.org/bugs/show_bug.cgi?id=399055

 

https://git.eclipse.org/c/birt/org.eclipse.birt.git/commit/?id=b6947ee83cbe29242645b36670b211f697b4849a

            Fix NPE is thrown out when insert chart into list #59066

            https://bugs.eclipse.org/bugs/show_bug.cgi?id=59066 is a JDT duplicate closed in 2004.

 

There are many other instances visible in https://git.eclipse.org/c/birt/org.eclipse.birt.git/log/