Proposal for radically altered approach to releases

[Beman Dawes]

Thorsten Ottosen wrote:

> Beman Dawes wrote:
>
>> A draft proposal is available at
>> http://mysite.verizon.net/beman/release_overview.html.
>>
>> I've put a fair amount of thought into this proposal, and have run some
>> Subversion simulations to make sure it works smoothly.
>
> I like it for the most. A thing that is missing is how to
> break the stable version when you do want to break it.
>
> For example, often when libararies are redesigned, they give up
> some compilers (Eg. spirit). Sometimes porting can really make a
> developer feel worn-out.
>
> As a concrete example, what happens when I commit the new version of the
> range library. Can I simply mark some of the compilers as not supported
> to get it into the stable-branch, or do I have to wait forever to get it
> from trunk to stable?

Just markup the failure as expected. I've added a note to make that clearer.

> Also, what happens if several libraries depend on your library in trunk,
> but can't work with the dependency found in stable?

You have to wait for the other libraries to be merged to stable.

> But the version in
> trunk is not ready to go to stable and so this will stall all libraries
> that depend on that library?

Yes. A good argument to only depend on features of Boost libraries that
are in stable.

Thanks,

--Beman
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Beman Dawes]

"Beman Dawes" <bdawes@...> wrote in message
news:44634D7C.9030108@......

> A draft proposal is available at
> http://mysite.verizon.net/beman/release_overview.html.

The draft has been updated to reflect comments from Michael Fawcett, Simon
Carter, Arkadiy Vertleyb, Pedro Lamarão, Robert Ramey, Anthony Williams, and
Thorsten Ottosen.

--Beman




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thorsten Ottosen-3]

Beman Dawes wrote:
> Thorsten Ottosen wrote:

>>Also, what happens if several libraries depend on your library in trunk,
>>but can't work with the dependency found in stable?
>
>
> You have to wait for the other libraries to be merged to stable.

I think I need to explain this better:

I upgrade library A in trunk s.t. it is no longer compatible with
library B (which depends on A) in either trunk nor table.

Since A don't work with B.stable, I can't commit A to stable.
Since B.trunk can be made to work with A, B.trunk can be made to work.
However, as soon as one tries to commit B.trunk to stable, it can't
because it won't work with A.stable.

Basically we need to commit A and B at the same time. Neither can go alone.

Does it make sense?

Thorsten
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Russell Hind]

Pedro Lamarão wrote:
>
> The keyword $Revision$ can substitute in a file the revision of the last
> commit to that file. But that number won't change on commits to other files.
>
> A tool is available, WCSubRev.exe, that reads the Subversion status of
> all files in a working copy (excluding externals), and can substitute in
> a file the revision of the last commit (among other things). It is
> usually called in build scripts while making a (tag for) release.
>

This is windows only as it is part of TortoiseSVN
(http://tortoisesvn.tigris.org) but I'm sure it could easily be ported
to other platforms.

We use this for our versioning too, it is very useful.

Cheers

Russell

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Nicola Musatti]

Pedro Lamarão <pedro.lamarao <at> intersix.com.br> writes:
[...]

> Beman Dawes escreveu:
>
> "Formal releases occur on a regular schedule. The formal release
> procedure is simply to package up the last tagged revision of stable,
> publish release candidates, and decide if there are any issues serious
> enough to wait for the next stable tag point."
>
> If this process would contemplate a bugfix branches associated with
> stable tags, and if some backporting fixes effort were made, the people
> complaining about API stability would be happier.

I agree. In my opinion a new branch should be created on STABLE for each formal
release. Its main purpose would be to provide an escape should anything go wrong
with the formal release, but it would also be available for smaller scale
bugfixing and backporting, subject to availability of necessary resources; I'm
aware that control should be exercised over what is committed on the formal
release branches, especially since these do not have an associated "unstable"
branch. People wishing to contribute to a bugfix branch should ensure that a
reasonable amount of regression testing is performed before the branch is given
a new "stable" tag.

Note that this would require a change in the release numbering scheme; a couple
of alternatives could be to add a fourth number for the weekly tags or to just
use the date in the YYYYMMDD format.

> No need to bugfix for ever; maybe just the previous release; or whatever
> is confortable enough. This should just give more longevity, and a
> healthier old age, to each Boost release.

