What about our webapp policy draft?

[Alexis Sukrieh]

Hi there,

Our Draft begins to be quite complete I think, I'd like to know what
remains to be done, to you, in order to have something good enough for a
first "stable" preview.

I think we should follow the good work in order to be able to show to the r
est of the project what we have in hands.

I'd like to know also if you think that a "Debian Webapp Team" could be
a good thing. I'm currently maintaining Bugzilla and have real
difficulties to keep my package up-to-date with security fixes when
upstream drop support (this sadly happens quickly in Mozilla's side).

I was wondering if such a team could be set up in order to maintain in a
collaborative way a couple of packages.

We already have the mailing list, the IRC channel and the alioth
project, all we need is energy and volunteers.

This idea just came out of my mind, feel free to comment on it.

Cheers,

Alexis.

[sean finney]

hi alexis,

nice to see some voices on the list again :)

Post by Alexis Sukrieh
Our Draft begins to be quite complete I think, I'd like to know what
remains to be done, to you, in order to have something good enough for a
first "stable" preview.

from my point of view, these are the next few steps:

- get more "outside eyes" reading over the document for review. mainly
i'd like to see at least one of the apache team sign off on it,
as they have a vested interest in seeing this work as well.
- get more work done on the webapps-common package to actually
implement this stuff.
- after webapps-common is in a releasable state, we could start lobbying
people to use it.
- after people start using it, we could start lobbying the developers'
reference to mention us.
- after the developers' ref mentions us (or in parallel to the above) we
could then start lobbying the policy peeps.

Post by Alexis Sukrieh
I'd like to know also if you think that a "Debian Webapp Team" could be
a good thing. I'm currently maintaining Bugzilla and have real
difficulties to keep my package up-to-date with security fixes when
upstream drop support (this sadly happens quickly in Mozilla's side).

i think for simple drop-and-go webapps this might be of help, but for
anything of significant complexity, i don't know that it will get us
much. with lots of the more complicated webapps you have to be
familiar with what it does and how to use it to be fully effective
at packaging.


sean

--

[Alexis Sukrieh]

Post by sean finney
- get more "outside eyes" reading over the document for review. mainly
i'd like to see at least one of the apache team sign off on it,
as they have a vested interest in seeing this work as well.

As I used to package an inoffical flavor of apache (apache-lingerd) I
know a few members of the apache maintainers, I'm going to contact them
for a first review.

Post by sean finney
- get more work done on the webapps-common package to actually
implement this stuff.

I'm willing to help for this, could you point me to the right place to
look at?

Post by sean finney
- after webapps-common is in a releasable state, we could start lobbying
people to use it.
- after people start using it, we could start lobbying the developers'
reference to mention us.
- after the developers' ref mentions us (or in parallel to the above) we
could then start lobbying the policy peeps.

Sounds good.

Post by sean finney

Post by Alexis Sukrieh
I'd like to know also if you think that a "Debian Webapp Team" could be
a good thing. I'm currently maintaining Bugzilla and have real
difficulties to keep my package up-to-date with security fixes when
upstream drop support (this sadly happens quickly in Mozilla's side).

i think for simple drop-and-go webapps this might be of help, but for
anything of significant complexity, i don't know that it will get us
much. with lots of the more complicated webapps you have to be
familiar with what it does and how to use it to be fully effective
at packaging.

I agree with you, on complex issues, only someone familiar with the
package can fix them. But there are several common issues when we are
about "webapps", and I think a team can efficiently fix them.

This team could also provide an "expert" point of view for
reviewing/sponsoring new webapp packages.

Regards,

Alexis.
--
Alexis Sukrieh <***@sukria.net>
0x1EE5DD34
Debian http://www.debian.org
Backup Manager http://www.backup-manager.org

[Alexis Sukrieh]

Post by sean finney
- get more "outside eyes" reading over the document for review. mainly
i'd like to see at least one of the apache team sign off on it,
as they have a vested interest in seeing this work as well.

Sadly my mail posted on debian-apache didn't catch any feedback...

Post by sean finney
- get more work done on the webapps-common package to actually
implement this stuff.

I grabbed the CVS repository and took a look at the bits. It looks great
but I must say I'm a bit puzzled, I don't where to start to give a hand.
Sean, can you enlighten me? ;)
--
Alexis Sukrieh <***@sukria.net>
0x1EE5DD34
Debian http://www.debian.org
Backup Manager http://www.backup-manager.org

[David Johnson]

I am quite pleased with the policy draft. I just finished compiling our
large web application with many different components and pieces into a
Debian package with the help of this document. I used nearly every portion
of the document and found it to be extremely helpful and well thought out.

Installing a large application of this type is very demanding and frequently
has numerous configuration challenges.

-----Original Message-----
Sent: Thursday, March 16, 2006 9:27 AM
Subject: Re: What about our webapp policy draft?

Post by sean finney
- get more "outside eyes" reading over the document for review. mainly
i'd like to see at least one of the apache team sign off on it,
as they have a vested interest in seeing this work as well.

Sadly my mail posted on debian-apache didn't catch any feedback...

Post by sean finney
- get more work done on the webapps-common package to actually
implement this stuff.

I grabbed the CVS repository and took a look at the bits. It looks great
but I must say I'm a bit puzzled, I don't where to start to give a hand.
Sean, can you enlighten me? ;)
--
0x1EE5DD34
Debian http://www.debian.org
Backup Manager http://www.backup-manager.org
--
with a subject of "unsubscribe". Trouble? Contact

[Neil McGovern]

Post by Alexis Sukrieh

Post by sean finney
- get more "outside eyes" reading over the document for review. mainly
i'd like to see at least one of the apache team sign off on it,
as they have a vested interest in seeing this work as well.

Sadly my mail posted on debian-apache didn't catch any feedback...

Post by sean finney
- get more work done on the webapps-common package to actually
implement this stuff.

I grabbed the CVS repository and took a look at the bits. It looks great
but I must say I'm a bit puzzled, I don't where to start to give a hand.
Sean, can you enlighten me? ;)

IMO, this should be a priority. The actual policy seems more or less
finished, and I'd like to send it to -project soon for a wider audience
to comment.

Neil

[sean finney]

hi folks,

Post by Alexis Sukrieh
Sadly my mail posted on debian-apache didn't catch any feedback...

that's too bad. i'll give it a try in the next week as well
to see if i can have any better luck :)

Post by Alexis Sukrieh
I grabbed the CVS repository and took a look at the bits. It looks great
but I must say I'm a bit puzzled, I don't where to start to give a hand.
Sean, can you enlighten me? ;)

it'd probably be best to meet up over im/irc to discuss this. i'll
send you my info privately.

Post by Alexis Sukrieh
I am quite pleased with the policy draft. I just finished compiling our
large web application with many different components and pieces into a
Debian package with the help of this document. I used nearly every portion
of the document and found it to be extremely helpful and well thought out.

thanks for the feedback, it's appreciated :)

Post by Alexis Sukrieh
IMO, this should be a priority. The actual policy seems more or less
finished, and I'd like to send it to -project soon for a wider audience
to comment.

sure. hopefully the S:N ratio is a little better there than it
is on -devel right now...


sean

--

[Matt Brown]

Post by Alexis Sukrieh
Hi there,
Our Draft begins to be quite complete I think, I'd like to know what
remains to be done, to you, in order to have something good enough for a
first "stable" preview.

One thing I've had on my TODO list for the PHPwiki package for a while
is to look at vhosts and how these are handled by the system.

Is there an existing policy or framework for this? Is it an apache
specific issue?

The problem is that when installing a package on a machine that has been
configured with virtual hosting, dropping a configuration snippet
into /etc/apache2/conf.d/ is not likely to have the desired effect. Some
method of choosing which vhost the user wants the package to appear in
and then making that work is required.

Has anything been done in this area that I am not aware of?

Cheers

[Alexis Sukrieh]

Post by Matt Brown
One thing I've had on my TODO list for the PHPwiki package for a while
is to look at vhosts and how these are handled by the system.
Is there an existing policy or framework for this? Is it an apache
specific issue?

