[egit-dev] Patch handling, bugzilla and IP log

[Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>]

All this is IP-stuff is new and confusing, but probably makes sense somehow.
The Git model seems easier, but it covers less ground.

We need to establish the work flow specific to EGit and JGit here.

We made some experiments and it seems we can both upload
patches from Git to Bugzilla and apply from bugzilla, provided the
patches looks like the e.-mailed patches Git likes. We can also
comment on patches through bugzilla. Using e-mail is a lot
smoother though.

Here is first attempt. I want comments here.

So we mail patches here or directly or add them directly to bugzilla.
Mailed patches should also be added to bugzilla.

Then a committer (another committer if the submitter is a committer),
reviews and commits to Git and SVN at the same time. We could
actually commit less often to SVN, but I think we should post Git
commit one by one. At least as long as we do not merge. The previous
Git-only work flow settled with a linear history, i.e. we rebase before
push if necessary.

Putative branches in Git can exist, but they are not official in any way,
and only mean for peek previews.

JGit patches are treated differently, Patches are mailed to the Git mailing
list and the JGit maintainers, applied and committed to the JGit
repository, JGit is third party software in this context, so updates are
made via CQ's. Is there any benefit of putting JGit in Orbit now, or
shall we perhaps do it later? Is there any difference in what we do
in terms of CQ's?

A special branch in JGit matches the version of JGit that is imported to
and used by the EGit plugin. JGit's master is the latest JGit, which may
not be the version used by the EGit plugin.

The main issue with JGit is that we still want to change it quite often
to accommodate new stuff in EGit and fix bugs. (yes, we do find such).


-- robin