Bug fixing should be performed on an as needed/as voluteered basis.

Cheers,
Nicola Musatti


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Witt-2]

Beman,

I'll comment on the actual proposal later.

Beman Dawes wrote:
> I propose changing to a different release model, one based on always
> maintaining a release-ready stable branch and merging updates for
> individual libraries into it asynchronously.

Just a quick remark. AFAICS the current release process is slowed down
by the switch to boost.build v2 and I am perfectly willing to take the
blame for that. The boost.build guys are working hard, some things just
take time.

Thomas



--
Thomas Witt
witt@...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Abrahams]

Beman Dawes <bdawes@...> writes:

> A draft proposal is available at
> http://mysite.verizon.net/beman/release_overview.html.
>
> I've put a fair amount of thought into this proposal, and have run some
> Subversion simulations to make sure it works smoothly.
>
> What do others think?

Mostly great.  I'm concerned about these time slots.  They don't seem
necessary in principle since subversion has atomic commits, and they
seem like they could introduce spurious lock contention on the
repository.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Abrahams]

"Beman Dawes" <bdawes@...> writes:

> "Simon Carter" <simon.carter@...> wrote in message
> news:loom.20060511T171525-434@......
>> Beman Dawes <bdawes <at> acm.org> writes:
>>>
>>> http://mysite.verizon.net/beman/release_overview.html.
>>>
>> The link is broken for me.
>>
>> I don't mind how the release is managed so long as I can use some kind of
>> numbering system to completely identify the version of boost I have. As a
>> minimum the overall boost version number should be incremented everytime
>> anything in the release branch changes.
>>
>> I'm thinking of cases where I know my app worked with (say) boost 1_30_0
>> but not
>> with 1_32_0 - I need to be able to go back to the earlier version without
>> jumping through hoops to reconstruct the state of the release branch at a
>> particular point in time.
>
> Good point. I've added a note to that effect, and suggested a number scheme
> based on the current practice.

SVN tags each state of the repository with a sequential number, so
even intermediate states can be identified with those.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Abrahams]

"Arkadiy Vertleyb" <vertleyb@...> writes:

> "Beman Dawes" <bdawes@...> wrote
>
>> The problems with the current release approach are not caused by release
>> managers or developers, but rather by the release system itself. It just
>> doesn't scale up to the number of libraries now in Boost, since every
>> library has to be ready before a release can occur.
>>
>> These problems will only grow worse as more libraries are added.
>
> I think you are considering just one dimension of the problem.
>
> The other one -- the number of supported compilers is IMO equaly, if not
> even more, important.  The broken build can be detected only after the
> regressions run on all the compilers.  Which may be a few days (or a few
> weeks).  

Making sure that incremental testing works reliably may be the best
way to address that problem.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jeff Garland]

Beman Dawes wrote:
> The current approach to getting releases ready is completely broken in
> my opinion. Each release requires heroic efforts by the release manager,
> careful attention by many developers, and endless delays until
> everything is just right.

No doubt that the process is broken.  I will say though, part of the
problem has always been nicely waiting for fixes to be made.  Releases
could trivially be made by reverting any library with regressions to the
version in the previous build.  This is similar to what you are
proposing, but would be more on the shoulders of the release manager to
be ruthless about meeting the deadlines.  The current release, for
example, would be progressing much faster if we just took the obvious
position: v2 build system isn't stable enough, revert to v1 and move on.
v2 will be in the next release.

> This is discouraging to developers and, worse yet, important library
> upgrades and bug fixes are taking far too long to get into user's hands.
>
> The problems with the current release approach are not caused by release
> managers or developers, but rather by the release system itself. It just
> doesn't scale up to the number of libraries now in Boost, since every
> library has to be ready before a release can occur.

Again, it's mostly because the release managers are too nice.  I'll
volunteer to be the next release manager, I'll set a date, and I'll
pretty much assure you that it will go out on or about that date because
I'd cut any change off that wasn't ready.  One really good thing about
your proposal is that it builds in the fix it or you're reverted
expectation that has been lacking for so long.

