[os-infrastructure] Accepting (or rejecting) user contributions into piccolo ingres!main and or community branches

[Jay Hankinson]

Chris raises a very good point here and I think this illustrates the 
need for a distinction between an SVN branch which syncs between 
community and enterprise (currently referred to as "community main 
(mirror)" in Ray's diagram) and a "main" branch for community 
development (hence force referred to as "comdev") which is used in much 
the same way main in piccolo is used during our current "enterprise" 
development cycle.

I can only talk from an Ingres perspective (wrt the sprint) but the VM 
we setup included an SVN client pulling from the main branch and the 
intention was/is is to submit ALL the projects back to this branch and 
eventually pull them into the enterprise product. However, if we follow 
the current diagram layout, the only way this is possible is to create a 
"sprint branch" and apply the changes as diffs (which we have) and 
commit there. Otherwise, all the changes would be pulled into 
piccolo-main and this is probably going to be met with some resistance. 
(Although I would argue that virtually everything will be wanted in the 
Enterprise product line).

What would make more sense (IMO, and I believe this is also the essence 
of what Steve suggested) would be to create a "comdev" branch from 
"community main" and mandate that form this point on there is no direct 
development in "community main" and that "comdev" becomes the point for 
main line community development.

J
Chris Clark wrote:
> Something that came up whilst chatting off line with Ralph; the code 
> sprint in the UK should have a number of excellent real world (small 
> project) use cases to talk about. We have a number of Ingres projects 
> and OpenROAD ones to look at (ideally all of them).
>
> Can anyone who is/was involved with the code sprints in the UK talk 
> about how that was(/is being)  handled? E.g. were branches made, or 
> were patches generated with "svn diff"? How are the changes going to 
> get into main (are they going to get into main or do we not want them).
>
> Chris
>
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure