Commit approvals on core

Contrary to what some may have heard, there is no approval
required from 
anyone to commit to either the 1x or 2x core.

Our primary request is that commits are not pushed to any
repository 
until changes being worked on are are complete.

We do encourage people to work in local branches, however
this is not an 
explicit policy.


~ Dracos
_______________________________________________
Xaraya_devel mailing list
Xaraya_develxaraya.com
http:
//xaraya.com/mailman/listinfo/xaraya_devel

On 2 nov 2007, at 05:27, Marty Vance wrote:

> Our primary request is that commits are not pushed to
any repository
> until changes being worked on are are complete.

Can you elaborate on this a bit? How does that work in
practice?


> We do encourage people to work in local branches,
however this is  
> not an
> explicit policy.

I'd rather have people push their branches to mt.xaraya.com
as  
scenarios, even when changes are incomplete. Theoretically
people can  
pull sideways from every repository, but this requires
developers to  
set up a monotone server, typically not what they spent
their time on.

If stuff is pushed to the 'xaraya monotone server' (properly
branched  
and named obviously) exposure of their work is much larger
and  
involvement and review is much easier.

marcel

-- 
Marcel van der Boom -- http://hsdev.com/mvdb.vcf
HS-Development BV   -- http://www.hsdev.com
So! webapplicaties  -- http://make-it-so.info



_______________________________________________
Xaraya_devel mailing list
Xaraya_develxaraya.com
http:
//xaraya.com/mailman/listinfo/xaraya_devel

Marcel van der Boom wrote:

> I'd rather have people push their branches to
mt.xaraya.com as 
> scenarios, even when changes are incomplete.
Theoretically people can 
> pull sideways from every repository, but this requires
developers to set 
> up a monotone server, typically not what they spent
their time on.
> 
> If stuff is pushed to the 'xaraya monotone server'
(properly branched 
> and named obviously) exposure of their work is much
larger and 
> involvement and review is much easier.
> 
Seems like an interesting idea. I'd have 3 concerns:
1. The potential profusion of scenarios in the repos. Is
there a way of 
removing them once they are no longer needed?

2. Can the infrastructure handle it? There have been a lot
of downtimes 
lately, sometimes for hours.  Is there someone managing the
repos that 
could handle the larger number of dbs?

3. What would the ground rules be for managing these
things?

Perhaps worth pursuing.

Marc
_______________________________________________
Xaraya_devel mailing list
Xaraya_develxaraya.com
http:
//xaraya.com/mailman/listinfo/xaraya_devel

On 2 nov 2007, at 23:04, marcinmilanxaraya.com wrote:

> Seems like an interesting idea. I'd have 3 concerns:
> 1. The potential profusion of scenarios in the repos.
Is there a way  
> of
> removing them once they are no longer needed?
>
Removing no, declaring it as 'unused' possibly. (i saw that
feature  
flying by recently in .36 or .37, will have to check) Once a
revision  
is created, it's there to stay for it's children.


> 2. Can the infrastructure handle it? There have been a
lot of  
> downtimes
> lately, sometimes for hours.  Is there someone managing
the repos that
> could handle the larger number of dbs?

I share your concern on the managing part. Technically the 

infrastructure is capable of handling it, but it's a bit of
high  
maintenance (relatively speaking) as we work with all the
cutting edge  
versions of viewmtn/trac/mtn-plugin/monotone. I'm not paying
as much  
attention to the server as i used to do in the past.

Not sure how many scenarios you have in mind, but i dont
think the  
number of databases would need to grow (assuming an open
environment  
for reading) In fact, i'm contemplating putting everything
into one  
database, instead of 4 to make things simpler.


> 3. What would the ground rules be for managing these
things?

One ground rule would be that people would invest some time
in  
monotone to grok what it is about. I have seen a lot of
'rowing  
against the stream' in the past, which is a pity.

Other than that, not many exciting stuff, unless we want to
have many  
tracs.
The mt.xaraya.com server would serve up the 'com.xaraya.*'
scope. The  
server would be configured to let anything in (and out) in
that scope.  
Given that a person connecting has a valid key and can put
new  
revisions into the remote database, that is about it.

Perhaps trivial, but another groundrule is thus: the branch
is part of  
the 'com.xaraya.*' scope.

After rereading i get the feeling you interpreted my message
as  
something like 'mtn hosting for *any* branch related to
xar'?

My concern was 'dont push until finished' is less likely to
work than  
'once committed locally and properly scoped, push
everywhere' IMHO


marcel

-- 
Marcel van der Boom -- http://hsdev.com/mvdb.vcf
HS-Development BV   -- http://www.hsdev.com
So! webapplicaties  -- http://make-it-so.info



_______________________________________________
Xaraya_devel mailing list
Xaraya_develxaraya.com
http:
//xaraya.com/mailman/listinfo/xaraya_devel