[os-engineering] FW: [os-infrastructure]Re:Model discussionboiled dry(er)

[Bodo Bergmann]

Steve,

I really like your proposal.

As said before, I'm more interested in getting the processes right
than the tools to use.
If the "community" branch is in another SCM rather than in Piccolo,
I can live with it (even if it means to use different tools for
enterprise & community development).
The main point is to allow the community to add their features in the
"community" trunk
(where all the community projects & releases are branched from)

We still have to find out how the Empire development fits into it,
but I'm sure Durwin can cope with it. :)
The Empire branches are just in Piccolo right now,
as we want to test the processes - which is independent of the SCM used
-
and we don't want to work on both fronts - processes and tools - at the
same time.
Get the processes right - then select the tool that can cope with it.
We also don't have the time right now to change all our Empire build
scripts to SVN
(also given the tools decision has not been made yet).

Bodo.

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Stephen Ball
Sent: Friday, June 27, 2008 2:32 AM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Cc: Open Source Engineering
Subject: RE: [os-engineering] FW: [os-infrastructure]Re:Model
discussionboiled dry(er)

Nice job on the diagram Ray. After being barraged with over 50 e-mails
overnight I was about to suggest we did something like this. It will
also clarify our situation for any conf call we have with members of
other projects.

It seems to me that the details on how/when we synch can be ironed out
in the implementation, as long as we know that both "immediate" and
"delayed" are theoretically possible with any model we propose. Since
how and when we synch doesn't affect the fundamentals of how we branch
various code-lines, it's something we can change our minds about at any
time anyway, so I think we should leave it out of the argument for the
time being so that we don't confuse matters further. 

Leaving "synch" out, there are currently two fundamental proposals on
the table; it would be good to see the diagram for proposal 2 (sorry Ray
I know you have a tone of stuff to do), because I think there is a
variation on proposal 2 which we might call proposal 3.

PROPSAL 3:
----------
is that "main" is exactly mirrored into "main/trunk" in our open source
code manager (for sake of simplicity I'll call it Subversion), and then
we take a full branch in Subversion called "community"; as with proposal
2, "community" is allowed to diverge from "trunk" and we may or may not
take the results back into "trunk" and therefore back into "main" in
piccolo. There will be very different rules about who can submit to
"community" and who can submit to "trunk", we may even restrict
committer access to "trunk" to Ingres employees. In principal, this
model is identical to the community "proposal 2" except that the
community branch exists in Subversion and not in piccolo;
diagrammatically it looks similar to "proposal 1" though. It satisfies
the needs of the people that want the "fedora" model whilst not having
the extra branch in piccolo. 

Before anyone jumps on this, I am not advocating that this proposal is
any better or worse than the other proposals, but it is another way of
serving the community/fedora model, and it does have a different looking
diagram to the other 2 proposals, so we should consider it. One of the
key differences it brings is that it allows the "fedora" model whilst
providing the community browse access to the "enterprise" version, which
resides on "trunk", although they may not be able to commit to that
branch. So the question is, if we decide on the Fedora model, do we want
the community to be able to browse the enterprise source using a code
management system? Some might argue that the GNU license compels us to
do this (I'm not one of those people).

For what it's worth; I was on the fence over this, but I have to say
that I am now favoring the "Fedora" model in some form or another....I
know I may never want to see the contents of "Project D" in my
enterprise code-line, but it's a really cool idea, and I don't see why
it shouldn't be folded into some community edition. *BUT* I have to say
that cross-branch integration needs to get a whole lot better in
Subversion in order for the fedora model to work well.

Steve


-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Chris Clark
Sent: Friday, June 27, 2008 2:18 AM
To: opensource-infrastructure at lists.ingres.com
Cc: Open Source Engineering
Subject: Re: [os-engineering] FW: [os-infrastructure] Re:Model
discussionboiled dry(er)

On 6/26/2008 9:04 AM, Alex Hanshaw wrote:
>  ....Ray has put together a diagram of
> model a) as a discussion point. I'm sure this list will see the detail
> once some initial refinement has been made. OpenROAD are aware.
>   

This is now ready for prime time at 
http://community.ingres.com/wiki/Community_Model I would like to suggest

a rule/guideline for this page, you only post what you know is the 
proposal. Discussion should talk place in this list, phone, IM, two tin 
cans and string. Avoiding cruft on the wiki page is going to be useful.

Currently we have "Proposal 1" -- which I *think* is the fresh/stale 
(a/b) options that Andrew put out as initial ideas. This does not 
discuss timing of syncs (or even what/how this is done) so maybe we need

1.a, 1.b.

We need a buffer example, and I we need the OpenROAD proposal up too 
(which is different code lines than ingres!main).

RE Proposal 1 - we need to start to iron the procedure, I'm not talking 
about avn hooks, piccolo hooks, etc. I'm thinking, what is sync'd this 
isn't not (cannot) be a straight sync of the tree. For instance the 
gateway dir (ingres!main!generic!gateway) is in there and this is closed

source, I think we have some (provate) signed keys in another dir in 
main etc. Luckily these are in specific directories so I think we are 
talking about limiting the syncs to only dirs - but we need consensus on

this and we need to document it! :-)

I think Proposal 1 has an implicit, "no closed source" restriction in 
the dirs that are synchronized - is this the vision for this proposal? 
Is this wrong! Lets flesh out the proposals (and get example use cases).

A big thanks to Ray for creating the image, it is IMHO much better than 
an ASCII diagram and very clear.

Chris

_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure