Abdelrazak Younes wrote: > It's the job of the > maintainer to recall the relevent developer his duty with regards to the > branch bug fixing. And Juergen is very goo at it. Artificially imposing a
not convincing. in many bugs its hard to decide whose is in charge and they just stay. > limit on trunk because we don't want developpers to lose their focus is not > needed IMO. there is also compromise possible - we freeze until the horrible number of bugs shrinks somewhat. > People should have two checkout: branch and trunk, period. now three: branch 1.6, branch 2.0, trunk 2.1. the fact that 2.0 will get less testing then is out of discussion. and this is next reason independent of 'losing focus' argument. so i still think that freezing its healthy at least for some time. > I would like to propose that we migrate new development to git. And that > current svn trunk stays the 2.0.x development platform. In git I would > impose that each new feature is done in a new git branch. i have no problem with git. at least we should give signal to another devs to look on it and try playing with lyx git repo, so before we proceed to real discussion people have real experience why not, why yes. and lets not pretend there are no drawbacks - what i quite miss is simple numbering of commits in linear order, its much harder to orient with checksums. there are also maintenance questions around - how good is connection with trac, whether its still possible to keep old svn links "r32567" living, mailling hooks etc. howsoever trivial detail this might look like, the fact that i was not able to influence such tasks like simple doxygen docs regeneration or broken wiki history on our server despite numerous questions, poses question who will do it ;) > I would also like to propose that we switch to a fixed date release cycle: > - feature release every six months. why not. > - lyx format changing release every two years (or less) already case. plus/minus ;) pavel
