10:16 a.m.
I'm not sure what purpose the remote branches origin/<username> should
fulfill. Branch names should always be associated with some task. (E.g.,
origin/JBRULES-2858 for fixing that one.)
Continuing work, from time to time, on a long-lived branch is bound to be
tricky and probably confusing to other team members.
-W
7:38 a.m.
Imo, topic branches should be local
or remote on a fork.
i dont think we should litter reference with remote topic branches.
it should only have release branches.
look at hibernate on github.
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/git-branches-origin-u...
Sent from the Drools - Dev mailing list archive at Nabble.com.
7:49 a.m.
OK, locally I can do whatever. But how am I supposed to get my work up to
remote and master? Merge locally and then push?
10+ years with CM in my organisation have shown us that branched work is
best integrated into the main (master) branch by some coordinating CM role.
But Drools isn't being developed according to some standard Development Life
Cycle.
-W
On 3 January 2011 14:38, ge0ffrey <ge0ffrey.spam(a)gmail.com> wrote:
Imo, topic branches should be local
or remote on a fork.
i dont think we should litter reference with remote topic branches.
it should only have release branches.
look at hibernate on github.
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/git-branches-origin-u...
Sent from the Drools - Dev mailing list archive at Nabble.com.
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
7:25 a.m.
But Drools isn't being developed according to some standard
Development Life Cycle.
Not true, but the development process should be documented
more. See
/README.txt
We have plenty of things already set-up. Most recently we defined they
idea focusing on "branch day" instead of "release day".
Feel free to open discussions on any other improvements we should do:
you're right there's much to do. But 1 at a time please, so people can
adjust to them.
Next thing is the split-up of the build and repositories (if possible).
After that we'll look into a lieutenant git model per repository, which
is basically the coordination CM role you speak of :)
Op 03-01-11 14:49, Wolfgang Laun schreef:
OK, locally I can do whatever. But how am I supposed to get my work
up
to remote and master? Merge locally and then push?
10+ years with CM in my organisation have shown us that branched work
is best integrated into the main (master) branch by some coordinating
CM role. But Drools isn't being developed according to some standard
Development Life Cycle.
-W
On 3 January 2011 14:38, ge0ffrey <ge0ffrey.spam(a)gmail.com
<mailto:ge0ffrey.spam@gmail.com>> wrote:
Imo, topic branches should be local
or remote on a fork.
i dont think we should litter reference with remote topic branches.
it should only have release branches.
look at hibernate on github.
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/git-branches-origin-u...
Sent from the Drools - Dev mailing list archive at Nabble.com.
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
9:56 a.m.
On 14 January 2011 14:25, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com> wrote:
But Drools isn't being developed according to some standard
Development
Life Cycle.
Not true, but the development process should be documented more. See
/README.txt
Well... Basically, we agree ;-)
We have plenty of things already set-up. Most recently we defined
they idea
focusing on "branch day" instead of "release day".
Feel free to open discussions on any other improvements we should do:
you're right there's much to do. But 1 at a time please, so people can
adjust to them.
A recent exchange with Edson/IRC has brought up a "howto" for the full
branch - change - push cycle. I'm collecting...
Next thing is the split-up of the build and repositories (if possible).
Ah, a consummation. Devoutly to be wish'd!
After that we'll look into a lieutenant git model per repository,
which is
basically the coordination CM role you speak of :)
Great.
-W
5096
days inactive
5108
days old
4 comments
3 participants
participants (3)
-
ge0ffrey -
Geoffrey De Smet
-
Wolfgang Laun