Re: [squid-core] v3 roadmap

2008-03-23 Thread Alex Rousskov
On Sun, 2008-03-23 at 15:24 +1300, Amos Jeffries wrote:
 Henrik Nordstrom wrote:
  On Wed, 2008-03-19 at 11:15 +1300, Amos Jeffries wrote:
  
- I'm kind of in favour of it as a pure file-movements-only 
  alteration.  3.2 has no feature-requests yet and back-porting across a 
  file-re-arranged setup is likely to be more trouble than its worth.
  
  bzr tracks renames and merges changes across them fine. bzr operates
  using abstract file identifiers, separate from the file names.
  
  you only run into trouble from tree reshuffles if you split/merge files,
  or don't tell bzr that you are renaming a file.. 
  
  bzr help mv
  
 
 Well, in light of that I don't have any objections to starting the 
 re-ordering now.

OK. My plan is to publish the first eCAP-related changes for review and
then start working on a cleanup patch.

 I'd like to be closely involved though to get my head around the changes.

Sure. Please review the source cleanup feature and raise any objections.
I will start with the big changes already listed there, I guess.

Let's move further discussions, if any to squid-dev.

Thank you,

Alex.




Re: [squid-core] v3 roadmap

2008-03-22 Thread Amos Jeffries

Henrik Nordstrom wrote:

On Wed, 2008-03-19 at 11:15 +1300, Amos Jeffries wrote:

  - I'm kind of in favour of it as a pure file-movements-only 
alteration.  3.2 has no feature-requests yet and back-porting across a 
file-re-arranged setup is likely to be more trouble than its worth.


bzr tracks renames and merges changes across them fine. bzr operates
using abstract file identifiers, separate from the file names.

you only run into trouble from tree reshuffles if you split/merge files,
or don't tell bzr that you are renaming a file.. 


bzr help mv



Well, in light of that I don't have any objections to starting the 
re-ordering now.


I'd like to be closely involved though to get my head around the changes.

Amos
--
Please use Squid 2.6STABLE17+ or 3.0STABLE1+
There are serious security advisories out on all earlier releases.


Re: [squid-core] v3 roadmap

2008-03-18 Thread Amos Jeffries

Amos Jeffries wrote:

Alex Rousskov wrote:

On Wed, 2008-03-19 at 00:25 +1300, Amos Jeffries wrote:


I'm looking forward a few weeks to 3.0.STABLE3 by march 31st


Great!


Possibly even a 3.1.DEVEL0 at the same time.


This should probably be discussed on squid-dev, but there are currently
several projects on the TODO list that may not be committed until March
31st. There is even a project with unknown ETA, which is a violation of
the TODO list definition!

Also, what about the /Features/SourceLayout cleanup project? Should that
wait for 3.2?

Finally, if we have the resources to include a few missing Squid2
features into Squid3, should v3.1 wait for that?


Our initial agreed time-plan called for an initial release around 31 
March. I was thinking PRE at that time, but as Henrik suggested there is 
DEVEL for feature-incomplete releases to keep things relatively to plan.


Hopefully we can ge the PRE1 out sooner, but any release of the for 
wider testing on time is better than long delays.


For the unknown, thats fixed. I'm sponsoring it. But have not heard back 
from Adrian whether he wants to take the money and do it to be added to -3.


Amos


Oops, meat to do the squid-dev move on that.

As for the cleanup...

.h cleanup:
 - going in next time I have a spare minute to check for tweaks.

The file re-arranging polish:
 - I'm kind of in favour of it as a pure file-movements-only 
alteration.  3.2 has no feature-requests yet and back-porting across a 
file-re-arranged setup is likely to be more trouble than its worth.
 - If you think you can get it done in a reasonable timespan to get 
done by the RC releases great. I don't think the PRE need to wait for 
it, its polish after all not a true feature.

 - It is your baby though.

If you have the resources to move a few 2.6 features to 3.1 they should 
be timelined by 31 March or officially shifted to 3.2 pending later 
re-evaluation. Yes?

 - I've added the LogDaemon as one such, I can do at a pinch.

Amos
--
Please use Squid 2.6STABLE17+ or 3.0STABLE1+
There are serious security advisories out on all earlier releases.


Re: [squid-core] v3 roadmap

2008-03-18 Thread Alex Rousskov
On Wed, 2008-03-19 at 11:15 +1300, Amos Jeffries wrote:

 The file re-arranging polish:
   - I'm kind of in favour of it as a pure file-movements-only 
 alteration.  3.2 has no feature-requests yet and back-porting across a 
 file-re-arranged setup is likely to be more trouble than its worth.

Can you clarify the above? I am not disagreeing, but am not sure whether
you are saying we should move/rename files in 3.1.

   - If you think you can get it done in a reasonable timespan to get 
 done by the RC releases great. I don't think the PRE need to wait for 
 it, its polish after all not a true feature.
   - It is your baby though.

Understood.

 If you have the resources to move a few 2.6 features to 3.1 they should 
 be timelined by 31 March or officially shifted to 3.2 pending later 
 re-evaluation. Yes?

Agreed. I am still evaluating what needs to be ported and whether the
Factory can sponsor any of that.

Thank you,

Alex.




Re: [squid-core] v3 roadmap

2008-03-18 Thread Henrik Nordstrom
On Wed, 2008-03-19 at 11:15 +1300, Amos Jeffries wrote:

   - I'm kind of in favour of it as a pure file-movements-only 
 alteration.  3.2 has no feature-requests yet and back-porting across a 
 file-re-arranged setup is likely to be more trouble than its worth.

bzr tracks renames and merges changes across them fine. bzr operates
using abstract file identifiers, separate from the file names.

you only run into trouble from tree reshuffles if you split/merge files,
or don't tell bzr that you are renaming a file.. 

bzr help mv

Regards
Henrik



Re: [squid-core] v3 roadmap

2008-03-18 Thread Amos Jeffries

Alex Rousskov wrote:

On Wed, 2008-03-19 at 11:15 +1300, Amos Jeffries wrote:


The file re-arranging polish:
  - I'm kind of in favour of it as a pure file-movements-only 
alteration.  3.2 has no feature-requests yet and back-porting across a 
file-re-arranged setup is likely to be more trouble than its worth.


Can you clarify the above? I am not disagreeing, but am not sure whether
you are saying we should move/rename files in 3.1.


I want to see it done in 3.1, but I'd personally prefer it happens close 
to the 3.0/3.1 switchover. ie the last changes to go in.


The maintainer hat on me thinks that if its not done in 3.1, I might be 
back-porting stuff for a while until 3.2 is worked out. For that whole 
as-yet-undefined period I don't want to be re-arranging patches because 
the files are in different places.


Likewise from the point its done to the point we release 3.1 and close 
3.0 series off I'll be doing the same downwards anyway.


I'd like both periods of trouble to be as short as possible.



  - If you think you can get it done in a reasonable timespan to get 
done by the RC releases great. I don't think the PRE need to wait for 
it, its polish after all not a true feature.

  - It is your baby though.


Understood.

If you have the resources to move a few 2.6 features to 3.1 they should 
be timelined by 31 March or officially shifted to 3.2 pending later 
re-evaluation. Yes?


Agreed. I am still evaluating what needs to be ported and whether the
Factory can sponsor any of that.

Thank you,

Alex.




Amos
--
Please use Squid 2.6STABLE17+ or 3.0STABLE1+
There are serious security advisories out on all earlier releases.