Index: [Article Count Order] [Thread]

Date:  Sun, 9 Mar 2008 17:15:13 -0400
From:  Brian <brian-list (at mark) comcast.net>
Subject:  [coba-e:12217] Re: PWDB and Dovecot...  [Friendly reminder about the mailing list rules]
To:  coba-e (at mark) bluequartz.org
Message-Id:  <EAEEE9C3-A2D9-4C2E-9507-FA4133CC998F (at mark) comcast.net>
In-Reply-To:  <BAY129-DAV87A675CED9C1E2F616E50CA0D0 (at mark) phx.gbl>
References:  <BAY129-DAV11BA311E49C6F1BC925713CA130 (at mark) phx.gbl> <004d01c880c1$6e1b1050$1e64a8c0 (at mark) nuonce.net> <BAY129-DAV1FA40D1C9A98086C083ADCA0C0 (at mark) phx.gbl> <200803091224.38935.bq (at mark) solarspeed.net> <BAY129-DAV131992BFDC46DD61A2253FCA0D0 (at mark) phx.gbl> <E89EC653-7C40-4C29-993B-D80E1D3943FA (at mark) comcast.net> <BAY129-DAV87A675CED9C1E2F616E50CA0D0 (at mark) phx.gbl>
X-Mail-Count: 12217


On Mar 9, 2008, at 4:01 PM, Zeffie wrote:

> so have at it and feel free to let me know if there is something  
> else I need to be building..  I really enjoy building rpms and one  
> of the main reasons I've gone public this list is so I could find  
> some more interesting things to build.

But to revisit the portion I don't see addressed--- changes to the  
base install, like updating to a current proftpd, if those go into  
the base source as a commit, then the project grows, is increased in  
stability and reliability, and contributions are cohesive and there  
aren't worries about stepping on pieces of code here and there (this  
all comes down to a consensus about how to do things in the end, any  
collaborated project does that).

I think that the benefits of this would go a long way and the issues  
that made this thread go where it has would, simply, not be issues.   
Do you see that would help everything relating to the project, your  
own efforts, and everyones customer base?   I see it :)

My personal preferences:  I'd not mind seeing more things available  
to the base as an rpm, and the "vendors" charging something to make  
thing more convenient (added to UI, whatever).  Those who have some  
background and want to add things to the backend by installing from  
RHEL/ CentOS rpms or building from stated RHEL/ CentOS-compatible  
source could do so without concern about BQ-specific changes  
elsewhere causing unexpected behavior Those who are reselling lots to  
users could pay for the convenience and UI fanciness that *their*  
customers appreciate.  I think it would make the base that much  
better, avoid duplication of effort, and allow both the base and the  
BQ UI to grow much more rapidly than it has to date.

B