You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Maxime Petazzoni <ma...@bulix.org> on 2006/02/10 01:22:22 UTC
Upcoming changes in mod_mbox repository
Hi,
It's been long since I last tried to release v0.2 of mod_mbox, without
success. The bug fixed tonight made me focus again on mod_mbox and I
really would like to see things changing and moving on.
Recently, I've been working on cleaning up the directory structure of
the module's source code in a 'surgery' branch. Today, this work is
done and the branch's code compiles, installs and works fine here at
home. Please not that the functionnal code is the same as in mod_mbox
trunk/, including tonight's bugfix.
mod_mbox still needs a lot of improvements as shown in the STATUS file.
But since current code is mostly what came out my Summer of Code, I
would like to see it released before continuing.
Before releasing mod_mbox, we need the work done in the surgery branch
back to trunk. So, unless there is any objections to it, here it what
I'll do in the next few days :
- Move the scripts/ directory one level up, outside of the branches/
tags/ trunk/ directory shema. These scripts are not part of the
module's source code, they do not need to be under it's versionning
(they're not even include in releases anyways).
- Merge the surgery branch back to trunk
- Create a 0.2.1 tarball and call for a vote on releasing it.
In the best case, mod_mbox-0.2.1 will finally come out and I'll continue
hacking on the module ASAP.
Regards,
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
Re: Upcoming changes in mod_mbox repository
Posted by Maxime Petazzoni <ma...@bulix.org>.
* Justin Erenkrantz <ju...@erenkrantz.com> [2006-02-11 11:53:40]:
> automake doesn't work. The solution is to revert Paul's commit that
> introduces automake. (Paul should really be the one doing this - not
> you - since he started this mess and promised that he'd revert it way
> back when.)
>
> I'm not trying to be a stick in the mud, but if we want to rearrange
> the source trees, then the build system should be fixed too. automake
> *usually* requires all sources to be in the src/ dir - that's why you
> can't really rearrange the directory layout to make sense without
> first removing automake. It's a chicken and egg thing. -- justin
http://skikda-dev.bulix.org/archives/httpd/dev/
This is the surgery branch, compiled with automake and without an src/
directory. I don't know why, but something is telling me that this
*work*.
Regads,
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
Re: Upcoming changes in mod_mbox repository
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 2/14/06, Maxime Petazzoni <ma...@bulix.org> wrote:
> Otherwise, I'd like to have some more detailled explanations (or a mail
> reference to) on this veto.
http://mail-archives.apache.org/mod_mbox/httpd-mbox-dev/200504.mbox/%3c20050416063918.GQ29417@scotch.ics.uci.edu%3e
HTH. -- justin
Re: Upcoming changes in mod_mbox repository
Posted by Maxime Petazzoni <ma...@bulix.org>.
* William A. Rowe, Jr. <wr...@rowe-clan.net> [2006-02-11 17:10:36]:
> >Why not simply ./automake and check in the resulting ./autoconf-ready
> >files? If you desire to delete the automake files afterwards, th
>
> ...at's fine. It's how we migrated the incubating mod_ftp out of automake.
> Of course more work on mod_ftp's build system is still needed, but at least
> automake is out of the picture.
If you're willing to keep an easy way of managing the build, the
automake files still need to be part of the repository, and that's not
going to honor the veto on automake.
If you have a solution to this problem, or if you (i'm talking to
everyone here, not just you Bill) have some time to switch the surgery
branch to the httpd build system then shoot.
Otherwise, I'd like to have some more detailled explanations (or a mail
reference to) on this veto.
Regards,
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
Re: Upcoming changes in mod_mbox repository
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> Folks you are talking over each other.
>
> Why not simply ./automake and check in the resulting ./autoconf-ready
> files? If you desire to delete the automake files afterwards, th
...at's fine. It's how we migrated the incubating mod_ftp out of automake.
Of course more work on mod_ftp's build system is still needed, but at least
automake is out of the picture.
[dang touchpad mousebuttons under my wrists lol]
> Bill
>
> Paul Querna wrote:
>
>> Justin Erenkrantz wrote:
>>
>>> On 2/11/06, Paul Querna <ch...@force-elite.com> wrote:
>>>
>>>> If you really want me to revert it I will. Then we won't have any
>>>> build
>>>> system at all.
>>>>
>>>> Maybe you are forgetting what we had before. A single makefile with
>>>> paths hard coded for your home directory.
>>>
>>>
>>>
>>> build-dso was the 'build' system - not Makefile.
>>>
>>>> If you want to convert it to use httpd's build system, no one is
>>>> stopping you.
>>
>>
>>
>> How? svn copy into a branch, make the changes, commit it, tell
>> everyone, merge the branch.
>>
>>>> FWIW, Automake doesn't require everything to be in src/, but it seems
>>>> you are so tainted against the tool (Hey, I don't exactly love it
>>>> either), that it doesn't matter that it currently _does_ work.
>>>
>>>
>>>
>>> We shouldn't be releasing code that has a dependency on automake. --
>>> justin
>>
>>
>>
>> Please define dependency.
>>
>> We have a buildconf dependency on Python in httpd. configure doesn't.
>>
>> Automake is the same as Python in this case.
>
>
>
Re: Upcoming changes in mod_mbox repository
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Folks you are talking over each other.
Why not simply ./automake and check in the resulting ./autoconf-ready files?
If you desire to delete the automake files afterwards, th
Bill
Paul Querna wrote:
> Justin Erenkrantz wrote:
>
>> On 2/11/06, Paul Querna <ch...@force-elite.com> wrote:
>>
>>> If you really want me to revert it I will. Then we won't have any build
>>> system at all.
>>>
>>> Maybe you are forgetting what we had before. A single makefile with
>>> paths hard coded for your home directory.
>>
>>
>> build-dso was the 'build' system - not Makefile.
>>
>>> If you want to convert it to use httpd's build system, no one is
>>> stopping you.
>
>
> How? svn copy into a branch, make the changes, commit it, tell everyone,
> merge the branch.
>
>>> FWIW, Automake doesn't require everything to be in src/, but it seems
>>> you are so tainted against the tool (Hey, I don't exactly love it
>>> either), that it doesn't matter that it currently _does_ work.
>>
>>
>> We shouldn't be releasing code that has a dependency on automake. --
>> justin
>
>
> Please define dependency.
>
> We have a buildconf dependency on Python in httpd. configure doesn't.
>
> Automake is the same as Python in this case.
Re: Upcoming changes in mod_mbox repository
Posted by Paul Querna <ch...@force-elite.com>.
Justin Erenkrantz wrote:
> On 2/11/06, Paul Querna <ch...@force-elite.com> wrote:
>> If you really want me to revert it I will. Then we won't have any build
>> system at all.
>>
>> Maybe you are forgetting what we had before. A single makefile with
>> paths hard coded for your home directory.
>
> build-dso was the 'build' system - not Makefile.
>
>> If you want to convert it to use httpd's build system, no one is
>> stopping you.
How? svn copy into a branch, make the changes, commit it, tell everyone,
merge the branch.
>> FWIW, Automake doesn't require everything to be in src/, but it seems
>> you are so tainted against the tool (Hey, I don't exactly love it
>> either), that it doesn't matter that it currently _does_ work.
>
> We shouldn't be releasing code that has a dependency on automake. -- justin
Please define dependency.
We have a buildconf dependency on Python in httpd. configure doesn't.
Automake is the same as Python in this case.
Re: Upcoming changes in mod_mbox repository
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 2/11/06, Paul Querna <ch...@force-elite.com> wrote:
> If you really want me to revert it I will. Then we won't have any build
> system at all.
>
> Maybe you are forgetting what we had before. A single makefile with
> paths hard coded for your home directory.
build-dso was the 'build' system - not Makefile.
> If you want to convert it to use httpd's build system, no one is
> stopping you.
The presence of automake is.
> FWIW, Automake doesn't require everything to be in src/, but it seems
> you are so tainted against the tool (Hey, I don't exactly love it
> either), that it doesn't matter that it currently _does_ work.
We shouldn't be releasing code that has a dependency on automake. -- justin
Re: Upcoming changes in mod_mbox repository
Posted by Paul Querna <ch...@force-elite.com>.
Justin Erenkrantz wrote:
> On 2/10/06, Maxime Petazzoni <ma...@bulix.org> wrote:
>> Okkaay. Please read again my paragraph. Now please read the STATUS
>> file. The current automake setup *works*, and migrating to the same
>> build system than httpd is planned. If you don't want any mod_mbox
>> release to go out until I find an fscking large piece of time to
>> understand of to get rid of automake -aka in a very, very long time-,
>> just say that, and I wont bother the list again.
>
> automake doesn't work. The solution is to revert Paul's commit that
> introduces automake. (Paul should really be the one doing this - not
> you - since he started this mess and promised that he'd revert it way
> back when.)
If you really want me to revert it I will. Then we won't have any build
system at all.
Maybe you are forgetting what we had before. A single makefile with
paths hard coded for your home directory.
If you want to convert it to use httpd's build system, no one is
stopping you.
> I'm not trying to be a stick in the mud, but if we want to rearrange
> the source trees, then the build system should be fixed too. automake
> *usually* requires all sources to be in the src/ dir - that's why you
> can't really rearrange the directory layout to make sense without
> first removing automake. It's a chicken and egg thing. -- justin
FWIW, Automake doesn't require everything to be in src/, but it seems
you are so tainted against the tool (Hey, I don't exactly love it
either), that it doesn't matter that it currently _does_ work.
-Paul
Re: Upcoming changes in mod_mbox repository
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 2/10/06, Maxime Petazzoni <ma...@bulix.org> wrote:
> Okkaay. Please read again my paragraph. Now please read the STATUS
> file. The current automake setup *works*, and migrating to the same
> build system than httpd is planned. If you don't want any mod_mbox
> release to go out until I find an fscking large piece of time to
> understand of to get rid of automake -aka in a very, very long time-,
> just say that, and I wont bother the list again.
automake doesn't work. The solution is to revert Paul's commit that
introduces automake. (Paul should really be the one doing this - not
you - since he started this mess and promised that he'd revert it way
back when.)
I'm not trying to be a stick in the mud, but if we want to rearrange
the source trees, then the build system should be fixed too. automake
*usually* requires all sources to be in the src/ dir - that's why you
can't really rearrange the directory layout to make sense without
first removing automake. It's a chicken and egg thing. -- justin
Re: Upcoming changes in mod_mbox repository
Posted by Maxime Petazzoni <ma...@bulix.org>.
* Justin Erenkrantz <ju...@erenkrantz.com> [2006-02-10 21:54:27]:
> On 2/10/06, Maxime Petazzoni <ma...@bulix.org> wrote:
> > It works, in a very simple and common way, and changing the build
> > system is not (yet) part of the showstoppers. Please keep in mind that
> > I want this release to be some kind of out-of-SoC release, not a
> > mod-mbox-has-become-the-killer-module one.
>
> To be clear, I've vetoed automake - no release can be done with an
> outstanding veto on a commit. (If I knew how to kick out automake, I
> would.)
Okkaay. Please read again my paragraph. Now please read the STATUS
file. The current automake setup *works*, and migrating to the same
build system than httpd is planned. If you don't want any mod_mbox
release to go out until I find an fscking large piece of time to
understand of to get rid of automake -aka in a very, very long time-,
just say that, and I wont bother the list again.
> > > And, then you can toss the ludicrous src/ directory too. All of the
> > > dirs under src/ should be in the top level.
> >
> > The src/ directory is not ludicrous. It goes in the directory
> > structure logic of splitting sources, includes and data.
>
> No. There should not be a src directory. Do you see one in httpd?
I guess it's here a fight of tastes. Anyway, since it's my call
against everybody else's, this will be done.
> Data is also very ambiguous and gives no hint about what's actually in
> that directory - docroot would probably be the best precendent httpd
> has to offer. -- justin
+1 here, this directory was named quickly at the begining of the
summer and was never touched back. I'll change that.
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
Re: Upcoming changes in mod_mbox repository
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 2/10/06, Maxime Petazzoni <ma...@bulix.org> wrote:
> It works, in a very simple and common way, and changing the build
> system is not (yet) part of the showstoppers. Please keep in mind that
> I want this release to be some kind of out-of-SoC release, not a
> mod-mbox-has-become-the-killer-module one.
To be clear, I've vetoed automake - no release can be done with an
outstanding veto on a commit. (If I knew how to kick out automake, I
would.)
> > And, then you can toss the ludicrous src/ directory too. All of the
> > dirs under src/ should be in the top level.
>
> The src/ directory is not ludicrous. It goes in the directory
> structure logic of splitting sources, includes and data.
No. There should not be a src directory. Do you see one in httpd?
Data is also very ambiguous and gives no hint about what's actually in
that directory - docroot would probably be the best precendent httpd
has to offer. -- justin
Re: Upcoming changes in mod_mbox repository
Posted by Maxime Petazzoni <ma...@bulix.org>.
Hi,
* Justin Erenkrantz <ju...@erenkrantz.com> [2006-02-10 07:54:49]:
> Can you please consider removing automake? (I did -1 it when Paul
> committed automake the first time.)
If you feel brave enough to get a hand on the new build system, feel
free to do so. Personally, I don't know how it works, and I was barely
able to make the autotools do what I want for the surgery branch.
It works, in a very simple and common way, and changing the build
system is not (yet) part of the showstoppers. Please keep in mind that
I want this release to be some kind of out-of-SoC release, not a
mod-mbox-has-become-the-killer-module one.
> And, then you can toss the ludicrous src/ directory too. All of the
> dirs under src/ should be in the top level.
The src/ directory is not ludicrous. It goes in the directory
structure logic of splitting sources, includes and data.
Regards,
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
Re: Upcoming changes in mod_mbox repository
Posted by Bill Stoddard <bi...@wstoddard.com>.
Justin Erenkrantz wrote:
> On 2/9/06, Maxime Petazzoni <ma...@bulix.org> wrote:
>> Recently, I've been working on cleaning up the directory structure of
>> the module's source code in a 'surgery' branch. Today, this work is
>> done and the branch's code compiles, installs and works fine here at
>> home. Please not that the functionnal code is the same as in mod_mbox
>> trunk/, including tonight's bugfix.
>
> (Assuming you mean 'Please note' instead of 'Please not'.)
>
> Can you please consider removing automake? (I did -1 it when Paul
> committed automake the first time.) And, then you can toss the
> ludicrous src/ directory too. All of the dirs under src/ should be in
> the top level.
>
+1
> If we keep automake, don't ever expect me to contribute to mod_mbox's
> build. I refuse to look at automake build systems. So, if it doesn't
> build out-of-the-box on my systems, I won't be able to test it and
> give a +1 for release. =)
yep.
>
> Thanks. -- justin
>
>
>
Re: Upcoming changes in mod_mbox repository
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 2/9/06, Maxime Petazzoni <ma...@bulix.org> wrote:
> Recently, I've been working on cleaning up the directory structure of
> the module's source code in a 'surgery' branch. Today, this work is
> done and the branch's code compiles, installs and works fine here at
> home. Please not that the functionnal code is the same as in mod_mbox
> trunk/, including tonight's bugfix.
(Assuming you mean 'Please note' instead of 'Please not'.)
Can you please consider removing automake? (I did -1 it when Paul
committed automake the first time.) And, then you can toss the
ludicrous src/ directory too. All of the dirs under src/ should be in
the top level.
If we keep automake, don't ever expect me to contribute to mod_mbox's
build. I refuse to look at automake build systems. So, if it doesn't
build out-of-the-box on my systems, I won't be able to test it and
give a +1 for release. =)
Thanks. -- justin
Re: Upcoming changes in mod_mbox repository
Posted by Maxime Petazzoni <ma...@bulix.org>.
* Maxime Petazzoni <ma...@bulix.org> [2006-02-12 01:50:38]:
> Expect for the automake problem, I already made the necessary changes
> to the surgery branch to comply with justin's will (aka not having an
> src/ directory and renaming data/ to docroot/).
s/Expect/Except/
Too late out there, need some rest.
'Night all!
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
Re: Upcoming changes in mod_mbox repository
Posted by Maxime Petazzoni <ma...@bulix.org>.
Hi,
* Maxime Petazzoni <ma...@bulix.org> [2006-02-10 01:22:22]:
> Before releasing mod_mbox, we need the work done in the surgery branch
> back to trunk. So, unless there is any objections to it, here it what
> I'll do in the next few days :
>
> - Move the scripts/ directory one level up, outside of the branches/
> tags/ trunk/ directory shema. These scripts are not part of the
> module's source code, they do not need to be under it's versionning
> (they're not even include in releases anyways).
> - Merge the surgery branch back to trunk
> - Create a 0.2.1 tarball and call for a vote on releasing it.
Now that we punched each other in the face about automake, could we
please move on ? I still want to work on mod_mbox, but as I said
several times before I would really like to make a release before
continuing.
Expect for the automake problem, I already made the necessary changes
to the surgery branch to comply with justin's will (aka not having an
src/ directory and renaming data/ to docroot/).
I know there's things in there that need to be changed, updated,
enhanced and we won't be able to go anywhere if we keep arguing like
this. Yes, automake is not easy to use and maintain. Yes, we must
switch to the same build system than httpd, but is it really the
matter of this release ? I don't believe so.
Shall we move on ?
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.