You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by Santiago Gala <sa...@gmail.com> on 2008/05/01 18:13:07 UTC
[dSCM] Use case: infra down for maintenance
The recent days of hardware problems have caused a slowdown in the
commit of code across the ASF, and probably that some working copies
contain now a mixture of different units of work.
Using dSCM tools the "hiccups" of the central repository would have no
secondary effects of mixing work units, but would just slow down the
merging. And even this could have been solved "peer to peer" between
developers, or by having a copy of the repository with the whole history
server temporarily from a different place (say p.a.o or a hosting
place).
Regards
Santiago
--
Santiago Gala
http://memojo.com/~sgala/blog/
Re: [dSCM] Use case: infra down for maintenance
Posted by Grant Smith <wo...@gmail.com>.
He was referring to "peer-to-peer" communication between two computers. In
other words, committing changes from one developer to another, but not the
central repository.
"Peer Review" is a concept which we use to ensure our "peers" (fellow
programmers and community members) review our work, etc.
> I'm just curious about this last statement. Aren't we all supposed to do
> peer-to-peer review of each others' patches? We tend to use Jira to share
> patches but I'm missing the fundamental difference in the process.
>
> Thanks,
> Matthieu
>
>
> >
> > --- Noel
> >
> >
> >
>
--
Grant Smith
Re: [dSCM] Use case: infra down for maintenance
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
On Fri, 2008-05-02 at 10:00 +0200, Santiago Gala wrote:
> <irony>
> You mean it would slow our code evolution to a sluggish and confusing
> state so that the ASF would die a horrible, slow, thermal death such as
> the one the linux kernel seems to be enjoying since they adopted git?
> </irony>
No, exactly the opposite would happen. Because of different needs,
pushes and working speeds, the projects would start to fragment.
See http://thread.gmane.org/gmane.linux.kernel/673386/
Linux is different, because it has something that we don't want to have:
A benevolent dictator.
Our development model enforces peers and wants to avoid project lead
developers, so it seems that for us, a centralized development model is
actually better suited because it allows everyone participating to keep
up to date.
Best regards
Henning
--
Henning P. Schmiedehausen -- hps@intermeta.de | JEE, Linux, Unix
91054 Buckenhof, Germany -- +49 9131 506540 | Apache Java Software
Open Source Consulting, Development, Design |
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Gesellschaftssitz: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
char name_buf[257]; /* max unix filename is 256, right? */
Re: [dSCM] Use case: infra down for maintenance
Posted by Santiago Gala <sa...@gmail.com>.
El jue, 01-05-2008 a las 15:20 -0700, Alan Cabrera escribió:
> On May 1, 2008, at 11:42 AM, Matthieu Riou wrote:
>
> > On Thu, May 1, 2008 at 11:31 AM, Sander Striker <s....@striker.nl>
> > wrote:
> >
> >> On Thu, May 1, 2008 at 8:05 PM, Matthieu Riou
> >> <ma...@offthelip.org>
> >> wrote:
> >>>
> >>> On Thu, May 1, 2008 at 10:47 AM, Noel J. Bergman <no...@devtech.com>
> >> wrote:
> >> [...]
> >>>> We do not want "peer to peer between developers" -- that is a
> >> violation of
> >>>> our development methodology, not a tool limitation.
> >>>>
> >>>
> >>> I'm just curious about this last statement. Aren't we all supposed
> >>> to
> >> do
> >>> peer-to-peer review of each others' patches? We tend to use Jira to
> >> share
> >>> patches but I'm missing the fundamental difference in the process.
> >>
> >> There is a difference between peer-review, and doing development
> >> helped by a dSCM which exchanges changesets between cooperating
> >> peers. We want everything to flow through the main repository,
> >> "forcing"
> >> collaboration on one tree.
> >>
> >
> > So let's see:
> >
> > 1. I develop something locally
> > 2. I post a patch in Jira for review
> > 3. Someone gets the patch and reviews it
> > 4. My patch is brilliant, I commit it.
> >
> > Compare to:
> >
> > 1. I develop something locally
> > 2. I make it available from a public mirror or my local copy
> > 3. Someone looks at it
> > 4. My patch is brilliant, I push it.
> >
> > I understand that on step 4, I could very well not push it. But I
> > could very
> > well not commit it either and just apply it on my super secret
> > vendor branch
> > instead. The latter is just slightly more painful but not more
> > painful than
> > slicing a big commit in several small ones to compare to a similar
> > parallel
> > thread :)
>
> The difference is step 2. In the former there is a single known place
> for people to monitor. In the latter, it adds complexity in the form
> of known and unknown peers whose locations must be kept track of and
> disseminated. Given the nature of developers who are loathe to follow
> even the modicum of procedure that we already impose I predict a
> proliferation of ad hoc peers that are not on most people's radar.
>
<irony>
You mean it would slow our code evolution to a sluggish and confusing
state so that the ASF would die a horrible, slow, thermal death such as
the one the linux kernel seems to be enjoying since they adopted git?
</irony>
While I think we can export data off the ASF issue tracker,
a) there is no way to do extensive work while offline while our
development processes have a proportion of patches hosted in a JIRA
instance, except by handling those patches by hand before going offline,
which is way more painful than pulling the involved branches/whole repos
before going offline.
b) if the server that hosts it has trouble, *we all* have trouble. This
is a key problem of any centralized approach. You may call FUD on it,
the same way that I called FUD on your remark about coordination being a
key problem of any de-centralized approach.
c) if some contractual problem would lead us off JIRA, we would have to
spend a long time migrating and organizing the bug tracker data so that
it is available again with comparible URIs, etc. (see the sf.net ->
roundup migration that the PSF has done as an example).
Regards
Santiago
>
> Regards,
> Alan
>
>
>
>
>
--
Santiago Gala
http://memojo.com/~sgala/blog/
RE: [dSCM] Use case: infra down for maintenance
Posted by "Noel J. Bergman" <no...@devtech.com>.
Matthieu Riou wrote:
> I'm thinking of a zone with the possibility to have git repositories per
> account on p.a.o.
And the benefit of this would be what?
--- Noel
Re: [dSCM] Use case: infra down for maintenance
Posted by Matthieu Riou <ma...@offthelip.org>.
On Fri, May 2, 2008 at 3:22 AM, Henning Schmiedehausen <hp...@intermeta.de>
wrote:
>
> On Thu, 2008-05-01 at 15:36 -0700, Matthieu Riou wrote:
>
> [...]
>
> > > The difference is step 2. In the former there is a single known place
> for
> > > people to monitor. In the latter, it adds complexity in the form of
> known
> > > and unknown peers whose locations must be kept track of and
> disseminated.
> > > Given the nature of developers who are loathe to follow even the
> modicum of
> > > procedure that we already impose I predict a proliferation of ad hoc
> peers
> > > that are not on most people's radar.
> > >
> >
> > That's because we have an existing process in place and created a single
> > known place for the patches (Jira). We could very well have a single
> known
> > place in the latter case if so we choose.
>
> Cool. Come up with a plan for us to review. How would you set this up?
> (Please keep in mind: 2000+ committers, 60+ projects, growth of at least
> 10% per year).
>
I'm thinking of a zone with the possibility to have git repositories per
account on p.a.o. And I wouldn't mind trying to set that up. Otherwise we
can all put our stuff on p.a.o but I'm guessing it wouldn't be so nice :)
Matthieu
>
> Best regards
> Henning
>
>
> --
> Henning P. Schmiedehausen -- hps@intermeta.de | JEE, Linux, Unix
> 91054 Buckenhof, Germany -- +49 9131 506540 | Apache Java Software
> Open Source Consulting, Development, Design |
>
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
> Gesellschaftssitz: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
>
> char name_buf[257]; /* max unix filename is 256, right? */
>
>
>
Re: [dSCM] Use case: infra down for maintenance
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
On Thu, 2008-05-01 at 15:36 -0700, Matthieu Riou wrote:
[...]
> > The difference is step 2. In the former there is a single known place for
> > people to monitor. In the latter, it adds complexity in the form of known
> > and unknown peers whose locations must be kept track of and disseminated.
> > Given the nature of developers who are loathe to follow even the modicum of
> > procedure that we already impose I predict a proliferation of ad hoc peers
> > that are not on most people's radar.
> >
>
> That's because we have an existing process in place and created a single
> known place for the patches (Jira). We could very well have a single known
> place in the latter case if so we choose.
Cool. Come up with a plan for us to review. How would you set this up?
(Please keep in mind: 2000+ committers, 60+ projects, growth of at least
10% per year).
Best regards
Henning
--
Henning P. Schmiedehausen -- hps@intermeta.de | JEE, Linux, Unix
91054 Buckenhof, Germany -- +49 9131 506540 | Apache Java Software
Open Source Consulting, Development, Design |
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Gesellschaftssitz: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
char name_buf[257]; /* max unix filename is 256, right? */
Re: [dSCM] Use case: infra down for maintenance
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, May 1, 2008 at 3:20 PM, Alan Cabrera <ad...@toolazydogs.com> wrote:
>
> On May 1, 2008, at 11:42 AM, Matthieu Riou wrote:
>
> On Thu, May 1, 2008 at 11:31 AM, Sander Striker <s....@striker.nl>
> > wrote:
> >
> > On Thu, May 1, 2008 at 8:05 PM, Matthieu Riou <ma...@offthelip.org>
> > > wrote:
> > >
> > > >
> > > > On Thu, May 1, 2008 at 10:47 AM, Noel J. Bergman <no...@devtech.com>
> > > >
> > > wrote:
> > > [...]
> > >
> > > > We do not want "peer to peer between developers" -- that is a
> > > > >
> > > > violation of
> > >
> > > > our development methodology, not a tool limitation.
> > > > >
> > > > >
> > > > I'm just curious about this last statement. Aren't we all supposed
> > > > to
> > > >
> > > do
> > >
> > > > peer-to-peer review of each others' patches? We tend to use Jira to
> > > >
> > > share
> > >
> > > > patches but I'm missing the fundamental difference in the process.
> > > >
> > >
> > > There is a difference between peer-review, and doing development
> > > helped by a dSCM which exchanges changesets between cooperating
> > > peers. We want everything to flow through the main repository,
> > > "forcing"
> > > collaboration on one tree.
> > >
> > >
> > So let's see:
> >
> > 1. I develop something locally
> > 2. I post a patch in Jira for review
> > 3. Someone gets the patch and reviews it
> > 4. My patch is brilliant, I commit it.
> >
> > Compare to:
> >
> > 1. I develop something locally
> > 2. I make it available from a public mirror or my local copy
> > 3. Someone looks at it
> > 4. My patch is brilliant, I push it.
> >
> > I understand that on step 4, I could very well not push it. But I could
> > very
> > well not commit it either and just apply it on my super secret vendor
> > branch
> > instead. The latter is just slightly more painful but not more painful
> > than
> > slicing a big commit in several small ones to compare to a similar
> > parallel
> > thread :)
> >
>
> The difference is step 2. In the former there is a single known place for
> people to monitor. In the latter, it adds complexity in the form of known
> and unknown peers whose locations must be kept track of and disseminated.
> Given the nature of developers who are loathe to follow even the modicum of
> procedure that we already impose I predict a proliferation of ad hoc peers
> that are not on most people's radar.
>
That's because we have an existing process in place and created a single
known place for the patches (Jira). We could very well have a single known
place in the latter case if so we choose.
Cheers,
Matthieu
>
>
> Regards,
> Alan
>
>
>
>
>
>
Re: [dSCM] Use case: infra down for maintenance
Posted by Alan Cabrera <ad...@toolazydogs.com>.
On May 1, 2008, at 11:42 AM, Matthieu Riou wrote:
> On Thu, May 1, 2008 at 11:31 AM, Sander Striker <s....@striker.nl>
> wrote:
>
>> On Thu, May 1, 2008 at 8:05 PM, Matthieu Riou
>> <ma...@offthelip.org>
>> wrote:
>>>
>>> On Thu, May 1, 2008 at 10:47 AM, Noel J. Bergman <no...@devtech.com>
>> wrote:
>> [...]
>>>> We do not want "peer to peer between developers" -- that is a
>> violation of
>>>> our development methodology, not a tool limitation.
>>>>
>>>
>>> I'm just curious about this last statement. Aren't we all supposed
>>> to
>> do
>>> peer-to-peer review of each others' patches? We tend to use Jira to
>> share
>>> patches but I'm missing the fundamental difference in the process.
>>
>> There is a difference between peer-review, and doing development
>> helped by a dSCM which exchanges changesets between cooperating
>> peers. We want everything to flow through the main repository,
>> "forcing"
>> collaboration on one tree.
>>
>
> So let's see:
>
> 1. I develop something locally
> 2. I post a patch in Jira for review
> 3. Someone gets the patch and reviews it
> 4. My patch is brilliant, I commit it.
>
> Compare to:
>
> 1. I develop something locally
> 2. I make it available from a public mirror or my local copy
> 3. Someone looks at it
> 4. My patch is brilliant, I push it.
>
> I understand that on step 4, I could very well not push it. But I
> could very
> well not commit it either and just apply it on my super secret
> vendor branch
> instead. The latter is just slightly more painful but not more
> painful than
> slicing a big commit in several small ones to compare to a similar
> parallel
> thread :)
The difference is step 2. In the former there is a single known place
for people to monitor. In the latter, it adds complexity in the form
of known and unknown peers whose locations must be kept track of and
disseminated. Given the nature of developers who are loathe to follow
even the modicum of procedure that we already impose I predict a
proliferation of ad hoc peers that are not on most people's radar.
Regards,
Alan
Re: [dSCM] Use case: infra down for maintenance
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
On Thu, 2008-05-01 at 11:42 -0700, Matthieu Riou wrote:
> So let's see:
>
> 1. I develop something locally
> 2. I post a patch in Jira for review
> 3. Someone gets the patch and reviews it
> 4. My patch is brilliant, I commit it.
>
> Compare to:
>
> 1. I develop something locally
> 2. I make it available from a public mirror or my local copy
> 3. Someone looks at it
> 4. My patch is brilliant, I push it.
Step 2:
a) one JIRA at https://issues.apache.org/jira
b) somewhere, that might be down, not accessible, and everyone uses
different locations. Hunting down needed.
That is the difference. And it is huge. As Sander wrote, the ASF wants
to *enforce* a centralized development model. Because it is a pillar of
our community. That is a political, not a technical decision.
Best regards
Henning
--
Henning P. Schmiedehausen -- hps@intermeta.de | JEE, Linux, Unix
91054 Buckenhof, Germany -- +49 9131 506540 | Apache Java Software
Open Source Consulting, Development, Design |
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Gesellschaftssitz: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
char name_buf[257]; /* max unix filename is 256, right? */
Re: [dSCM] Use case: infra down for maintenance
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, May 1, 2008 at 11:31 AM, Sander Striker <s....@striker.nl>
wrote:
> On Thu, May 1, 2008 at 8:05 PM, Matthieu Riou <ma...@offthelip.org>
> wrote:
> >
> > On Thu, May 1, 2008 at 10:47 AM, Noel J. Bergman <no...@devtech.com>
> wrote:
> [...]
> > > We do not want "peer to peer between developers" -- that is a
> violation of
> > > our development methodology, not a tool limitation.
> > >
> >
> > I'm just curious about this last statement. Aren't we all supposed to
> do
> > peer-to-peer review of each others' patches? We tend to use Jira to
> share
> > patches but I'm missing the fundamental difference in the process.
>
> There is a difference between peer-review, and doing development
> helped by a dSCM which exchanges changesets between cooperating
> peers. We want everything to flow through the main repository, "forcing"
> collaboration on one tree.
>
So let's see:
1. I develop something locally
2. I post a patch in Jira for review
3. Someone gets the patch and reviews it
4. My patch is brilliant, I commit it.
Compare to:
1. I develop something locally
2. I make it available from a public mirror or my local copy
3. Someone looks at it
4. My patch is brilliant, I push it.
I understand that on step 4, I could very well not push it. But I could very
well not commit it either and just apply it on my super secret vendor branch
instead. The latter is just slightly more painful but not more painful than
slicing a big commit in several small ones to compare to a similar parallel
thread :)
Cheers,
Matthieu
>
> Cheers,
>
> Sander
>
Re: [dSCM] Use case: infra down for maintenance
Posted by Sander Striker <s....@striker.nl>.
On Thu, May 1, 2008 at 8:05 PM, Matthieu Riou <ma...@offthelip.org> wrote:
>
> On Thu, May 1, 2008 at 10:47 AM, Noel J. Bergman <no...@devtech.com> wrote:
[...]
> > We do not want "peer to peer between developers" -- that is a violation of
> > our development methodology, not a tool limitation.
> >
>
> I'm just curious about this last statement. Aren't we all supposed to do
> peer-to-peer review of each others' patches? We tend to use Jira to share
> patches but I'm missing the fundamental difference in the process.
There is a difference between peer-review, and doing development
helped by a dSCM which exchanges changesets between cooperating
peers. We want everything to flow through the main repository, "forcing"
collaboration on one tree.
Cheers,
Sander
Re: [dSCM] Use case: infra down for maintenance
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, May 1, 2008 at 10:47 AM, Noel J. Bergman <no...@devtech.com> wrote:
> Santiago Gala wrote:
>
> > The recent days of hardware problems
>
> is not a justification for dSCM. There have been how many outages since
> switching to SVN? How many total between CVS and SVN over 8 years?
>
> And, as you note, this could be addressed "by having a copy of the
> repository with the whole history
> server temporarily from a different place (say p.a.o or a hosting place)",
> which is part of the plan.
>
> We do not want "peer to peer between developers" -- that is a violation of
> our development methodology, not a tool limitation.
>
I'm just curious about this last statement. Aren't we all supposed to do
peer-to-peer review of each others' patches? We tend to use Jira to share
patches but I'm missing the fundamental difference in the process.
Thanks,
Matthieu
>
> --- Noel
>
>
>
Re: [dSCM] Use case: infra down for maintenance
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, May 1, 2008 at 1:55 PM, Doug Cutting <cu...@apache.org> wrote:
> I think Noel meant that we want project work to take place in public, on
> mailing lists, in Jira and in Subversion. Direct peer-to-peer exchanges of
> patches are not a matter of public record, and should thus not be encouraged
> as an Apache project development pattern.
+1. -- justin
Re: [dSCM] Use case: infra down for maintenance
Posted by Santiago Gala <sa...@gmail.com>.
El vie, 02-05-2008 a las 03:56 -0400, Davanum Srinivas escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> And the concrete proposal is? what?
>
No concrete proposal, this is intended for discussion of possible use
cases. Please notice the conditional verbal form. (Spanish has even more
of those "conditionals/subjunctive/..." forms than French) Very
specially, I don't want to put *any* stress on the infrastructure team
in moments where there are hardware problems, so please, infra people
reading these threads, just keep doing the cool and hard work and let
the threads for a moment where everything is going 100% right, etc.
Sorry if I disturbed you.
> Every project should have a wiki(?) which documents public repos which are sandboxes of prople participating in the
> project (whether they are committers or folks submitting patches)
>
For folks submitting patches, I guess a URL would be enough, as in
"please pull a patch to do YYY from XXX". Other technique often used is
to have tools like git-format-patch/git-send-email, which will send a
series of emails for a set of commits. Those emails document 100% of the
changes, and can be applied by a different person while keeping
authorship and date info.
For committers, a centralized approach would have a repo per committer,
maybe with several branches, hanging off a place like git.kernel.org...
BTW, I have set up one at p.a.o/~sgala/git/ Please tell me if it is
supposed to be a problem, load or otherwise, or I should shut it down or
set up the appropriate robots.txt, ...
> And/OR
>
> When someone creates a JIRA, they should have an option to specify a public git repo location and revision # for their
> patch.
If the patch is generated with something like git-format-patch, see for
instance
https://issues.apache.org/jira/secure/attachment/12380278/SHINDIG-146-for-humans-3.patch
it can be applied by git straight on, without loosing info (AFAICT). So
if we had a clever enough issue tracker stuff, the backoffice of JIRA
should recognize the format and offer a "merge" button, which would
automatically call git-svn on it... (magics happens) ...
Ditto for equivalent formats in mercurial, darcs, whatever... This is
just SciFi I guess. :)
OTOH, such a patch format allows me to save the patch and do something
like:
git checkout master
git checkout -b SHINDIG-146-v3
git am /tmp/SHINDIG-146-for-humans-3.patch
gitk --all&
and have a colored diff browser for the patch, or
git diff master SHINDIG-146-for-humans-3.patch
to see the squashed set of commits. The "for robots" versions just don't
use the move/copy detection, which makes them way more difficult to
read, as a lot of the changes are a rename +4 line changes... but able
to be applied with regular "patch". I actually applied one squashed
version of this one to subversion, but I could have applied the 48 small
changes series instead as 48 commits. The whole thing was an experiment.
I don't think we are at the stage of concrete proposals, at least until
the current problems are clearly solved. One good thing of the modern
SCM world is that changeset formats preserving most/all information are
being developed, so we can, in principle, have lots of interoperating
client sides.
Some people uses command line, some people emacs. Other people netbeans,
intelliJ or eclipse... it would be difficult to have a one-fits-all
solution. I guess the subversion repository format is the current lcd
(lowest common denominator). I like a lot Linus' solution for move-copy
management, very much metacrap-oriented
( http://www.well.com/~doctorow/metacrap.htm ). So I can reconstruct
moves and/or copies for visual inspection, even when subversion is not
tracking them because the author didn't properly move.
Compare this:
http://people.apache.org/~sgala/git/?p=shindig.git;a=commitdiff;h=7530b4d0ac78c01ff8cca12e1890775421d425c0
handled by svn as
http://svn.apache.org/viewvc?view=rev&revision=648723
http://markmail.org/message/befbcst3whk7wxiw
Notice how git-svn told subversion about moves (as copy+delete)
with...
I see:
http://people.apache.org/~sgala/git/?p=shindig.git;a=commitdiff;h=e9b08ce54bd4d55db4c2070358bf691cd914a917
handled as
http://svn.apache.org/viewvc?rev=652498&view=rev
i.e. even if the commit has no copy/move metadata, git reconstructs it,
(see
http://people.apache.org/~sgala/git/?p=shindig.git;a=commitdiff;h=e9b08ce54bd4d55db4c2070358bf691cd914a917#patch10 vs but viewvs doesn't know how. Had this commit gone through git-svn, we would have got better metadata, and a smaller/more clever svn repo and diffs, assuming that the heuristics included with git are good...
This is a killer, IMO. The algorithm for move/copy detection is tunable,
and very useful to review refactorings. In fact I'm currently reading
the foundation private (or web site) repo changes in time by ignoring
completely commit emails and using just:
git svn rebase
git log --color-words --stat -p -M -C
(and then use "/^commit " to navigate commits in $PAGER)
which enables me to see typos corrected as red/green letters at the
terminal, for instance, and moved files like agendas -> minutes cleanly.
Saves a lot of cognitive effort, something nice for people getting old
as myself.
Those were part of the kind of things I wanted to talk about in the
proposal for ACUS 2008 I submitted about "accountancy of source code".
Regards
Santiago
>
> thanks,
> dims
>
> Santiago Gala wrote:
> | El jue, 01-05-2008 a las 13:55 -0700, Doug Cutting escribió:
> |> Santiago Gala wrote:
> |>>> We do not want "peer to peer between developers" -- that is a violation of
> |>>> our development methodology, not a tool limitation.
> |>>>
> |>> Please, define $We. I'm a member of the ASF, active in a few PMCs, and
> |>> have been an officer for some yers, and I don't feel included in such
> |>> $We.
> |> I think Noel meant that we want project work to take place in public, on
> |> mailing lists, in Jira and in Subversion. Direct peer-to-peer exchanges
> |> of patches are not a matter of public record, and should thus not be
> |> encouraged as an Apache project development pattern.
> |
> | Peer to peer exchanges can, and possibly should be for this purpose,
> | done in public. See the hundreds of repos at http://git.kernel.org/ that
> | are variations on the "master" linus tree. They all, literally, document
> | work that would be sunk on private working copies at the ASF. Direct
> | peer-to-peer exchanges of patches is bazaar, not cathedral, style. But
> | neither cathedral style is public without taking measures for
> | transparency (we need to *require* public issue tracker, public lists,
> | no irc or logged irc, irc decisiones were a tough item a few years
> | ago...) nor bazaar style is private by default (in fact, the use of
> | "pull" promotes that every developer has at least one public clone to
> | allow access to their changes, or else they are forced to send patches).
> |
> | We should try to avoid framing the discussion into black/white
> | disjunctions. The line between
> |
> | a) using patches or quilt or eclipse "local changes" as "private repos"
> | and an issue tracker or a development list to review the work and commit
> | to svn, and
> | b) having a full fledged, mandatory dSCM setup for the ASF
> |
> | is a long line, full of places where people can stand. As Sander said,
> | as long as we have the master subversion repository documenting the
> | processes, one can use whatever is reasonable and interoperates with
> | issue tracking, patch generation and application, etc.
> |
> | Regards
> | Santiago
> |
> |> Doug
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
>
> iD8DBQFIGsktgNg6eWEDv1kRAveBAJ4pRx4+PIEp2JMORCJsgWIUzwIlZACdG68/
> AgtmLzK8XuJGkoPpD/5ENqs=
> =hr4E
> -----END PGP SIGNATURE-----
--
Santiago Gala
http://memojo.com/~sgala/blog/
Re: [dSCM] Use case: infra down for maintenance
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
And the concrete proposal is? what?
Every project should have a wiki(?) which documents public repos which are sandboxes of prople participating in the
project (whether they are committers or folks submitting patches)
And/OR
When someone creates a JIRA, they should have an option to specify a public git repo location and revision # for their
patch.
thanks,
dims
Santiago Gala wrote:
| El jue, 01-05-2008 a las 13:55 -0700, Doug Cutting escribió:
|> Santiago Gala wrote:
|>>> We do not want "peer to peer between developers" -- that is a violation of
|>>> our development methodology, not a tool limitation.
|>>>
|>> Please, define $We. I'm a member of the ASF, active in a few PMCs, and
|>> have been an officer for some yers, and I don't feel included in such
|>> $We.
|> I think Noel meant that we want project work to take place in public, on
|> mailing lists, in Jira and in Subversion. Direct peer-to-peer exchanges
|> of patches are not a matter of public record, and should thus not be
|> encouraged as an Apache project development pattern.
|
| Peer to peer exchanges can, and possibly should be for this purpose,
| done in public. See the hundreds of repos at http://git.kernel.org/ that
| are variations on the "master" linus tree. They all, literally, document
| work that would be sunk on private working copies at the ASF. Direct
| peer-to-peer exchanges of patches is bazaar, not cathedral, style. But
| neither cathedral style is public without taking measures for
| transparency (we need to *require* public issue tracker, public lists,
| no irc or logged irc, irc decisiones were a tough item a few years
| ago...) nor bazaar style is private by default (in fact, the use of
| "pull" promotes that every developer has at least one public clone to
| allow access to their changes, or else they are forced to send patches).
|
| We should try to avoid framing the discussion into black/white
| disjunctions. The line between
|
| a) using patches or quilt or eclipse "local changes" as "private repos"
| and an issue tracker or a development list to review the work and commit
| to svn, and
| b) having a full fledged, mandatory dSCM setup for the ASF
|
| is a long line, full of places where people can stand. As Sander said,
| as long as we have the master subversion repository documenting the
| processes, one can use whatever is reasonable and interoperates with
| issue tracking, patch generation and application, etc.
|
| Regards
| Santiago
|
|> Doug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFIGsktgNg6eWEDv1kRAveBAJ4pRx4+PIEp2JMORCJsgWIUzwIlZACdG68/
AgtmLzK8XuJGkoPpD/5ENqs=
=hr4E
-----END PGP SIGNATURE-----
Re: [dSCM] Use case: infra down for maintenance
Posted by Santiago Gala <sa...@gmail.com>.
El jue, 01-05-2008 a las 13:55 -0700, Doug Cutting escribió:
> Santiago Gala wrote:
> >> We do not want "peer to peer between developers" -- that is a violation of
> >> our development methodology, not a tool limitation.
> >>
> >
> > Please, define $We. I'm a member of the ASF, active in a few PMCs, and
> > have been an officer for some yers, and I don't feel included in such
> > $We.
>
> I think Noel meant that we want project work to take place in public, on
> mailing lists, in Jira and in Subversion. Direct peer-to-peer exchanges
> of patches are not a matter of public record, and should thus not be
> encouraged as an Apache project development pattern.
Peer to peer exchanges can, and possibly should be for this purpose,
done in public. See the hundreds of repos at http://git.kernel.org/ that
are variations on the "master" linus tree. They all, literally, document
work that would be sunk on private working copies at the ASF. Direct
peer-to-peer exchanges of patches is bazaar, not cathedral, style. But
neither cathedral style is public without taking measures for
transparency (we need to *require* public issue tracker, public lists,
no irc or logged irc, irc decisiones were a tough item a few years
ago...) nor bazaar style is private by default (in fact, the use of
"pull" promotes that every developer has at least one public clone to
allow access to their changes, or else they are forced to send patches).
We should try to avoid framing the discussion into black/white
disjunctions. The line between
a) using patches or quilt or eclipse "local changes" as "private repos"
and an issue tracker or a development list to review the work and commit
to svn, and
b) having a full fledged, mandatory dSCM setup for the ASF
is a long line, full of places where people can stand. As Sander said,
as long as we have the master subversion repository documenting the
processes, one can use whatever is reasonable and interoperates with
issue tracking, patch generation and application, etc.
Regards
Santiago
>
> Doug
--
Santiago Gala
http://memojo.com/~sgala/blog/
Re: [dSCM] Use case: infra down for maintenance
Posted by Doug Cutting <cu...@apache.org>.
Santiago Gala wrote:
>> We do not want "peer to peer between developers" -- that is a violation of
>> our development methodology, not a tool limitation.
>>
>
> Please, define $We. I'm a member of the ASF, active in a few PMCs, and
> have been an officer for some yers, and I don't feel included in such
> $We.
I think Noel meant that we want project work to take place in public, on
mailing lists, in Jira and in Subversion. Direct peer-to-peer exchanges
of patches are not a matter of public record, and should thus not be
encouraged as an Apache project development pattern.
Doug
RE: [dSCM] Use case: infra down for maintenance
Posted by Santiago Gala <sa...@gmail.com>.
El jue, 01-05-2008 a las 13:47 -0400, Noel J. Bergman escribió:
> Santiago Gala wrote:
>
> > The recent days of hardware problems
>
> is not a justification for dSCM.
Has anybody said it was except you? NO. Frankly, I'm beginning to get
tired of having naysayers around. No need to be defensive.
> There have been how many outages since
> switching to SVN? How many total between CVS and SVN over 8 years?
Scaling up goes very well until it hits the ceiling, as people trying to
compete with google knows well.
> And, as you note, this could be addressed "by having a copy of the
> repository with the whole history
> server temporarily from a different place (say p.a.o or a hosting place)",
> which is part of the plan.
Cool, I was not trying at all to critizice the plan or the execution. As
you might have noticed (I didn't cc: committers@ to avoid spamming) I
thanked the effort of the infra team in this crisis.
>
> We do not want "peer to peer between developers" -- that is a violation of
> our development methodology, not a tool limitation.
>
Please, define $We. I'm a member of the ASF, active in a few PMCs, and
have been an officer for some yers, and I don't feel included in such
$We. And stating that it is a violation is stating that the practice of
attaching patches or having "vendor" repositories that are synced via
patches is a "violation of our development methodology".
I clearly would like to see where is "our development methodology"
documented with such precision.
Regards
Santiago
> --- Noel
>
>
--
Santiago Gala
http://memojo.com/~sgala/blog/
RE: [dSCM] Use case: infra down for maintenance
Posted by "Noel J. Bergman" <no...@devtech.com>.
Santiago Gala wrote:
> The recent days of hardware problems
is not a justification for dSCM. There have been how many outages since
switching to SVN? How many total between CVS and SVN over 8 years?
And, as you note, this could be addressed "by having a copy of the
repository with the whole history
server temporarily from a different place (say p.a.o or a hosting place)",
which is part of the plan.
We do not want "peer to peer between developers" -- that is a violation of
our development methodology, not a tool limitation.
--- Noel