[plt-dev] usr repositories

[Ugh...  Subject change *again* -- what is it with choosing the wrong
thread for the content?]


On Apr 17, Noel Welsh wrote:
> On Sat, Apr 17, 2010 at 5:05 PM, Eli Barzilay <eli at barzilay.org> wrote:
> > Well, *now* would be a good time to ask questions!
> 
> Ok. Funky dev processes are fair easier with Git than svn.

Well, I was trying to solicit questions on git -- not on workflow
decisions...


> Is the intention to mandate any such process? For example, all
> dev. on branches, merge to trunk when finished?

In the beginning, things should be roughly the same as they are now.
That is, there is a `master' branch where all development happens on,
just like the svn trunk.  A notable difference that will probably be
relevant pretty quickly is that branch work is considerabely easier.
So people who are currently using branches (eg, most of the NEU
faction) will probably be greatly relieved, and people who are using
them infrequently or borderline users will probably start using them
more seriously (I'm definitely in that camp).

There are a few administrative decisions that will come up in a short
while.  For example: should the trunk^H^H^H^H^Hmaster branch be stable
at every point.  At least for now, I have implemented a "counter" that
counts pushes -- when you push to the server, you'll get a message
telling you "this is push #N", and this will be a kind-of a cheap
replacement for svn revision numbers for drdr -- specifically, the
plan is for it to test things out on every *push* rather than on every
commit.  This means that the basic important expectation is that you
only push when everything is in working order -- which means that the
master branch on the server should always be in working order.

But a related question is whether you could push a sequence of commits
where some of them are broken, but the overall push is fine.  It is of
course better to have the master be usable at all commits -- for
example, it would make using `git bisect' easier.  There's many ways
to get there -- for example, recommend using branches for all changes
and using `--no-ff' for merges.  Another way to do so is closer to
what you suggest: allow pushes to happen only on some dev branch, and
only someone else (a human or drdr or whatever) can merge them to the
master.

But all of these are pretty impractical to expect at the beginning.
Therefore, I think that the best way to do the move (which is similar
to the cvs->svn move in the past) is to continue working as usual, let
people get gradually more comfortable with git, and when everyone is
up to speed on that, then we can see what can be done on the process
side to improve things.

BTW, one thing that is a bit more svn-centric is the release process
-- with an early branch and cherry-picking commits into it, and
finally turning it into a tag.  I'm going to do exactly the same thing
here, for the same reason -- my guess is that after 2-3 releases it
will become clear if this works out fine or not, and if not then what
should change.


On Apr 17, Carl Eastlund wrote:
> On Sat, Apr 17, 2010 at 4:22 PM, Noel Welsh <noelwelsh at gmail.com> wrote:
> > On Sat, Apr 17, 2010 at 9:20 PM, Carl Eastlund <cce at ccs.neu.edu> wrote:
> >> DrDr were automatically promoting any non-bug-introducing changes
> >> into milestone as soon as possible
> >
> > This.
> 
> That's tenable as an idea, but I'm not sure we're "there" yet.
> There are components DrDr doesn't test, some kinds of bugs we have
> to ignore to get sanity (all the "changes"), and the system often
> gets many hours behind.

+1


> Besides, I don't know that we should rely on DrDr to do our thinking
> for us.  Why do we need a "dev" repository between users and
                                  ^(branch)^
> "milestone", if people can commit locally and run relevant tests
> before pushing to... well, to whatever we're calling the version
> people pull from?

"master"


> Running the relevant tests oneself, fixing if necessary, then
> pushing once done, is faster overall than pushing to DrDr, waiting
> for it to catch up, build everything, test everything, and notify,
> before figuring out if a fix can go to milestone.

You have some weird terminology like "pushing to drdr" instead of to
some branch[*]...  But +1 overall.  Furthermore: I expect that in a
few months some people will have personal stories to tell on how they
do their workflow -- so we'll have some gallery of ideas to compare
and maybe promote to "the recommended" or even "the enforced"
workflow.

[*] Either that or a weird idea like everyone pushing to a repo on
drdr, and have it forward changes...


On Apr 17, Noel Welsh wrote:
> On Sat, Apr 17, 2010 at 9:28 PM, Carl Eastlund <cce at ccs.neu.edu> wrote:
> > That's tenable as an idea, but I'm not sure we're "there" yet.  There
> > are components DrDr doesn't test, some kinds of bugs we have to ignore
> > to get sanity (all the "changes"), and the system often gets many
> > hours behind.
> 
> My suggestion: move to the UK. DrDr is always pretty snappy when the
> US is asleep :)

(That's probably right not only because the US is sleeping, but
because people tend to do more commits later in the day, so even in
the UK evenings you won't see much drdr loads...)


> Basically I don't have enough nor the same experience of developing
> the PLT trunk so I'm just throwing out the ideas. I can't accurately
> judge the cost/benefit ratio 'cause I don't do this stuff everyday.

IMO, the bottom line is not not spend any cycles on that before we get
to actually know what we're doing.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!