Torben, Yeah I think developing a timeline soon would be good so people don't start very large projects in proximity to the move. I think once we get out committer accounts and web site / wiki to the point where we can start posting plans, we should definitely start to publish a timeline. Thanks.
~Michael On Dec 10, 2010, at 1:08 PM, Torben Weis wrote: > Hi, > > sorry, I misunderstood your idea. As long as we do it one after the other > that's fine. > > We should definitely voice a time line for the move. Furthermore, we should > put up some instructions > of what to do with development clones that could not be committed before the > move. > I am not a hg/git wiz and would be in some trouble when the project moves > before I can commit my changes for code review. > > Once we know how to migrate development clones to the new infrastructure > "easily" we define a "move day". > This will lead to a freeze while development can continue on the clones. > If the system is stable at move day (i.e. compiles, starts and does not > crash immediately), we move. > If it is broken we try the next day. This way we can be sure to move a > stable source tree. > > Greetings > Torben > > 2010/12/10 Michael MacFadden <[email protected]> > >> Torben, >> >> I agree that moving infrastructure and code clean up could be risky to do >> at the same time. That is exactly why I am recommending doing it now. I >> suspect that we won't be ready to move the code over for several weeks to a >> month or two. We don't have committer accounts, issue tracking, source >> control, etc. It might take some time to get all that in the place. >> >> We can use that time to get the code base cleaned up before the move. As >> it is, people are already committing lots of code and functional changes >> right now. I don't see how removing dead code that is not being used is any >> more risky. >> >> On that note though, we may want to start thinking about the time line for >> the move and whether we want to have a code freeze during that time. >> >> ~Michael >> >> On Dec 10, 2010, at 12:29 PM, Santiago Gala wrote: >> >>> It can be done in a branch or patch to be applied later. Not sure about >> hg, >>> very easy with GIT. >>> >>> Regards, >>> Santiago >>> El 10/12/2010 20:57, "Torben Weis" <[email protected]> escribió: >>>> Hi Michael, >>>> >>>> I try to avoid changing code and infrastructure at the same time. It is >>>> tempting to start with a clean code base on a new infrastructure, but >>> there >>>> is a risk that in the end it takes >>>> a) too long because of unforeseen issues >>>> b) if something breaks, it is difficult to see what caused the problem. >>>> >>>> I am all in for a code cleanup. I am just not sure that doing it >> together >>>> with the source code move is the best timing. >>>> >>>> Greetings >>>> Torben >>>> >>>> 2010/12/10 Michael MacFadden <[email protected]> >>>> >>>>> All, >>>>> >>>>> As we ponder moving our source code over to Apache in the next month or >>>>> two, I thought this would be a great opportunity for us to have a code >>> clean >>>>> up drive. Looking through the code base it is apparent that we have >> some >>>>> code atrophy. As we have re-organized, rewritten, or replaced >>>>> functionality, in many cases the former code has been left in the code >>> base. >>>>> >>>>> Dead code is a threat to the code based since it a) has to be >> maintained, >>>>> b) has the potential to break, c) confuses new developers. I suggest >> that >>>>> we take this opportunity to look at the areas of code we work with and >>>>> remove any legacy code that is no longer needed. Of course I would >>> suggest >>>>> checking with others before just removing large bits of code, that you >>>>> yourself didn't write. >>>>> >>>>> Thanks, >>>>> >>>>> Michael >>>> >>>> >>>> >>>> >>>> -- >>>> --------------------------- >>>> Prof. Torben Weis >>>> Universitaet Duisburg-Essen >>>> [email protected] >> >> > > > -- > --------------------------- > Prof. Torben Weis > Universitaet Duisburg-Essen > [email protected]
