[os-infrastructure] Model discussion boiled down

Jay Hankinson jeremy.hankinson at ingres.com
Wed Jun 25 16:18:29 PDT 2008


I'm have to admit, I'm a little surprised this particular conversation 
is happening at all. We have huge job ahead to us to try build a 
community around Ingres and OpenROAD without forcing outside users to 
learn a completely new source code management system to do so. Having 
been piccolo development and support for the passed 7 years or so I can 
say without any hesitance, the biggest single issue I see from new users 
(and current for that matter) is grasping the concept of map files and 
subscription lists. It might work well in the well defined (and usually 
pre-setup) confines of our build environments but how many people on 
this list could setup a piccolo build environment from scratch? Even 
with all the critisim leveled at SVN (and I'm not a huge fan of it 
myself), I would hazard a guess there are more of you that could get 
going on subversion than piccolo. In my opinion it is just plain not 
suited for use in the environment we are trying to grow. Subversion may 
not the answer, but neither is piccolo.

However, in the interests of fair and open discussion (and that is 
really what we need to focus on) here is the beginnings of a list of 
things that would need to be addressed in piccolo before it would be 
suitable for community use. Fell free to add to it (or dispute it for 
that matter).

J

 - Web client or at very least some sort of publicly readable access
 - Proper user authentication for committing, probably over ssl
 - Hooks into IDEs (at very least Eclipse and  OpenRoad)
 - Hooks into a bugs tracking system (or you can add give bugs web 
access too)
 - Make client stateless
    - The repository currently holds every version of every file on 
every client ever created (and not unsubscribed). For ad-hoc public 
downloads this clearly won't scale. The "have" table in the database is 
the main source of contention
    - You currently need to be connected to the server to do anything. 
open, rcompare etc.
 - Generally improve performance and stability
 - Universal diff output


Joe Abbate wrote:
> Hi Andrew,
>
> Andrew Ross wrote:
>> At the moment, no one is signed up to develop piccolo to be appropriate
>> for community. If someone wants to fight for that great, but let's be
>> mindful of what else they could be doing other than developing a tool we
>> can easily get for free.
>
> I'm reminded of Heinlein's TANSTAAFL. Piccolo is already developed and 
> is even "freer" than Subversion. We already have 50 or perhaps more 
> developers that are familiar with Piccolo and all its quirks and 
> nuances. Some have even gone as far as creating a layer of scripts 
> that makes submissions and integrations easier or that pinpoint 
> changes that have not been cross-integrated into a given codeline.
>
> I understand that external contributors may find Piccolo 
> uncomfortable, but is that the only reason to discard it as a 
> solution? Or what about its close cousin Perforce which can be used 
> for free for open source projects? External contributors may also find 
> Jam uncomfortable (like some of us do), but like it or not, it does 
> work portably on the platforms we support.
>
> If we think Piccolo is not appropriate for community projects, why not 
> start with a list of items that would make it appropriate?
>
> Joe
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure



More information about the opensource-infrastructure mailing list