> These problems will only grow worse as more libraries are added.
>
> I propose changing to a different release model, one based on always
> maintaining a release-ready stable branch and merging updates for
> individual libraries into it asynchronously.
>
> A draft proposal is available at
> http://mysite.verizon.net/beman/release_overview.html.
>
> I've put a fair amount of thought into this proposal, and have run some
> Subversion simulations to make sure it works smoothly.
>
> What do others think?

In general I like the direction.  A couple concerns though:

1) This does mean additional work for developers since all changes will
require merges.  So this better be really easy to do in SVN for the
trivial merges for an entire library.  I still don't use SVN on a daily
basis, so it is hard for me to evaluate how much work merging will
require.  Overall, however, it will be worth a little extra work to make
the release process actually work again...

I also wonder if there should be exceptions to this policy.  For
example, a documentation update or example code not compiled as part of
regression test update.  Putting these on the trunk will not provide any
feedback anyway.  The only danger is that if you allow these exceptions
someone might get sloppy.

2) The dynamics of past releases have shown over and over that as good
as the regression system is unexpected things show up.  So we either
need to tag a point where minor changes can be made to a release stable
point or freeze major changes on stable for a beta period while
beta-testers go one last step and test the packaged release.  This is
mostly to avoid having to redo release notes, version numbers and other
work associated with the release.

3) Some core libraries need to be mercilessly reverted on the trunk as
well as on stable.  There is a core set of libraries that cause major
issues when they don't work.  type traits, config, and test come to
mind.  If these libraries are unstable on the trunk they prevent other
developers from validating and moving their code to stable.  Thus
developers of these libraries will need to be held to a higher standard
than developers of other libraries.  They need to revert changes on the
trunk after some pre-defined period (48 hours maybe) if they can't fix a
build issue that is breaking lots of other libraries.

4) I suggest that the set of compilers monitored on the stable branch
will only be the group of agreed "supported compilers".  If volunteers
want to add a new compiler to the supported set (say some new version of
the Sun compiler) they must demonstrate that a previous stable build of
Boost passes all libraries with no unmarked failures.  It is up to these
volunteers to work with developers to achieve this state using the trunk.

Thx for doing this Beman -- it's something that really needs to be tackled.

Jeff


-----
Minor wording nits:

     * Regression tests are run daily on both trunk and  stable. Testers
coordinate via the boost-test mailing list to ensure that both truck and
                                                                ^^^^^
       Note well: Reverting is a safety-value only. Developers must never
                                 ^^^^^^^^^^^^

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vladimir Prus]

Jeff Garland wrote:

> Beman Dawes wrote:
>> The current approach to getting releases ready is completely broken in
>> my opinion. Each release requires heroic efforts by the release manager,
>> careful attention by many developers, and endless delays until
>> everything is just right.
>
> No doubt that the process is broken.  I will say though, part of the
> problem has always been nicely waiting for fixes to be made.  Releases
> could trivially be made by reverting any library with regressions to the
> version in the previous build.  This is similar to what you are
> proposing, but would be more on the shoulders of the release manager to
> be ruthless about meeting the deadlines.  The current release, for
> example, would be progressing much faster if we just took the obvious
> position: v2 build system isn't stable enough, revert to v1 and move on.
> v2 will be in the next release.

Huh? Sorry, this is FUD. Though V2 initially caused quite a number of issues
on it's own, they were fixed pretty quickly, and the remaining issues can
be knocked down quickly too.

The problem is that I don't see any effort to close other issues. Let me get
specific:

  - There's date_time failures with FelipeAlmeida and Bronek_office runners,
    which use V1. How V2 prevents you from investigating them?
  - The concept_check and mpl libraries fail across *all* toolsets. I've
    reported this here, twice, and nothing is still done.

>> The problems with the current release approach are not caused by release
>> managers or developers, but rather by the release system itself. It just
>> doesn't scale up to the number of libraries now in Boost, since every
>> library has to be ready before a release can occur.
>
> Again, it's mostly because the release managers are too nice.  I'll
> volunteer to be the next release manager, I'll set a date, and I'll
> pretty much assure you that it will go out on or about that date because
> I'd cut any change off that wasn't ready.  

How about reverting date_time to the version that was shipped with 1.33,
right now, on the grounds of there being test failures?

Sorry if that sounds rush, but I simply don't think that "revert war" on
mainline is a best way to handle anything.

