Hi
Wayne,
Going
forward, we do plan to check-in directly to the Eclipse BIRT
Git. But it would be good to do one last sync to get the
last set of code changes into Eclipse Git. I am cc’ing
Xiaoying on this email – if the Eclipse team could work with
Xiaoying to assist us that would be great. If we can do this
quickly maybe we can get caught up for the Kepler SR1 RC1.
What is the best way to move this forward?
To
answer the other aspect of your email: We have been in full
compliance with the IP policy at all times. This is very
important to us of course. Only Committers have been making
code changes. I am not up on all the details but my
understanding is that the issue was the automated sync of
the Committers changes stopped working because the “machine”
making the sync was not a Committer J
(even though all the code changes originated from
Committers).
We
are committing a release to SR1. The current version is the
same as the GA release. We don’t have a lot of code changes
for SR1 but we do have some. This is part of the work caught
in this transition.
Paul.
Thanks Paul.
If there is something that I can do to help BIRT get the
syncing process back up and running, or help your committers
sort out how to work directly against the common repository,
please let me know.
The only real change that we added with the CLAs is the
requirement that non-committer contributors have a signed CLA
and that commits are signed-off-by. Is this what's causing the
breakage? I assume that you have some commit records from
non-committers that have not been "signed-off" using the new
process but are otherwise in full conformance with the IP
Policy. If this is the case then we can work with the
webmaster to implement some kind of temporary work around to
get things up and running. Then, moving forward, you can
implement the new process.
I've noticed that BIRT is contributing the same Kepler GA bits
[1] for Kepler SR1RC1. Will the project be contributing a
service release for SR1 Final?
Thanks,
Wayne
[1] http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/tree/birt.b3aggrcon
On 08/22/2013 03:22 PM, Paul Clenahan
wrote:
Wayne,
Apologies
for the tardy reply on this one but I did want to get back
to you. There are three items you brought up…
Eclipse
BIRT Git repository – For convenience, we had been using a
separate Git repository and automatically syncing that
with the Eclipse BIRT Git repository on a frequent basis.
The goal has always been to ensure that the Eclipse BIRT
Git repository was completely up to date and the community
had the latest code. When the new CLA process was
introduced, our sync process stopped working. Going
forward, we decided that we would do check-ins directly to
the Eclipse BIRT Git repository. That is our current
process. The Bugzilla bugs that are marked as resolved
with code changes that are not in Git are ones that got
caught in the transition between the sync not working and
the revised process. We are reviewing these and will get
them sorted out.
References
to internal tracking numbers – As you note, this was
something discussed a while back. These are Eclipse BIRT
issues found during the testing of our commercial products
that get fixed in the open source code base. Sometimes
references to the internal issue numbers show up in the
comments – we have raised this with our team and will
continue to work to avoid this. I also note that the
Bugzillas logged against BIRT since June 1 include some
logged by IBM and include references to what looks like
some IBM tracking numbers – I have added comments to all
those Bugzilla entries asking that the submitter does not
reference any IBM tracking numbers.
Committer
Community stability – This is simply an indication that we
have a stable committer community. Of course, we would
welcome new committers – and I am interested to see from
your email that there are some folks interested. Would be
great to hear more.
Paul.
Greetings BIRT PMC.
AFAICT, the BIRT project's Git repository has no new commits
for a full month. 17 bugs [1] have changed status to
RESOLVED in that period of time (which indicates that there
must certainly have been some corresponding commit
activity). We had previously discussed having the BIRT
committers work directly against the open source repository.
How is that progressing?
As we have previously discussed, the distributed nature of
Git makes it very natural for development to occur in a
clone. But the eclipse.org repository needs to be kept
current.
Almost all of the commits contain an internal bug tracking
number. AFAICT, only one commit in the month of June
contains a reference to Bugzilla.
We previously discussed the separate issue tracker [2].
After some thought, I don't believe that it is appropriate
for these issue tracker numbers to appear in the open source
project's log. At best, they are meaningless to a potential
contributor or adopter; at worst, they are an indicator to a
potential contributor or adopter that the project is not
open.
I don't believe that creating a Bugzilla record for every
commit makes any sense. But I have to believe that at least
some of these commits have conversations behind them that
are not being captured in a transparent manner.
As we have previously discussed, it's difficult for
contributors to participate in the project when it appears
to be in development behind a corporate firewall.
I've also noticed that the BIRT project has added only two
committers in the last four years (only one in the last
three years). I find this odd. How is it that the project
has had basically no turnover?
Wayne
[1] https://bugs.eclipse.org/bugs/buglist.cgi?list_id=6312385&classification=BIRT&chfieldto=Now&query_format=advanced&chfield=bug_status&chfieldfrom=2013-06-18&chfieldvalue=RESOLVED
[2] http://dev.eclipse.org/mhonarc/lists/birt-pmc/msg00479.html
_______________________________________________
birt-pmc mailing list
birt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/birt-pmc