We just speak quickly of the "vhosts" feature in our draft, be we could
provide much more information about it:

http://webapps-common.alioth.debian.org/draft/html/ch-httpd.html#s-httpd-virtual

Post by Matt Brown
The problem is that when installing a package on a machine that has been
configured with virtual hosting, dropping a configuration snippet
into /etc/apache2/conf.d/ is not likely to have the desired effect. Some
method of choosing which vhost the user wants the package to appear in
and then making that work is required.

Automatically enabling vhosts is something difficult and dangerous to do.
Remeber that the code snippet you will put under the conf.d directory is
a conffile, thus you must not overwrite it or remove it silently.

Moreover, if you want to automate that, you have to support apache2
layout as well, that means putting the vhost conffile under
/etc/apache2/site-available, make a symlink in
/etc/apache2/site-enabled...

For the bugzilla package, the smooth solution I chose was to speak about
virtual hosting in README.Debian and point the user to vhost conffiles
located under `/usr/share/bugzilla/examples'.

The user just have to copy/paste the code located there where *he* wants,
restart his web server and he's done.

I would advice you do to do so, it's safer than trying to do everything
within postinst.

Note that you have to make sure people can set up multiple vhosts of
your package, to do so each vhosts should read its conffile and not
interfere with another instance.

I'v achieved this goal in Bugzilla thanks to mod_env, I look for
`X_BUGZILLA_SITE' in the environment and use that variable to know where
my conffile is located.

Refer to the bugzilla source package for details.

Good luck,

Alexis.
--
Alexis Sukrieh <***@sukria.net>
0x1EE5DD34
Debian http://www.debian.org
Backup Manager http://www.backup-manager.org

[sean finney]

hi guys,

Post by Matt Brown
One thing I've had on my TODO list for the PHPwiki package for a while
is to look at vhosts and how these are handled by the system.
Is there an existing policy or framework for this? Is it an apache
specific issue?

i think the actual configuration process will be apache specific,
though we can perhaps abstract some level of behavior to be
more general as well.

Post by Matt Brown
The problem is that when installing a package on a machine that has been
configured with virtual hosting, dropping a configuration snippet
into /etc/apache2/conf.d/ is not likely to have the desired effect. Some
method of choosing which vhost the user wants the package to appear in
and then making that work is required.

i think unless you're shooting to solve the Big Problem, your best
bet is to assume that your application is being installed under
a subdirectory, but at the same time make sure that it will also
function as a virtual host as well (and perhaps provide examples
and docs for how to do it the other way).

Post by Matt Brown
Has anything been done in this area that I am not aware of?

there's some stuff in webapps-common in CVS, but it hasn't seen the
light of day (or my editor) for a few months :)

Post by Matt Brown

Post by sean finney
- get more "outside eyes" reading over the document for review. mainly
i'd like to see at least one of the apache team sign off on it,
as they have a vested interest in seeing this work as well.

As I used to package an inoffical flavor of apache (apache-lingerd) I
know a few members of the apache maintainers, I'm going to contact them
for a first review.

that would be really welcome. i would say the support of the apache
peeps is a pre-requisite for any progress relating to making this
an official policy.

Post by Matt Brown

Post by sean finney
- get more work done on the webapps-common package to actually
implement this stuff.

I'm willing to help for this, could you point me to the right place to
look at?

sure. currently the webapps-common module in CVS has the source
for a webapps-common package which iirc is already somewhat functional.
also in the source is an examples directory, in which you can build
some example packages as proof of concept.

Post by Matt Brown
I agree with you, on complex issues, only someone familiar with the
package can fix them. But there are several common issues when we are
about "webapps", and I think a team can efficiently fix them.

right.

Post by Matt Brown
This team could also provide an "expert" point of view for
reviewing/sponsoring new webapp packages.

this is definitely a good idea. as progress in other areas is
made, i think getting our name out to the right groups will be
beneficial for this. for example, in addition to the
developers' reference there's the new maintainers' guide, and likewise,
letting the dd's who help out in debian-newmaint know of our existance
would probably be welcomed as we could help field some of the webapp
related questions for them.


sean