incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <omarg.develo...@gmail.com>
Subject Re: Make Git happen
Date Wed, 21 Nov 2012 20:21:10 GMT
On Wed, Nov 21, 2012 at 12:14 PM, Justin Mclean <justin@classsoftware.com>wrote:

> Hi,
>
> > I've never used GitHub.  It doesn't have a way to monitor commits that
> > couldn't send a notification to flex-commits@?
>
> The problem I see here is that github (and git) encourages local
> branching, so peoples experiments and patches are not always going to be
> public.
>

I see this as a flawed argument. In SVN I could basically keep a bunch of
code for experiments and patches on my local machine without committing as
long as I want, making it not public. The difference is doing this in SVN
without committing makes the process at which a programmer arrived at the
final commit when they do decide to make it public not something that can
be followed. At least with a DVCS you can keep committing while you keep
your work 'private' and when you push you can have a commit history that
makes the changes more palatable.


>
> There's still the outstanding issue of how to close off pull requests -
> it's been in JIRA for months with no comment or resolution.
>
> > So what are really the minimum requirements of the Apache Way?  For sure
> the
> > mailing lists and voting and the processes for earning
> committer-hood.romatic
> I'd add all work must be done in public. Having code in github is slightly
> problematic from that point of view as while it's public ASF has little
> control over it.
>

The valid point here is that code in GitHub would be outside of the
'control' of ASF. Couldn't the onus be on the PMC that we assure all code
that is accepted via GitHub patches meet the requirements of the ASF? We're
all adults here I'm sure we can handle such responsibility.


>
> Having a github mirror of an a ASF hosted git repro (which we basically
> have now) seems the best way forward to me.
>
> Thanks,
> Justin
>
>
I disagree with this as it will continue to complicate the workflows we
ideally want to use to run this project, said workflows being the ones we
voted for earlier this year.

-omar

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message