postfixadmin-devel

[Postfixadmin-devel] PFA v3

[Rudi F. <rud...@go...>]

[translation into german on request]
Hallo Christian,

ich denke die art wie wir unser svn nutzen stößt an seine grenzen. Für
die ganzen ideen wie wir einpflegen wollen, müssten wir nur in branches
entwickeln, bzw. bugfixes durchführen und mit tags releases festhalten.
Nicht nur in trunk entwickeln. Entweder wir strukturieren die arbeit in
svn um, oder wir wechseln zu Git wenn das auf sourceforge schon möglich ist.

Desweiteren würde ich fragen wie es mit der entwicklung für PFA3 aussieht?
Würde dafür gerne dann eine neue branch in svn oder in git einen neuen
context starten. Generell schon mal eine todo anfangen.
Mag zwar ein langer weg werden, aber einige Ziele sind ja schon da
(einige aus meinem privaten wunsch sammelsorium), wie
*trennung von Model und Controller
*trennung der db functionen aus der functions.php
*generell nur noch kleine hilfsfunktionen in der functions.php aufbewahren.
*neues pfad system, um das mvc konzept bestmöglich auszunutzen.
*von usern eingepflegte spalten. (stichwort CCK in drupal)
*besseres setup, mit automatischer setup.php creation.
*upgrade von 2.2 und 2.3 evntl. 2.4 wenn es raus ist.
*verbesserte unterstützung von PFA-CLI
*etc.

Was sagst du dazu?

Würd mich über eine antwort freuen.

Re: [Postfixadmin-devel] PFA v3

[David G. <da...@co...>]

Rudi Floren wrote :
> [translation into german on request]

Don't care about German, English would be kind of cool, given the
subject...

thanks
David.


> Hallo Christian,
> 
> ich denke die art wie wir unser svn nutzen stößt an seine grenzen. Für
> die ganzen ideen wie wir einpflegen wollen, müssten wir nur in branches
> entwickeln, bzw. bugfixes durchführen und mit tags releases festhalten.
> Nicht nur in trunk entwickeln. Entweder wir strukturieren die arbeit in
> svn um, oder wir wechseln zu Git wenn das auf sourceforge schon möglich ist.
> 
> Desweiteren würde ich fragen wie es mit der entwicklung für PFA3 aussieht?
> Würde dafür gerne dann eine neue branch in svn oder in git einen neuen
> context starten. Generell schon mal eine todo anfangen.
> Mag zwar ein langer weg werden, aber einige Ziele sind ja schon da
> (einige aus meinem privaten wunsch sammelsorium), wie
> *trennung von Model und Controller
> *trennung der db functionen aus der functions.php
> *generell nur noch kleine hilfsfunktionen in der functions.php aufbewahren.
> *neues pfad system, um das mvc konzept bestmöglich auszunutzen.
> *von usern eingepflegte spalten. (stichwort CCK in drupal)
> *besseres setup, mit automatischer setup.php creation.
> *upgrade von 2.2 und 2.3 evntl. 2.4 wenn es raus ist.
> *verbesserte unterstützung von PFA-CLI
> *etc.
> 
> Was sagst du dazu?
> 
> Würd mich über eine antwort freuen.
> 
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel

-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] PFA v3

[Rudi F. <rud...@go...>]

ohhh sry. I meant english^^


First the structure of our svn project.
Normally you add features in trunk. At a point where it runs without
errors you start a new branch. You solve bugs in this branch an merge it
into trunk. If you have a new bugfree Version you release a tag.
The problem is that we have many branches for each version instead of
branches for 2.1, 2.3 and  2.4.

We have to fix our svn structure or use something mor modular like git.


Another point is the start of a 3.0 branch.
The main goals are:
*Split handlers in  model and controller
*extract db function into special db layer.
*refactoring of function.inc.php. It should only have helper functions
like array_remove etc.
*new path system for support the mvc concept as good as possible.
*user defined fields in database and backend. (see: CCK in drupal 6)
*better setup, with automatic config.local.php creation
*better support of PFA-CLI
*upgrade from 2.2, 2.3 and 2.4 to 3.0
*some feature request in our tracker

What do you think?

Should we create a 3.0 branch?
greets Rudi




