buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spiewak <>
Subject Re: Welcome to Rebase Hell!
Date Mon, 02 Mar 2009 17:54:47 GMT
I like the term "town-hall repository" to serve as a central, trustworthy
point for forking (in the good way) and contribution back into the project
with less red tape than a central repo.  To be clear, this town-hall repo
should always remain synced with the main repository, being a less
authoritative source than the official upstream.  However, because this repo
is more accessible to the community and more interactive (faster turnaround
for patches, lower bar for entry, etc) potential contributions are
encouraged to a far higher degree.  People (like myself) who would never
have taken the time to contribute patches in a purely-authoritative
environment are now given exactly the opportunity they need to innovate
unimpeded by the necessary, but annoying processes associated with a single
centralized repository.  This is really no different from people modifying
Buildr for their own needs, except that these modifications can be pushed
back to the community with a minimum of fuss.  Eventually, they may find
their way back to the authoritative repo, but in the meantime, there is no
reason why those at the "town-hall" can't reap the benefits and further
their development.


On Mon, Mar 2, 2009 at 11:44 AM, Assaf Arkin <> wrote:

> On Mon, Mar 2, 2009 at 7:57 AM, Daniel Spiewak <>
> wrote:
> > Welcome back from lurk-mode!  :-)
> >
> > I think this is an interesting issue beyond just Git vs SVN and how the
> > project is hosted.  As Assaf said, the Git repository is still synced to
> > the
> > SVN (and vice versa), so there isn't any real side-stepping going on.  In
> > fact, committers could use SVN directly if they so choose (without any
> > negative impact on an SVN-based workflow), it's merely personal taste
> which
> > drives everyone to Git.  The interesting point though is that while in
> > incubation, Vic's GitHub repo really became the "unofficially canonical"
> > one.  While Buildr's site did point everyone to the SVN *first*, the
> > culture
> > was such that Git was really the convention/standard across the board.
> > That's not to say that SVN was discouraged in any way, it just wasn't
> used
> > (except as the main store-point once commits were made).
> >
> > The larger issue here is what does it mean to be the "primary" source
> when
> > all sources give the same artifacts?  Is it the repository officially
> > recommended by the project?  Is it the repository decided by the "wisdom
> of
> > the masses" in the development team?  As solutions like Git, Mercurial
> and
> > Bazaar catch on, I think we're going to see more and more projects
> raising
> > this issue: what does it mean to have multiple "canonical" sources and
> when
> > does it really cause problems?
> Apache has two interesting principles.
> The first, you need a "licensed and reviewed contributions" repository. The
> repository blessed by Apache so to speak, from which you cut releases.
> There's a lot of wisdom of the years insisting on having this repository,
> and also insisting that it run on Apache hardware (meaning, guarded and
> monitored by Apache).
> The second, all development have to be done in the open, that way everyone
> can participate. It's the open development part of open source. (The
> context
> here is the project and its community, not anything you do downstream.)
> Once
> code has been brought to our attention -- JIRA patch, mailing list
> discussions, etc -- we continue working on it in a public forum with as
> much
> visibility as possible.
> In the SVN model this job is handled by the master repository, but what
> would we do if there was only Git?
> You will still have one "licensed and reviewed contributions" Git
> repository, and it will still be hosted on Apache hardware, and it will
> still be only writable to committers. Again all those wisdoms of the years
> will take us there. The difference is, you can also have any number of
> perfectly synchronized clones, so development can happen elsewhere.
> Now we get into the open development question. If development can happen
> anywhere, how do I keep track of all the places where it happens? And where
> do I find one place where it happens, so I can start tracking it? You need
> to have at least one place that everyone can point to, a common ground, and
> it needs to have certain guarantees: be an accurate clone of the
> contribution repo, get synchronized quickly enough, not be the weakest link
> (security wise), etc.
> It doesn't have to be a single place, but having too many places could be a
> problem. Where do you start? Are they all as well maintained? Will they
> last
> long enough to be permalinks?
> The second question is, once code has been brought to our attention, what
> places do we have to accommodate it before it ends up in
> the contribution repo. Our focus here is for everyone to be able to follow
> changes to that code, say as a result of discussion on the mailing list,
> and
> for committers to be able to pull it in as a contribution. This should be
> at
> least as good as what we have right now; for the record, what we have right
> now are JIRA patches.
> In my experience, you can have as many canonical sources as you want, but
> as
> a project you're responsible for their quality/reliability, it actually
> works better to have as few as possible. One must be the "licensed and
> reviewed contribution" repo, which Apache takes care of.
> For people who want to track development, view the source code, branch off,
> or start contributing, which repository would you point them to? Let's call
> this one "the town hall repo", the one place we get to socialize around
> code.
> I absolutely agree that this should be a decision for the individual
> project. It doesn't have to run on Apache infrastructure, as long as it
> follows certain guidelines (public access, restricted writes, timely
> updates, etc), it just has to work very well for that project. It therefore
> can't be Apache official repository because the ASF can't govern other
> people's infrastructure. But if the project agrees to supervise it for the
> purposes I outlined above, why can't it be the project's primary public
> repository?
> To put it in context, all mailing list discussions have to pass through
> Apache's servers, and Apache maintains the contributing archive. If in
> doubt, look there. But projects can tell people to search in other
> archives,
> like markmail or nabble. Can one of these off-site archives be the primary
> point of reference for the project? If so, why can't we do the same for
> source control?
> Assaf
> > Daniel
> >
> > On Mon, Mar 2, 2009 at 3:07 AM, Martijn Dashorst <
> >
> > > wrote:
> >
> > > On Mon, Mar 2, 2009 at 1:34 AM, Assaf Arkin <> wrote:
> > > > I'm with you in using Github as the main repository:
> > >
> > > As an ASF Member I must protest against the direction that you are
> > > taking this project. GitHub can not be used as the main repository for
> > > any ASF Project. The canonical resource for Apache project's code must
> > > be hosted on Apache hardware. Since the only repository that is
> > > supported by Infrastructure is SVN, you'll have to maintain the
> > > primary source for your project *in* SVN. Not somewhere else, not
> > > bypassing ASF authorizations, not bypassing Apache policy.
> > >
> > > Martijn
> > >
> >

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