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.
From: birt-pmc-bounces@xxxxxxxxxxx [mailto:birt-pmc-bounces@xxxxxxxxxxx] On Behalf Of Paul Clenahan
Sent: Monday, May 06, 2013 2:55 PM
To: BIRT PMC communications (including coordination, announcements, andGroup discussions)
Subject: Re: [birt-pmc] Separate bug tracker?
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
On 04/29/2013 03:13 PM, Wayne Beaton wrote:
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 2nd 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/
_______________________________________________
birt-pmc mailing list
birt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/birt-pmc
