You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@commons.apache.org by Greg Stein <gs...@lyra.org> on 2002/11/04 20:17:26 UTC
Re: Moving serf to commons?
On Mon, Nov 04, 2002 at 12:42:24AM -0800, Justin Erenkrantz wrote:
> Does anyone want to spearhead moving apr-serf to commons?
>
> While I want to move it, I don't have the necessary karma/knowhow to
> do that, and I'd rather spend what little time I do have to spend on
> serf writing more code. (Next on my list is deflate support.)
>
> So, do we have any volunteers? =) -- justin
I can definitely do it, but Aaron's being a butthead with a -1 saying it
doesn't fit the Commons' goals :-) Aaron: if you say "no", then what still
needs to happen to define those goals? Help out here, so we can get
component adoption going. I believe Peter wants to start shifting a bunch of
Avalon components, too. There may be some J-C guys, too.
But about serf specifically, I haven't seen votes on it from Ken, Jim, or
Geir. We also don't seem to have a solid consensus on CVS organization or
mailing lists.
Hmm. Maybe we should use Subversion? We could certainly not worry about
directory organization in that case. We'd lose CVS history, though, since we
can't blend multiple CVS repositories over time. i.e. we could use cvs2svn
for an initial set, but future additions would lose history since we
couldn't "blend" them into an existing repos.
[grrr...]
I think it is time to stop dicking around, complete the Commons' mission
statement, and start getting some work done.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Moving serf to commons?
Posted by Justin Erenkrantz <je...@apache.org>.
--On Monday, November 04, 2002 11:17:26 -0800 Greg Stein <gs...@lyra.org>
wrote:
> Hmm. Maybe we should use Subversion? We could certainly not worry about
> directory organization in that case. We'd lose CVS history, though, since
> we can't blend multiple CVS repositories over time. i.e. we could use
> cvs2svn for an initial set, but future additions would lose history since
> we couldn't "blend" them into an existing repos.
I would personally be a strong +1 for using Subversion for serf. I think
Subversion is ready for a trial run here within the ASF.
That said, I'm going to stay the heck out of this policy debate. I want to
see serf move to commons, but I'm not going to waste my breath arguing over
it. I've stated my position, and I'd rather spend my time improving the
code. -- justin
Re: Moving serf to commons?
Posted by Justin Erenkrantz <je...@apache.org>.
--On Monday, November 04, 2002 11:17:26 -0800 Greg Stein <gs...@lyra.org>
wrote:
> Hmm. Maybe we should use Subversion? We could certainly not worry about
> directory organization in that case. We'd lose CVS history, though, since
> we can't blend multiple CVS repositories over time. i.e. we could use
> cvs2svn for an initial set, but future additions would lose history since
> we couldn't "blend" them into an existing repos.
I would personally be a strong +1 for using Subversion for serf. I think
Subversion is ready for a trial run here within the ASF.
That said, I'm going to stay the heck out of this policy debate. I want to
see serf move to commons, but I'm not going to waste my breath arguing over
it. I've stated my position, and I'd rather spend my time improving the
code. -- justin
Re: Moving serf to commons?
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 04, 2002 at 11:43:43AM -0800, Aaron Bannert wrote:
> On Mon, Nov 04, 2002 at 11:17:26AM -0800, Greg Stein wrote:
> > I can definitely do it, but Aaron's being a butthead with a -1 saying it
> > doesn't fit the Commons' goals :-)
>
> Naw, that's not true, I'm not saying it doesn't fit the goals. I'm
> saying we don't have goals to fit.
Yah, I know. But you're saying serf can't / shouldn't move because of a lack
of goals. So what is missing from Commons' goals? We've got a number of
items decided, and it seems that serf fits into those items.
IOW, what is the delta from here to >there< such that you feel Commons has a
well (enough) defined goals/mission?
> > Aaron: if you say "no", then what still
> > needs to happen to define those goals?
>
> That's easy:
>
> 1) APR needs to finalize its mission
Screw the APR mission. As Ryan pointed out, the serf project has decided
independently that it wants to move. Feel free to discuss the APR mission
with serf as a measuring stick, but the APR mission no longer has any
bearing on serf's move.
> 2) Commmons needs to finalize its mission (or have something final enough
> to start accepting things like Serf)
Take a look at the current STATUS doc. Vote where you haven't, and if the
mission isn't finalized enough, then please clarify. I don't know what
actions to take to move towards clarity.
> > Help out here, so we can get
> > component adoption going.
>
> I'd like to see Commons create an "HTTP Utilities Component" and figure
> out what that can mean.
This is your idea, so go ahead and push it :-)
I'd say "go ahead and shift serf" and when you have your concept defined,
then we wrap it around serf. IOW, does the definition need to impede the
operational aspects of moving the serf codebase?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Moving serf to commons?
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 04, 2002 at 11:43:43AM -0800, Aaron Bannert wrote:
> On Mon, Nov 04, 2002 at 11:17:26AM -0800, Greg Stein wrote:
> > I can definitely do it, but Aaron's being a butthead with a -1 saying it
> > doesn't fit the Commons' goals :-)
>
> Naw, that's not true, I'm not saying it doesn't fit the goals. I'm
> saying we don't have goals to fit.
Yah, I know. But you're saying serf can't / shouldn't move because of a lack
of goals. So what is missing from Commons' goals? We've got a number of
items decided, and it seems that serf fits into those items.
IOW, what is the delta from here to >there< such that you feel Commons has a
well (enough) defined goals/mission?
> > Aaron: if you say "no", then what still
> > needs to happen to define those goals?
>
> That's easy:
>
> 1) APR needs to finalize its mission
Screw the APR mission. As Ryan pointed out, the serf project has decided
independently that it wants to move. Feel free to discuss the APR mission
with serf as a measuring stick, but the APR mission no longer has any
bearing on serf's move.
> 2) Commmons needs to finalize its mission (or have something final enough
> to start accepting things like Serf)
Take a look at the current STATUS doc. Vote where you haven't, and if the
mission isn't finalized enough, then please clarify. I don't know what
actions to take to move towards clarity.
> > Help out here, so we can get
> > component adoption going.
>
> I'd like to see Commons create an "HTTP Utilities Component" and figure
> out what that can mean.
This is your idea, so go ahead and push it :-)
I'd say "go ahead and shift serf" and when you have your concept defined,
then we wrap it around serf. IOW, does the definition need to impede the
operational aspects of moving the serf codebase?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Moving serf to commons?
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Nov 04, 2002 at 11:17:26AM -0800, Greg Stein wrote:
> I can definitely do it, but Aaron's being a butthead with a -1 saying it
> doesn't fit the Commons' goals :-)
Naw, that's not true, I'm not saying it doesn't fit the goals. I'm
saying we don't have goals to fit.
> Aaron: if you say "no", then what still
> needs to happen to define those goals?
That's easy:
1) APR needs to finalize its mission
2) Commmons needs to finalize its mission (or have something final enough
to start accepting things like Serf)
> Help out here, so we can get
> component adoption going.
I'd like to see Commons create an "HTTP Utilities Component" and figure
out what that can mean.
> I believe Peter wants to start shifting a bunch of
> Avalon components, too. There may be some J-C guys, too.
>
> But about serf specifically, I haven't seen votes on it from Ken, Jim, or
> Geir. We also don't seem to have a solid consensus on CVS organization or
> mailing lists.
>
> Hmm. Maybe we should use Subversion? We could certainly not worry about
> directory organization in that case. We'd lose CVS history, though, since we
> can't blend multiple CVS repositories over time. i.e. we could use cvs2svn
> for an initial set, but future additions would lose history since we
> couldn't "blend" them into an existing repos.
>
>
> [grrr...]
>
> I think it is time to stop dicking around, complete the Commons' mission
> statement, and start getting some work done.
+1
-aaron
Re: Moving serf to commons?
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Nov 04, 2002 at 11:17:26AM -0800, Greg Stein wrote:
> I can definitely do it, but Aaron's being a butthead with a -1 saying it
> doesn't fit the Commons' goals :-)
Naw, that's not true, I'm not saying it doesn't fit the goals. I'm
saying we don't have goals to fit.
> Aaron: if you say "no", then what still
> needs to happen to define those goals?
That's easy:
1) APR needs to finalize its mission
2) Commmons needs to finalize its mission (or have something final enough
to start accepting things like Serf)
> Help out here, so we can get
> component adoption going.
I'd like to see Commons create an "HTTP Utilities Component" and figure
out what that can mean.
> I believe Peter wants to start shifting a bunch of
> Avalon components, too. There may be some J-C guys, too.
>
> But about serf specifically, I haven't seen votes on it from Ken, Jim, or
> Geir. We also don't seem to have a solid consensus on CVS organization or
> mailing lists.
>
> Hmm. Maybe we should use Subversion? We could certainly not worry about
> directory organization in that case. We'd lose CVS history, though, since we
> can't blend multiple CVS repositories over time. i.e. we could use cvs2svn
> for an initial set, but future additions would lose history since we
> couldn't "blend" them into an existing repos.
>
>
> [grrr...]
>
> I think it is time to stop dicking around, complete the Commons' mission
> statement, and start getting some work done.
+1
-aaron
Re: Moving serf to commons?
Posted by Peter Donald <pe...@apache.org>.
On Tue, 5 Nov 2002 07:59, Greg Stein wrote:
> Oh... just thought of one thing. While the commit date gets shifted to a
> non-standard date property, the converted tags would be correct. If
> somebody was interested in "avalon component FOO, v0.6", then they could go
> to (say) /tags/avalon-FOO/0.6 and see the component as it was at that tag.
> It is only by-date querying that we lose.
>
> [ but we could easily build a tool to do the query on the alternate date
> property. for example:
>
> $ get-rev avalon-commit-date 'Nov 2, 2000'
> 4772
> $
That works for me. Mostly we just want the tags and dates are sugar. I will
ask on Avalon if anyone objects when the time comes.
--
Cheers,
Peter Donald
"Artists can color the sky red because they know it's blue. Those of us who
aren't artists must color things the way they really are or people might
think we're stupid." -- Jules Feiffer
Re: Moving serf to commons?
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Nov 05, 2002 at 07:42:12AM +1100, Peter Donald wrote:
> On Tue, 5 Nov 2002 06:17, Greg Stein wrote:
>...
> > We could certainly not worry about
> > directory organization in that case. We'd lose CVS history, though, since
> > we can't blend multiple CVS repositories over time. i.e. we could use
> > cvs2svn for an initial set, but future additions would lose history since
> > we couldn't "blend" them into an existing repos.
>
> that would suck! Hmmm .. no way at all to do this? Even hand hacking the db or
> something?
Oh, cvs2svn can convert any number of repositories, and jam them all into a
single SVN repository. Later on, you could convert some more and add them to
the repository. The problem that arises is that the revisions are no longer
time-ordered. (the additional set could have commits from before the first
set) It turns the question of "give me the revision for <this> date" into a
linear search problem :-(
If we had the components up front, then we'd do one big-ass conversion of
the CVS repositories, and all the revisions for the components' commits
would be interleaved. It is when you migrate components later on...
Of course, you *could* add components later if you're all right with
revision numbers changing on the resulting repository (through revamping the
existing repos to interleave the new component). But that would suck hard.
In practice, we use revision numbers like tags or reference points in
discussion. e.g. "fixed in rev 2632" or "svn 0.14.3 is /trunk at rev 3200"
If the revision number changes for some logical/semantic revision, then all
those references are horked.
Hmm. It could be possible to add components later on if we didn't worry
about their original commit date. We could retain the history, but lose the
dates. (well, we could record the dates in a non-standard date property for
reference, but something like 'svn co -r {nov 2, 2000} ...' would not work)
Oh... just thought of one thing. While the commit date gets shifted to a
non-standard date property, the converted tags would be correct. If somebody
was interested in "avalon component FOO, v0.6", then they could go to (say)
/tags/avalon-FOO/0.6 and see the component as it was at that tag. It is only
by-date querying that we lose.
[ but we could easily build a tool to do the query on the alternate date
property. for example:
$ get-rev avalon-commit-date 'Nov 2, 2000'
4772
$
(where 4772 has a standard date of the time of the repos conversion)
]
For serf, we don't care about history. For more-developed components,
especially those with releases, it could be very useful to retain the
history.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Moving serf to commons?
Posted by Peter Donald <pe...@apache.org>.
On Tue, 5 Nov 2002 06:17, Greg Stein wrote:
> I can definitely do it, but Aaron's being a butthead with a -1 saying it
> doesn't fit the Commons' goals :-) Aaron: if you say "no", then what still
> needs to happen to define those goals? Help out here, so we can get
> component adoption going. I believe Peter wants to start shifting a bunch
> of Avalon components, too.
Yep. Expect a proposal of about 15 components once the gates open ;)
> Hmm. Maybe we should use Subversion?
That would be great!
> We could certainly not worry about
> directory organization in that case. We'd lose CVS history, though, since
> we can't blend multiple CVS repositories over time. i.e. we could use
> cvs2svn for an initial set, but future additions would lose history since
> we couldn't "blend" them into an existing repos.
that would suck! Hmmm .. no way at all to do this? Even hand hacking the db or
something?
> I think it is time to stop dicking around, complete the Commons' mission
> statement, and start getting some work done.
+1
--
Cheers,
Peter Donald
-----------------------------------------------
"You can't depend on your eyes when your
imagination is out of focus." -Mark Twain
-----------------------------------------------