This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Switching from Subversion to Git


On Mon, Sep 22, 2014 at 5:15 PM, Per Bothner <per@bothner.com> wrote:
> Thanks for your strong reasoning - sorry I've been tardy replying.

No problem, it's not an urgent topic and more a long-standing discussion :)

>
> Suppose we enable this workflow, how would that change my current
> workflow for changes that I make?  Right now, after I've tested a
> patch, I just do 'svn ci'.  With "raw git" (or Mercurial) its
> two commands, which is not noticably worse.  But if I have a trivial
> fix I want to make, what is my workflow when using github?
>

For the development you are doing yourself, I would not change your
workflow at all. Simply commit your changes and then push on the
remote git repository. I don't think a formal review style workflow
would bring much for Kawa project as it is right now. Mainly because
you are the main contributor, so you would probably review your own
patches which does not have much sense.

The different workflow I mentioned earlier would be reserved for
patches currently submitted on the mailing list or via the bug
tracker. Here the workflow that is most commonly used on github:

 1. Developer fork Kawa (which is a personal clone with write access)
and creates a feature or fix branch (feature-optimize-switch or
fix-int-conversion, for example).
 2. Developer make some commits in git and push to his forked repository.
 3. Once ready, developer, using GitHub interface, creates a Pull
Request. In words, it's a way to ask you, the manager of the project,
to merge fix-int-conversion branch from forked repository into master
branch of official Kawa repository.
 4. Travis continuous integration runs the whole test suite using the
developer's branch, telling directly in the web UI if the test suite
passes or not.
 4. Being notified, you review the pull request in the web interface,
making comments and asking for changes.
 5. Developer make the changes you asked for and push a new version.
 6. Tests are run again.
 7. You are satisfy with the patch, you simply press merge in the web UI.

>
> Kawa is a GNU project (though a low-profile one), and politically I
> want to be part of the GNU umbrella.  That is one advantage to Savannah.
>

I don't now much about GNU project requirements, so it cannot see what
would be the consequences of moving to GitHub. I read they have hard
policy regarding usages of Free Software. Don't know if this is true
also for the hosting platform.  I guess it's a potential show-stopper.

>
> That's not clear to be.  With millions of Github projects, I'd be
> surprised if getting noticed would be any easier.
>

I agree, maybe I was over optimistic at time of writing :) Overall, I
still think it would be a good move for the exposure of the project.
Maybe just not as big as I have implied.

>
> For now I'd like to keep at least the Kawa web pages on gnu.org, and
> use the existing framework.  (Not to deny that the webpages need work -
> to start the home page needs to be simplified and the Features page
> needs to be updated and punchier.)
>
> I do own the kawa-lang.org domain.  If at some point we move the website,
> I'd like to use that.
>

I understand. The point was mainly to show some possibilities offered
by GitHub. On a side note, configuring a custom domain name with
GitHub Pages seems possible.

>
> Kawa source tarballs are a bit more complex, following GNU standards.
> Can the Github release mechanism handle that?  I see you can add extra
> "assets" (such as pre-generated files), but it's not clear how to do
> that automatically .
>

Hard to tell, I never did a release using GitHub mechanism myself. I
will try to test this feature this week on a test repository to see
how it works and to what extend it could be automated.

>
> I have no experience using GitHub (except some simple browsing) so
> we'd need volunteer(s) to do it.
>

I'm all in to help with this. Again, some conversion work and
configuration is already done and working.

> If we switch to GitHub for bug-tracking (which I assume you wuld recommend?)
> then we have problem what to do with existing issues.  I assume it would
> be too difficult to migrate the existing issues.
>

Indeed, I would recommend it all way long. If there is a web API for
Savannah, which I doubt after my little research, it should be
possible to have something to migrate issues without too much problem.
It almost 100% sure that it would not be a 1:1 mapping, but seeing the
GitHub API for issues (https://developer.github.com/v3/issues/), I
hope that a lot could be achieved.

Even without a Savannah web API for fetching issues, making a small
bot crawling Savannah issues and exporting them to a sort of exchange
format could be a fun "project" for someone wanting to learn Kawa.
With the issues formatted into JSON for example, it would then be easy
to import them into GitHub directly using their web API.

Maybe a volunteer will rise for this :) But if not, I'm willing to
make this happen.

If their is something I can do to help you in your decision, I'm not far :)

In the end, you are the one taking the decision and I will respect it,
whatever it is :D

Best regards,
Matt


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]