From: mose <mo...@ti...> - 2007-11-25 23:32:57
|
le Sun, Nov 25, 2007 at 05:16:36PM +0100 par Nyloth : > Hi, > > YES ! ;) > > As mose already knows, I'm also in favor of migrating to SVN asap. It has a > lot of advantages over CVS and is even easier to use. > > About releases numbers and other stuff, my preferences are : > > - to follow what was done before (If there was & 1.9.0 before 1.9.1, then I > prefer 1.10.0), but I will be ok with any choices, It's not important for me, - okay, no matter the number, anyways, it has to get out. > - as you proposed, to continue 1.10 branch on CVS and start a new 2.0 branch > in SVN, based on last 1.10 code, as soon as we decide to freeze 1.10 branch, - I think that switching to 2.0 will be the occasion to refactor some things and I think that 1.x versions can probably have some life in front of it. I also bet that some people will find lotta excuse to avoid to jump to svn and will continue coding with cvs for the version they use. That may result is a sortof internal fork, maybe. > - to wait for the next RC and first establish a list of things that have to > be done before releasing (release blockers). > > I'd prefer to have such a list before any RC release, and then only have > bugfixes as soon as the first RC is released. For example, there are some > features that either need to be removed, either to be finished, but they are > not fully functionnal and should not be in a stable version (this includes, > in my opinion, some devs "in progress" like those from nkoth or niclone, > especially "mypages"), - yes some very recent contributions are still unknown, unexplored and trashy, but that's also the case of some old contributions :) The inventory we'll have to make this week should list them all, evaluate their level of buginess, and there will be some 'cuts' but only on some old feature that never worked for anybody or are very marginaly used, like the charts, the whelp thing, the ephemeride maybe, I would be in favor also to remove the chat. nd there are many others. Such non-functionnal features are false promises and they are only source of frustration for the ones that expect the features in the list can be used. But, as we worship optionnality, I think that some live features, actively developped currently, should get a chance to get thru, as far as it's proven that they are properly optional. > As you are the release manager of 1.10.x, please consider my request to start > this page (If it's not already done somewhere) and to ask devs to focus now > on those release blockers stuff. If we have such a page/tracker, I will add > some bug tracker items. > > It seems that http://tikiwiki.org/tiki-index.php?page=ReleaseProcess1_10_0 is > the wiki page that should be (as a tradition) used for this, but it's content > is maybe not up-to-date. As you wish. - you are right. I'll update that page as a central point to coordinate action on 1.10.0 (if that's how it will be named). I plan to dedicate this week to listing blockers, all the help is welcome. This announces a freeze on 1.10 branch for this week until we release the first RC version. Only bugfixes and translation are allowed, please refrain your commits on new features. If you have a doubt, please contact me before committing. I'll do a separate mail to announce it asap. cheers, mose > > Btw, thanks mose ! > Nyloth. > > On Sunday 25 November 2007 14:24:37 luci aka luciash d' being wrote: > > hi, > > > > yes, we should definitely move to SVN. it has many advantages over CVS > > imho. > > > > mose wrote: > > > hi > > > > > > That's not a new topic, we seem to collectively wish to switch to svn > > > rather than cvs. I was wondering if it could be done now. > > > > > > We are still in process of preparing 1.10.1rc1, I got busy but I plan > > > now to get back in it and prepare something fast. We may try to use > > > that occasion to try a migration. > > > > > > I've been wondering for a while before proposing such move now. The > > > thing is that moving on svn will have some consequences that would > > > affect all tikiwiki contributors, and others that are used to upgrade > > > and maintain their tiki from CVS currently. > > > > > > The move to SVN would permit things that we can't do with CVS, like > > > erasing dirs, moving them around, renaming files, such things that we > > > would badly need. Imho the move is not questionnable, the point to set > > > up is: when. > > > > iirc it even preserves symlinks when needed. when ? i'd like to have it > > ready for Tiki 2.0 development. > > > > > Then I open now that thread : should we try to get tikiwiki to svn > > > now ? Would it be on 1.10 or on future 1.11 version (current head). > > > > > > I think it would be risky to move the current release-in-progress > > > 1.10 branch, my opinion is that we could move on svn for the 1.11 > > > (which can be renamed 2.0 if it appears appropriate in the future). > > > > the question is if we continue developing 2.0 with the current messy > > code base trying to fix it and polish it in a "never ending story" or if > > we start coding for Tiki 2.0 from scratch. i can imagine (and actually > > i'd like to see) Tiki 2.0 as a shiny new, user friendly "Web 2.0" > > features introducing release, until it's too late and there will be some > > Web 3.0 or similar hype in the future... > > > > > But that would make 2 active branches, because I know that some coders > > > prefer svn for good reasons so they'll jump in it whatever the > > > version. So there may be a risk of split in coding population. > > > > > > There are some others immediatly visible issues with the svn move : > > > > > > * there is no merge tool between cvs and svn afaik, then merge would > > > have to be done manually the hard way, file by file. > > > > when we decide to develop Tiki 2.0 from scratch this wouldn't be necessary > > > > > * on some shared spaces they propose cvs use, but not always svn (it's > > > the case for the hosts that marc uses to host several *.tw.o sites). > > > > lets find alternatives for svn > > > > > * about cvs stats tools that we use, like cvsmonitor, we probably can > > > find equivalent stats tools (but there is no svnmonitor). > > > > maybe ohloh.net stats could serve good for this > > > > > * svn setup would be some amount of work, adapting the cvsignores in > > > svn:properties and other things like keywords substitution (not much > > > an hassle, but some ant work). > > > > i don't see this as a show stopper > > > > > So, I call for your comments on this topic. What is the position of > > > you coders about this ? non coders can talk, for sure, but I think > > > that coders should have the priority in the choice of the tool they > > > work with. > > > > i'm definitely + for switch to SVN, but maybe do it for the Tiki 2.0 > > development only (which we should start soon anyway) > > > > > > luci > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Tikiwiki-devel mailing list > > Tik...@li... > > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Tikiwiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel |