develooper Front page | perl.bootstrap | Postings from July 2000

Re: Voting/Decision making guidelines

Thread Previous | Thread Next
From:
Steve Fink
Date:
July 25, 2000 11:04
Subject:
Re: Voting/Decision making guidelines
Message ID:
397DD6A2.BCE45483@digital-integrity.com
Chris Nandor wrote:
> 
> At 17:33 +0100 2000.07.25, Tim Bunce wrote:
> >On Tue, Jul 25, 2000 at 10:57:34AM -0400, Dan Sugalski wrote:
> >> At 10:44 AM 7/25/00 -0400, Chris Nandor wrote:
> >> >At 14:42 +0100 2000.07.25, Hugo wrote:
> >> > >people realising it before it is too late. I think this is one thing
> >> > >that the voting may have been intended to address - "hey folks, this
> >> > >may be the _last_ chance to make your views known" - but I think it
> >> > >is probably not the best way. If the RFC approach is done right, I
> >> > >think it can solve this problem: for that, I think a) there needs to
> >> > >be a way to say 'notify me when the RFC text changes', and b) the text
> >> > >of the RFC needs to be updated (among other occasions) when consensus
> >> > >starts to emerge but before any final decision is taken.
> >> >
> >> >Excellent ideas.  That way people don't have to monitor mailing lists just
> >> >so they can keep an eye out for when something that they know interests
> >> >them is going to come along.
> >>
> >> In which case it might be useful to have some means of automatic
> >> notification when an RFPC (or one of its children) changes. A mutant
> >> mailing list, or website signup thing or something.
> >
> >Perforce can do that automatically. Maybe cvs/sourceforge can as well.
> 
> Aha, this is what I was hoping for.  SourceForge can't AFAIK, though there
> are probably add-ons to CVS that can.  But in any event, yes, this would be
> Cool.  Probably have special (read-only) mailing lists for each document or
> group of documents, and updates for that document go to the mailing list,
> making subscribing and unsubscribing simple.

If it ends up being CVS, I volunteer for putting it together, seeing as
how I've done it once before. (And don't take that as an endorsement of
CVS -- I dislike the thing.) At my company, I've set up a system that
chooses which list of addresses to send patches to based on the module
and a regex match on the full path of each committed file. (It's perl,
so you can use whatever you want.) CVS tries to make it hard, but I've
worked around most of the problems. CVS screws up quoting, its locking
mechanism gets in the way, and its operations are unnecessarily
restricted, but it can be 95% tamed.

But from what I've heard of Perforce, it sounds like a better tool.

What I'd like in a change management system is for everyone in the world
to be able to update, modify the latest code, and commit their changes
into a playpen. If we're lucky, then maybe be able to use a pool of
diverse Sourceforge machines to run make test all over the place. Then
ask the change mgmt system to generate the patch in a standard format,
with an id. Then we'll always know what version anything is patched
against, the patches can be shared with anyone, and we can group them
into big change sets and talk about them like they're alive and
slobbering all over the couch in the living room.

But maybe this is premature/offtopic?

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About