The "stable branch" idea from Beman, on the other hand, sounds quite
feasible. It might be even better if merges to stable branch are done by
release manager only, so that he gets full control of what goes to release.


- Volodya


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vladimir Prus]

Thomas Witt wrote:

>
> Beman,
>
> I'll comment on the actual proposal later.
>
> Beman Dawes wrote:
>> I propose changing to a different release model, one based on always
>> maintaining a release-ready stable branch and merging updates for
>> individual libraries into it asynchronously.
>
> Just a quick remark. AFAICS the current release process is slowed down
> by the switch to boost.build v2 and I am perfectly willing to take the
> blame for that. The boost.build guys are working hard, some things just
> take time.

Hi Thomas,
as I already mention in reply to Jeff, it does not seem that way for me.
During V2 switch I've address tens of issues that originally were present.
At the same time, regressions in concept_check and mpl, on *all* compilers,
that I reported to this list and to you personally are still there.

I did suggested to you to setup an issue tracker specifically for listing
all issues that must be addressed before release. It would allow anybody to
understand the state of release process.

Do you still think it's a bad idea? I can create the tracker in 5 mins.

- Volodya

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Abrahams]

Vladimir Prus <ghost@...> writes:

> The problem is that I don't see any effort to close other issues. Let me get
> specific:
>
>   - There's date_time failures with FelipeAlmeida and Bronek_office runners,
>     which use V1. How V2 prevents you from investigating them?
>   - The concept_check and mpl libraries fail across *all* toolsets. I've
>     reported this here, twice, and nothing is still done.

I didn't notice a report recently about concept_check.  I thought I
checked in fixes for the problems we were seeing.  Hmm, maybe the CVS
outage kept things from going in... lemme check.

Um, despite SF site status saying that CVS is up, I can't reach the
server through ssh:

  $ ssh -v david_abrahams@...
  OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005
  debug1: Reading configuration data /home/dave/.ssh/config
  debug1: Connecting to cvs.sourceforge.net [66.35.250.207] port 22.
  debug1: connect to address 66.35.250.207 port 22: Connection reset by peer
  ssh: connect to host cvs.sourceforge.net port 22: Connection reset by peer

So I may well be sitting on fixes that I can't check in.  Can't tell
of course, because with CVS you can't do a diff unless you can reach
the server.  I've submitted a support request at SF, but in principle
they don't check those except on weekdays... :(

> Sorry if that sounds rush, but I simply don't think that "revert war" on
> mainline is a best way to handle anything.

Agree

> The "stable branch" idea from Beman, on the other hand, sounds quite
> feasible. It might be even better if merges to stable branch are done by
> release manager only, so that he gets full control of what goes to release.

Sounds good to me.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Edward Diener]

Vladimir Prus wrote:

> Jeff Garland wrote:
>
>> Beman Dawes wrote:
>>> The current approach to getting releases ready is completely broken in
>>> my opinion. Each release requires heroic efforts by the release manager,
>>> careful attention by many developers, and endless delays until
>>> everything is just right.
>> No doubt that the process is broken.  I will say though, part of the
>> problem has always been nicely waiting for fixes to be made.  Releases
>> could trivially be made by reverting any library with regressions to the
>> version in the previous build.  This is similar to what you are
>> proposing, but would be more on the shoulders of the release manager to
>> be ruthless about meeting the deadlines.  The current release, for
>> example, would be progressing much faster if we just took the obvious
>> position: v2 build system isn't stable enough, revert to v1 and move on.
>> v2 will be in the next release.
>
> Huh? Sorry, this is FUD. Though V2 initially caused quite a number of issues
> on it's own, they were fixed pretty quickly, and the remaining issues can
> be knocked down quickly too.
>
> The problem is that I don't see any effort to close other issues. Let me get
> specific:
>
>   - There's date_time failures with FelipeAlmeida and Bronek_office runners,
>     which use V1. How V2 prevents you from investigating them?
>   - The concept_check and mpl libraries fail across *all* toolsets. I've
>     reported this here, twice, and nothing is still done.
>
>>> The problems with the current release approach are not caused by release
>>> managers or developers, but rather by the release system itself. It just
>>> doesn't scale up to the number of libraries now in Boost, since every
>>> library has to be ready before a release can occur.
>> Again, it's mostly because the release managers are too nice.  I'll
>> volunteer to be the next release manager, I'll set a date, and I'll
>> pretty much assure you that it will go out on or about that date because
>> I'd cut any change off that wasn't ready.  
>
> How about reverting date_time to the version that was shipped with 1.33,
> right now, on the grounds of there being test failures?
>
> Sorry if that sounds rush, but I simply don't think that "revert war" on
> mainline is a best way to handle anything.
>
> The "stable branch" idea from Beman, on the other hand, sounds quite
> feasible. It might be even better if merges to stable branch are done by
> release manager only, so that he gets full control of what goes to release.

