Julien Rioux wrote: >>> a) make new code available early
i have been thinking about the proposed changes last couple of days and from many small things the main issue occuring to me again and again is that the new model of each 6 months release is going to be harmful for the overall stability of the stable lyx releases in general. 6 months mean 2 corrective releases (in current counting) and i think that if we end with 2.0.2/3 there is not enough time to even catch problematic bugs so the final 2.0.x release will be steep drop in quality compared to the previous releases. to my taste such price for pushing new features out quickly is inadequate. for the smaller things: >>> f) use commit log filters (doc/translations/web page/cosmetic/etc.) >> >> I'm not sure what you mean with this. My idea is that all documentation, >> translations, etc. will go into the respective branch. Only >> when a new release is set up, the translations and documentation will be >> merged into the master branch. this would be good indeed, it was my continuing frustration to crawl through milion of po/ remerges when searching something via git log -p. > f) separate development into doc/translation/web page/etc., > and have the ability to follow their activity independently > > I'm also glad that my only objection with the above list is c) develop new > features in branches. I don't think it's necessary for most features, only > for largish ones that are likely to take time and break the normal bug-free > level in the main dev branch. my fear is also that while the extensive branch usage is superior from the geeky point of view, its hindrance for people not so technically skilled. do we want only geeks to be around? > One thing I would add to the list is > > j) keep development alive during alpha-beta-rc stage for new > features that are not intended for this release but the next ideas to keep development active during rc stages is imho next nail in the coffin of the next major release besides short branch afterlife. pavel