Am 06.03.2011 13:41, schrieb David Goodwin:
> Rudi Floren wrote :
>> [translation into german on request]
> Don't care about German, English would be kind of cool, given the
> subject...
>
> thanks
> David.
>
>
>> Hallo Christian,
>>
>> ich denke die art wie wir unser svn nutzen stößt an seine grenzen. Für
>> die ganzen ideen wie wir einpflegen wollen, müssten wir nur in branches
>> entwickeln, bzw. bugfixes durchführen und mit tags releases festhalten.
>> Nicht nur in trunk entwickeln. Entweder wir strukturieren die arbeit in
>> svn um, oder wir wechseln zu Git wenn das auf sourceforge schon möglich ist.
>>
>> Desweiteren würde ich fragen wie es mit der entwicklung für PFA3 aussieht?
>> Würde dafür gerne dann eine neue branch in svn oder in git einen neuen
>> context starten. Generell schon mal eine todo anfangen.
>> Mag zwar ein langer weg werden, aber einige Ziele sind ja schon da
>> (einige aus meinem privaten wunsch sammelsorium), wie
>> *trennung von Model und Controller
>> *trennung der db functionen aus der functions.php
>> *generell nur noch kleine hilfsfunktionen in der functions.php aufbewahren.
>> *neues pfad system, um das mvc konzept bestmöglich auszunutzen.
>> *von usern eingepflegte spalten. (stichwort CCK in drupal)
>> *besseres setup, mit automatischer setup.php creation.
>> *upgrade von 2.2 und 2.3 evntl. 2.4 wenn es raus ist.
>> *verbesserte unterstützung von PFA-CLI
>> *etc.
>>
>> Was sagst du dazu?
>>
>> Würd mich über eine antwort freuen.
>>
>> ------------------------------------------------------------------------------
>> What You Don't Know About Data Connectivity CAN Hurt You
>> This paper provides an overview of data connectivity, details
>> its effect on application quality, and explores various alternative
>> solutions. http://p.sf.net/sfu/progress-d2d
>> _______________________________________________
>> Postfixadmin-devel mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel

Re: [Postfixadmin-devel] PFA v3

[Christian B. <pos...@cb...>]

Hello,

Am Sonntag, 6. März 2011 schrieb Rudi Floren:
> ohhh sry. I meant english^^

*g*

> First the structure of our svn project.
> Normally you add features in trunk. At a point where it runs without
> errors you start a new branch. You solve bugs in this branch an merge
> it into trunk. If you have a new bugfree Version you release a tag.
> The problem is that we have many branches for each version instead
> of branches for 2.1, 2.3 and  2.4.

> We have to fix our svn structure 

Yes, we have accidently tagged some releases into branches/ instead of 
tags/. Yes, we have to fix the svn structure.

Don't be surprised if you see lots of "svn mv" commit messages in the 
next hours or days...

> or use something mor modular like git.

Switching to git would cause some problems for us - for example 
upgrade.php depends on the SVN revision number to work. I'm sure there 
are ways how to do something similar in git (date?), but "never change a 
running system" applies here IMHO. We have other areas where investing 
time is more useful.

> Another point is the start of a 3.0 branch.
> The main goals are:
> *Split handlers in  model and controller

Can you give an example how such a split would look like?
I'm not too deep in the MVC theory, so this slightly sounds like 
buzzwords to me ;-)

> *extract db function into special db layer.

Define "layer", please.
Regarding OOP: As long as it makes things easier for us and/or for the 
users. See my answer to "About Trunk version" for the long version.

> *refactoring of function.inc.php. It should only have helper
> functions 

Agreed. A split by functionality (database, helper functions, ...) would 
be a good idea. The current functions.inc.php with 2500+ lines is only 
maintainable if you search for the function name...

For doing the actual split, we should "svn cp" functions.inc.php to a 
new name and then remove the lines that should no longer be in the 
respective file. This is slightly more work than just moving code to a 
new file, but has the advantage of not breaking svn history. (The svn 
history has helped me more than once to understand why some code was 
written the way it is.)

So the question is: Which parts should we split out and how should we 
name the file? I'd say:
- database specific functions (db_*)
- validation functions (like check_email)
- maybe: functions for the web interface (TODO: textarea_to_array)

I intentionally skipped the filename part because I have no better idea 
than db_functions.php for now ;-) - proposals?

> like array_remove etc.

Good example - with a TODO tag attached *g*

> *new path system for support the mvc concept as good as possible.

I'm open for proposals.

> *user defined fields in database and backend. (see: CCK in drupal 6)

I'd say "see fetchmail.php" (or model/DomainHandler for an unfinished 
class-based version of it). We just need to provide a hook so that the 
field array ($struct) can be modified from the config.