The whole point of Beman's proposal is against this last statement. The
point is that each library developer should be responsible for getting
their library into the stable branch and maintaining that stability at
all times. If a library is put into the stable branch with some change
which breaks another library, it needs to be backed out until the
appropriate libraries are coordinated to work together at the stable
branch level.

The release manager is then freed to set the appropriate dates and get
out the release.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jeff Garland]

On Sat, 13 May 2006 12:34:41 +0400, Vladimir Prus wrote
> Jeff Garland wrote:
>
> Huh? Sorry, this is FUD. Though V2 initially caused quite a number
> of issues on it's own, they were fixed pretty quickly, and the
> remaining issues can be knocked down quickly too.

Hi Vladimir -

Please, don't get upset -- I'm not trying to single you out -- there's plenty
of good reasons for the release delay I'm sure.  And I'm sorry, you're right I
shouldn't have used an example I don't really have first hand knowledge of --
I haven't paid attention enough to know if V2 is really stalling the current
release.  Only Thomas can say.  

> The problem is that I don't see any effort to close other issues.
> Let me get specific:
>
>   - There's date_time failures with FelipeAlmeida and Bronek_office
> runners,    which use V1. How V2 prevents you from investigating
> them?

Nothing at all.  I've been a bit busy so I haven't looked lately and Doug's
failure nag seems to have gone away.  Of course with no changes in date-time
for a month and barely any since the last release it's probably a problem
elsewhere, but who knows.  I'll try to look today.  Of course even if all the
regressions were fixed today, someone would realize we need to run the license
checker and that would spiral us into another week of fixing, etc, etc.

>  - The concept_check and mpl libraries fail across *all*
> toolsets. I've    reported this here, twice, and nothing is still done.

Yep.

> How about reverting date_time to the version that was shipped with
> 1.33, right now, on the grounds of there being test failures?

I'd be fine with that if the build manager felt it was necessary to get the
release done.  I wouldn't make the suggestion if I wasn't willing to have it
applied to myself.

> Sorry if that sounds rush, but I simply don't think that "revert
> war" on mainline is a best way to handle anything.

Sure it would.  It would change the process in a way that would stop the
endless delays and waiting for everything to be fixed.  Since the process
would be much faster there could be more releases and the fact that date_time
or anything else was reverted wouldn't be such a big deal.  Again, I'm not
suggesting this policy for the current release (frankly it's too late), just
pointing out an alternative to the current process that I believe would make
the process shorter.
 
> The "stable branch" idea from Beman, on the other hand, sounds quite
> feasible. It might be even better if merges to stable branch are
> done by release manager only, so that he gets full control of what
> goes to release.

That sounds vaguely like what I was proposing ;-)  As I tried to say, I'm
generally a supporter of Beman's proposal because it basically enforces what
I'm talking about -- fix it or it's reverted.  Until we get serious about
enforcing that no one will pay attention.
 
Jeff
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jeff Garland]

On Sat, 13 May 2006 12:38:13 +0400, Vladimir Prus wrote
 
> I did suggested to you to setup an issue tracker specifically for listing
> all issues that must be addressed before release. It would allow
> anybody to understand the state of release process.
>
> Do you still think it's a bad idea? I can create the tracker in 5 mins.

This is a great idea. I'd really like to see this, because this would be
useful now in organizing and getting the release done ASAP.  Posting to the
list isn't working...

Jeff
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Ralf W. Grosse-Kunstleve]

--- David Abrahams <dave@...> wrote:

