Please take a look at
I need help to decide who will have CVS access (official commiters).
Wow, you made it really fast. good job.
and I have a question.
Who will be join in this fork?
HOESH will join and continue to work or next holidays only?
and other members listed on sf.net ? who will be the manager?
anyway, please give me CVS access to work on.
not because I'm expert on mmcache, but because there
are nobody who have time to do this job now i think.
If you can, mail me account stuff.
> Wow, you made it really fast. good job.
Thx, opensource is magic, i didn't make something hard :)
> Who will be join in this fork?
All people interesting to patch/test actual 2.4.7-cvs version.
>HOESH will join and continue to work or next
Hoesh, for history, is important in the project. But perhaps you're all right when you said 'next holidays only' cause i suppose he got lot's of work most important than turckmmcache.
He make serious work about a turckmmcache potential fork, and i try to explain to him that turckmmcache.exeprod.com is not a place for a turckmmcache fork, but a place to patchs actual 2.4.7-cvs version, UNOFFICIALY, and TEMPORARY.
> who will be the manager?
Don't know. For CVS write access on the fork, it's me, cause it's my server. But due to my bad knowledge with C programming, i can't be a commit reviewer. Who can do this job ? So ...
I you feel that You can do the job of the commit reviewer, please go to
register yourself in the Wiki, and make a purposal.
Temporary, it will be a good thing that i give you CVS write access, to give you rights to put your patch.
I missed the reason that the fork is being put in an 'off-sourceforge' location?
In wanting to monitor progress / participate in future evolution of this project - ideally - retaining the user account I have here at SF, if preferable to YAUA (Yet Another User Account)
Not concerned by branching - Just would prefer to see the branch right here in the SF spotlight and common meeting point please. (unless other reasons I didn't notice impact this decision)
- Thanks, Julian.
> I missed the reason that the fork is being put in an 'off-sourceforge' location?
Because we have to name for new project, a lot's of name has been given as purpose, but noone has said 'yes, this name is the good one'.
If you relaunch discution about name, it should take longs days before find the good one.
While someone decide of a new name, I put 2.4.7-cvs out of sourceforge because Dmitry is the admin, and we need him to authorize user to be developer of the project. Nobody else expect him can do that.
Don't forget that one fork of turckmmcache while be published during next week (http://sourceforge.net/projects/eaccelerator/), and another has been purpose by Hoesh (mmcache).
Dmitry prefer to see forks of turckmmcache (due to GPL) rather than give his admin access. Not a problem :).
So while you are all waiting to see if forks of turckmmcache will be good, I just put 2.4.7 branch out of sourceforge to be able to make patchs.
So turckmmcache.exeprod.com is an UNOFFICIAL and TEMPORARY page before official forks. You can considere that the project TurckMMCache - on sourceforge - officialy stop any activity on code on 2.4.7 version.
Today, 2.4.8 version, containing patch of segv74 will be available for tests.
> In wanting to monitor progress [...]
No problem, every time something important (like this patched version) will append, I will annonce it on this forum. I understand that anobody don't want to have Yet An Other User Account)
Have a good day :)
Its really good that things are picking up again, for a while it seemed this project was destined for the great repository in the sky. Franck your doing a fantastic job as a co-ordinator / project manager.
Can I suggest that we put more emphasis on words like "rebranding" and "future development" (perhaps not the best choice, but teminology like forking/branching can be a little confusing to those who are unfamiliar with it).
There is already a renaming thread on this forum, but I propose we create a new one, where we give users 7 days to submit their actual idea's for a name (no chitter chatter on the thread), after this time a committee of 3 people will look at the submitted names and choose the one they think is best. Then we submit the new name to sourceforge and get a new account setup etc.
Good idea? bad idea? any thoughts or suggestions?
Someone mentioned a while ago there may be an issue with pre/appending "php" to a product name.
Might be worth mentioning at this point.
> Its really good that things are picking up again, for a while it seemed this project was destined for the great repository in the sky.
Me too :)
>Franck your doing a fantastic job as a co-ordinator / project manager.
Thanks a lot, i really don't want to see a page with something like TurckMMCache is DEAD.
>emphasis on words like "rebranding" and "future development",
Understand. You know, turckmmcache.exeprod.com, every body can modify/correct/add page until having an account on it (it's an invitation for collective work, and due to my english, whish is not correct sometimes, it will be great somebody correct me)
For this story of new name, I absolutely want to wait for eaccelerator project. If it's a good one, if Hoesh, segv74, or other people working on actual turckmmcache version say "yes, it's interesting to work on eaccelerator", so the question of the name will have no place.
As I said, eaccelerator should be published next week.
If eaccelerator is same thing as turckmmcache now, with just 1 or 2 bugs corrected, I don't know exactly what will be the best way :
- Hoesh has something behind the head, but he wants to correct and change a lot of things in turckmmcache.
- Segv74 is just patching the code to make a last stable release of turckmmcache (I call that Unofficial patches, only for moment)
So, C programmers must speak eatch others to see the degree of compatibility of what they are doing on the code. If too much desagreements, perhaps we will see too much direction for futur of turckmmcache. The idea is to regroup all theses directions into 1 or 2 directions.
For moment we have :
- unofficial patches (segv74)
- official fork : eaccelerator (reinerJ)
- potential fork : mmcache (hoesh)
In one or two weeks, we will see something more clear, we should be able to test and see eaccelerator and test patches by segv74.
After that, just to have opinion of Hoesh of all that.
If futur of turckmmcache is eaccelerator, the name is already choose. I suppose that Hoesh will not like Eaccelerator, due to the idea he has for the futur.
- If futur of turckmmcache is based on Hoesh work (He send me see nice documents about that), we must know if Hoesh want us to help him to choose a name or if he want to keep the name "mmcache" and see if work of segv74 can be integrated or not.
- If futur of turckmmcache is based on the work of segv74, we will create a new phread to choose a name.
- If futur of turckmmcache is based on the work of segv74+Hoesh+others people, let's create a new phread to choose a name.
Please, be patient one weeks or two max to see what append.
I didn't know about eaccelerator or other forks.
If I knew that, I wouldn't start this job. sigh.
I think it is not so bad to have 3-4 forks of mmcache in the world.
(* yeah, users's head will spin. what should i use? )
but, we are spending time on a lot of unnecessary efforts. I think all developers of forks are reverse-engineering undocumented php5/mmcache code along.
I don't think this is game those who reach goal first win.
people waited too long time including me. I think we should cooperate to provide stable version to public as soon as possible. for example,
if we see other's code, we can know what's missing part in me and others.
but, we don't even know who's working on it. *sigh*
I will check my version of mmcache daily based. so, if those who need what i did, visit Frank's CVS.
shin seung woo (segv74)
>I didn't know about eaccelerator or other forks.
> If I knew that, I wouldn't start this job. sigh.
I understand you :(
>I think it is not so bad to have 3-4 forks of mmcache in the world.
>(* yeah, users's head will spin. what should i use? )
I don't take care about user's head spin, I take care of what happening with turckmmcache before now : I preferer one or two forks with lot's of code contributors than 10 forks with one or two maintener (theses projects will die like turckmmcache).
>I don't think this is game those who reach goal first win.
Agree with you, the goal is to have a free, opensource, reliable php accelerator for php4/5.
>people waited too long time including me. I think we should cooperate to provide stable version to public as soon as possible. for example,
if we see other's code, we can know what's missing part in me and others.
YES !! I'm really agree with you on this point.
I'm creating a mailing list called php-accelerators on freelist.org. The idea is to get C programmers working on turckmmcache forks speak eatch other, for code & technical stuffs. Hoesh, you, eaccelerator team & co and every people how want to speak about the code.
>but, we don't even know who's working on it. *sigh*
we must know ! stop working alone in a corner without knowing other people do (i speak for Hoesh, eaccelerator and Alan Haldeman, without be angry :), it's just a suggestion, but it would be great and very usefull)
>I will check my version of mmcache daily based. so, if those who need what i did, visit Frank's CVS.
This CVS is here for that : patches on actual 2.4.7-cvs version. Happy to know that your using it :)
I'm preparing a page with daily snapshots downloadeable on the wiki.
Segv74, don't be afraid about other forks of turckmmcache, because for moment, nobody see a fork of turmmcache running with php5 without segfault, we wait for that.
If forks of turckkmcache do the stuff, it's not really important for you : your patches should be considered as 'unofficial' but reliables and EXISTING patches for turckmmcache (2.4.8 ?)
Please continue, for moment you are finaly the only one making something on the original code, and who say it in this forum, with files to download.
I've see Hoesh documents, I speak with ReinerJ (eaccelerator), I will continu to speak with Alan, but patches I can apply on the code is your's so let's go man :)
If we see that one or more forks of turckmmcache is correct, we will keep your patches on a website until php will exist :)
Log in to post a comment.