The only thing that can't be handled by changing the $struct array is 
using custom validation functions for a field - in this case a new class 
based on a model/* with the function added would be the way to go. (That 
would probably affect 1% of the "custom field" cases - most requests we 
got until now didn't require special validation.)

> *better setup, with automatic config.local.php creation

Sounds like a good idea - but also like lots of work...
If we do this, we should also support a versioned config so that it's 
possible to ask just for the new config options.

> *better support of PFA-CLI

Obviously. It's still unfinished.

> *upgrade from 2.2, 2.3 and 2.4 to 3.0

We already have that - see upgrade.php :-)  (included by setup.php)
IIRC it can even upgrade from 2.1...

> *some feature request in our tracker

Indeed, there are some good ideas in there.

I'd like to add another one:
* Invent days with more than 24 hours ;-))


Regarding "3.0 branch": I'm against it and the reason is simple: 
IMHO trunk is our "3.0 branch". We should finish all the things we have 
started there (CLI, model/*, use model/* from web interface, ...).
Creating a separate 3.0 branch would only lead to superfluous merge 
work.
When we do the 3.0 final release, we can/should of course create a 3.0.x 
branch that is handled similar to the 2.3 branch is now (only bugfixes).

As far as I can tell (I still use 2.3.x on my production servers) the 
current status of trunk is useable if you can accept some minor bugs. 
Compared to 2.3.x we already have some added features, even if some of 
them are incomplete.

Therefore I'd propose to do 2.9.x [1] releases (as in "beta" or "3.0 
preview") regularly to enable users to use the already finished parts, 
but with a clear note [2] that they have to expect small bugs and 
incomplete implementation of the new features.

We should also continue to maintain the 2.3 branch (only bugfixes, no 
new features) until we release 3.0 final for people that prefer 
stability over new features.


Regards,

Christian Boltz

[1] The reason for 2.9.x instead of "3.0 beta" is the easier handling of
    the version number in RPM (and probably DEB) because 2.9.x < 3.0,
    but "3.0 beta1" or "3.0 preview1" is hard to compare to "3.0".
    Even if we decide to use "3.0 previewX", I'll have to package it as 
    2.9.x to avoid update problems - so we should also use 2.9.x for the 
    tarballs ;-)

[2] AFAIK Sourceforge can display a README directly on the download page
-- 
> Als Vanilla werden die ungepatchten LinuxKernel bezeichnet die es
> z.B. bei http://www.kernel.org gibt.
Genau. Sozusagen ein Kernel ohne Aroma. Ich hatte den 2.4.19-pre7 
probiert, der schmeckt nur nach Kernel - und geht. 
[> Markus Kolb und Jörg Lippmann in suse-linux]

Re: [Postfixadmin-devel] PFA v3

[David G. <da...@co...>]

> 
> Another point is the start of a 3.0 branch.
> The main goals are:
> *Split handlers in  model and controller
> *extract db function into special db layer.
> *refactoring of function.inc.php. It should only have helper functions
> like array_remove etc.
> *new path system for support the mvc concept as good as possible.
> *user defined fields in database and backend. (see: CCK in drupal 6)
> *better setup, with automatic config.local.php creation
> *better support of PFA-CLI
> *upgrade from 2.2, 2.3 and 2.4 to 3.0
> *some feature request in our tracker
> 
> What do you think?

A better idea would be to support e.g. exim as well.... but I have no knowledge of exim.



David.

Re: [Postfixadmin-devel] PFA v3

[Rudi F. <rud...@go...>]

Here is an german schema of an exim database.
http://developer.gauner.org/ispmail-exim/
we only need the config files. our database schema is right.

Should be part of our ExampleConfig Wiki Category.
Am 07.03.2011 03:30, schrieb David Goodwin:
>> Another point is the start of a 3.0 branch.
>> The main goals are:
>> *Split handlers in  model and controller
>> *extract db function into special db layer.
>> *refactoring of function.inc.php. It should only have helper functions
>> like array_remove etc.
>> *new path system for support the mvc concept as good as possible.
>> *user defined fields in database and backend. (see: CCK in drupal 6)
>> *better setup, with automatic config.local.php creation
>> *better support of PFA-CLI
>> *upgrade from 2.2, 2.3 and 2.4 to 3.0
>> *some feature request in our tracker
>>
>> What do you think?
> A better idea would be to support e.g. exim as well.... but I have no knowledge of exim.
>
>
>
> David.
>