[1.32 Plan] Stalled forever?
I don't want to sound harsh or anything, and I truly appreciate the effort that's being put in this, but a month has slipped by since the first schedule for releasing, and AFAIK we don't even have an agreed upon branching date for the near future. People are beginning to divert (a review in progress, etc.) I haven't been involved in previous releases, but I guess a month delay is well over what's considered normal/acceptable. Shouldn't we settle now on a realistic branching date and proceed with the release? Or, should I shut my mouth and let the release manager handle this as he deems convenient? Again, don't get me wrong. I am not willing to push anybody, but the process looks, well, erratic. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
I would like to second that. Two month ago I was told that I had to freeze any development yet another month ago. Now we still nowhere and I still couldn't move a finger. I understand that it may be caused by book preparation. But should we necessarily need to use namely this release? Let at least set a policy for open information: if for whatever reason release needs to be postponed lets announce it and set a new date. Regards, Gennadiy.
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote in message news:cgh8lj$jgm$1@sea.gmane.org...
I would like to second that.
Two month ago I was told that I had to freeze any development yet another month ago. Now we still nowhere and I still couldn't move a finger. I understand that it may be caused by book preparation. But should we necessarily need to use namely this release?
Sorry for breaking into this thread as I'm not a boost developer, but IMHO something seems really wrong with the SCM if you need to wait two months doing nothing. Why not branch for release right now, let people fix the issues on the release branch and merge back to the main trunk when it's complete (IIUC you use the main trunk as the active development line). This would let people who are working on new or updated functionality to proceed on the main trunk. I assume that the projects that are being prepared for the 1.32 release will not simultaneously be worked on in the main trunk - which could cause some pain when merging back. Even if so, a decent SCM tool would probably make things easy enough. Has anyone considered using Perforce instead of CVS? I believe there's a possibility to get a free server license for open source software (http://www.perforce.com/perforce/opensource-faq.html) development - don't know if the terms apply to boost. I've found Perforce easy to use and administer, fast, exists for about as many platforms as cvs (perhaps more on the server side) and the branching stuff is really, really smooth. Support is also outstanding, but I don't know the support terms for open source servers. IIRC FreeBSD (or some other BSD variety) uses Perforce as their main development platform and basically publishes the results to CVS to make things easier for CVS users. I know there's also subversion, but that's pretty immature yet (no flame wars please), and still haven't implemented atomic changelists(?). For the sake of order, I'll admit I have no personal experience using svn. (And, no, I'm not a Perforce sales representative - I just happen to like the darn thing ;-) // Johan
On 2004-08-25, Johan Nilsson <johan.nilsson@esrange.ssc.se> wrote:
Sorry for breaking into this thread as I'm not a boost developer, but IMHO something seems really wrong with the SCM if you need to wait two months doing nothing. Why not branch for release right now, let people fix the issues on the release branch and merge back to the main trunk when it's complete (IIUC you use the main trunk as the active development line). This would let people who are working on new or updated functionality to proceed on the main trunk. [...] Has anyone considered using Perforce instead of CVS?
CVS has its problems, but coping with the type of release cycle you describe isn't really one of them. It might not be as pretty as one might like, but it isn't a particularly difficult thing to do. It might, of course, not be an approach which is deemed practicable. The problem with getting the 1.32 release out the door (whatever it might be) won't, I suspect, be solved by using a different SCM... phil -- change name before "@" to "phil" for email
"Phil Richards" <news@derived-software.ltd.uk> wrote in message news:20040825194822.3E953E1E48@derisoft.derived-software.demon.co.uk...
On 2004-08-25, Johan Nilsson <johan.nilsson@esrange.ssc.se> wrote:
[...]
The problem with getting the 1.32 release out the door (whatever it might be) won't, I suspect, be solved by using a different SCM...
I didn't really imply that. Switching to a different SCM tool now would, I suspect, even further delay the 1.32 release ;-) What I was implying though, is that process can be hindered by inadequate tools (leaving out any specific tool comparison). // Johan
Gennadiy Rozental writes:
I would like to second that.
Two month ago I was told that I had to freeze any development yet another month ago. Now we still nowhere and I still couldn't move a finger.
1) Release or not, any major new development should happen on the branch. 2) At least please take care of the unmarked failures in Boost.Test before claiming that you've done your part for the release.
I understand that it may be caused by book preparation. But should we necessarily need to use namely this release?
Yes. We have to use a coherent set of sources that contains the new version of the MPL, and this is what this release is going to provide us with, in particular.
Let at least set a policy for open information: if for whatever reason release needs to be postponed lets announce it and set a new date.
There *was* annoucement of the release delay. The new date is going to be set as soon as MPL is in the main trunk. -- Aleksey Gurtovoy MetaCommunications Engineering
JOAQUIN LOPEZ MU?Z writes:
I don't want to sound harsh or anything, and I truly appreciate the effort that's being put in this, but a month has slipped by since the first schedule for releasing, and AFAIK we don't even have an agreed upon branching date for the near future.
The branching date is pending MPL check-in. The latter has been postponed several times as the new issues surfaced (in particular, due to better tests), but it's crucial to ensure that the library is in the predictable state before the release (remember that it goes on the CD with the TMP book), so please bear with us.
People are beginning to divert (a review in progress, etc.) I haven't been involved in previous releases, but I guess a month delay is well over what's considered normal/acceptable.
There are external constraints for this release's timeframe, but within those, the release is criteria-driven. One of the criteria is regression-free codebase, and another is the new MPL version. There is no point of releasing "on time" if the release is useless.
Shouldn't we settle now on a realistic branching date and proceed with the release? Or, should I shut my mouth and let the release manager handle this as he deems convenient?
Again, don't get me wrong. I am not willing to push anybody, but the process looks, well, erratic.
Please don't forget that we are all volunteers here. The best way to speed up things is to contribute to them. MPL issues notwithstanding, we still have the regression field to be cleared -- http://www.meta-comm.com/engineering/boost-regression/developer/summary.html. Turning it green while MPL is in works will make a huge difference. If you are willing to take over managing that one until the MPL check-in, be my guest. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy ha escrito:
JOAQUIN LOPEZ MU?Z writes:
I don't want to sound harsh or anything, and I truly appreciate the effort that's being put in this, but a month has slipped by since the first schedule for releasing, and AFAIK we don't even have an agreed upon branching date for the near future.
The branching date is pending MPL check-in. The latter has been postponed several times as the new issues surfaced (in particular, due to better tests), but it's crucial to ensure that the library is in the predictable state before the release (remember that it goes on the CD with the TMP book), so please bear with us.
People are beginning to divert (a review in progress, etc.) I haven't been involved in previous releases, but I guess a month delay is well over what's considered normal/acceptable.
There are external constraints for this release's timeframe, but within those, the release is criteria-driven. One of the criteria is regression-free codebase, and another is the new MPL version. There is no point of releasing "on time" if the release is useless.
I hope you haven't thought I'm irritated or trying to attack ayone; I've tried to write my post in the sweetest manner my English skills allow me, if it felt flaming I apologize, that was not my intention. Only that from my rather external point of view things didn't seem to have changed much during the last three weeks or so, no feedback or progress at all. But at least now from your answers and Dave's we have some concrete info, namely that branching will occur after MPL is checked in and that there's the absolute CD deadline. And I know you're working hard at this. That's fine. And I can't but agree on your concern about the general status of the regression tests, of which the MPL issue is not responsible.
Shouldn't we settle now on a realistic branching date and proceed with the release? Or, should I shut my mouth and let the release manager handle this as he deems convenient?
Again, don't get me wrong. I am not willing to push anybody, but the process looks, well, erratic.
Please don't forget that we are all volunteers here. The best way to speed up things is to contribute to them. MPL issues notwithstanding, we still have the regression field to be cleared -- http://www.meta-comm.com/engineering/boost-regression/developer/summary.html. Turning it green while MPL is in works will make a huge difference. If you are willing to take over managing that one until the MPL check-in, be my guest.
I whish I could, but I'm already stealing much too time from my daily work to engage into managerial tasks. OTOH I've done little contributions to some problems before vacation, and will try to help a bit now. Again, please do not take my complaints as offence. I much appreciate your volunteering to manage the release and wouldn't want to be seen as an additional source of pressure. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (4)
-
Aleksey Gurtovoy -
Gennadiy Rozental -
JOAQUIN LOPEZ MU?Z -
Joaquín Mª López Muñoz
-
Johan Nilsson -
Phil Richards