> I didn't notice a report recently about concept_check.  I thought I
> checked in fixes for the problems we were seeing.  Hmm, maybe the CVS
> outage kept things from going in... lemme check.
>
> Um, despite SF site status saying that CVS is up, I can't reach the
> server through ssh:
>
>   $ ssh -v david_abrahams@...
>   OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005
>   debug1: Reading configuration data /home/dave/.ssh/config
>   debug1: Connecting to cvs.sourceforge.net [66.35.250.207] port 22.
>   debug1: connect to address 66.35.250.207 port 22: Connection reset by peer
>   ssh: connect to host cvs.sourceforge.net port 22: Connection reset by peer
>
> So I may well be sitting on fixes that I can't check in.  Can't tell
> of course, because with CVS you can't do a diff unless you can reach
> the server.  I've submitted a support request at SF, but in principle
> they don't check those except on weekdays... :(

The boost CVS is indeed active since Friday, but you have to patch all your CVS
Root files since the server address has changed, e.g. first create a file
"Root" somewhere, e.g. in your home directory, with just one line:

abrahams@...:/cvsroot/boost

Then cd into boost and run:

find . -name Root -exec cp $HOME/Root {} \;

Unfortunately there is another problem:

cvs update: [06:07:02] waiting for vawjr's lock in
/cvsroot/boost/boost/libs/regex/test/c_compiler_checks

It started Friday afternoon. I think the only way to remove the stale lock is
to open a SF support request.

Cheers,
        Ralf


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Rene Rivera]

Ralf W. Grosse-Kunstleve wrote:
> The boost CVS is indeed active since Friday, but you have to patch all your CVS
> Root files since the server address has changed

If you have wincvs, and the TCL shell active in it, there's a macro that
will also do this for you "Macro, CVS, Change CVSROOT".

> Unfortunately there is another problem:
>
> cvs update: [06:07:02] waiting for vawjr's lock in
> /cvsroot/boost/boost/libs/regex/test/c_compiler_checks
>
> It started Friday afternoon. I think the only way to remove the stale lock is
> to open a SF support request.

I already did that
<http://sourceforge.net/tracker/?func=detail&aid=1488367&group_id=1&atid=200001>.


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Abrahams]

"Ralf W. Grosse-Kunstleve" <rwgk@...> writes:

> --- David Abrahams <dave@...> wrote:
>> I didn't notice a report recently about concept_check.  I thought I
>> checked in fixes for the problems we were seeing.  Hmm, maybe the CVS
>> outage kept things from going in... lemme check.
>>
>> Um, despite SF site status saying that CVS is up, I can't reach the
>> server through ssh:
>>
>>   $ ssh -v david_abrahams@...
>>   OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005
>>   debug1: Reading configuration data /home/dave/.ssh/config
>>   debug1: Connecting to cvs.sourceforge.net [66.35.250.207] port 22.
>>   debug1: connect to address 66.35.250.207 port 22: Connection reset by peer
>>   ssh: connect to host cvs.sourceforge.net port 22: Connection reset by peer
>>
>> So I may well be sitting on fixes that I can't check in.  Can't tell
>> of course, because with CVS you can't do a diff unless you can reach
>> the server.  I've submitted a support request at SF, but in principle
>> they don't check those except on weekdays... :(
>
> The boost CVS is indeed active since Friday, but you have to patch all your CVS
> Root files since the server address has changed, e.g. first create a file
> "Root" somewhere, e.g. in your home directory, with just one line:
>
> abrahams@...:/cvsroot/boost

Oh, that's just intolerable.  Did they even announce the change??!
Wasn't it just a few years ago that that very address became unusable
and we were forced to switch to plain cvs.sourceforge.net?

Get me offa SourceForge, please!

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Anthony Williams-3]

David Abrahams <dave@...> writes:

> "Ralf W. Grosse-Kunstleve" <rwgk@...> writes:
>
>> The boost CVS is indeed active since Friday, but you have to patch all your CVS
>> Root files since the server address has changed, e.g. first create a file
>> "Root" somewhere, e.g. in your home directory, with just one line:
>>
>> abrahams@...:/cvsroot/boost
>
> Oh, that's just intolerable.  Did they even announce the change??!
> Wasn't it just a few years ago that that very address became unusable
> and we were forced to switch to plain cvs.sourceforge.net?

Yes, they announced the change, but only last week.

Anthony
--
Anthony Williams
Software Developer
Just Software Solutions Ltd
http://www.justsoftwaresolutions.co.uk

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost