Proposal for radically altered approach to releases

[Stefan Seefeld]

David Abrahams wrote:

>> abrahams@...:/cvsroot/boost
>
> Oh, that's just intolerable.  Did they even announce the change??!

They did, to project admins, last week (11/5).

FWIW, there are tools to recursively adjust CVS/ metadata, though
that should be easy enough to script by hand.

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

[Anthony Williams-3]

Stefan Seefeld <seefeld@...> writes:

> David Abrahams wrote:
>
>>> abrahams@...:/cvsroot/boost
>>
>> Oh, that's just intolerable.  Did they even announce the change??!
>
> They did, to project admins, last week (11/5).
>
> FWIW, there are tools to recursively adjust CVS/ metadata, though
> that should be easy enough to script by hand.

find /projects/boost-cvs -name Root -exec sed -i -e \
s/cvs.sourceforge.net/boost.cvs.sourceforge.net/ \{} \;

It took a few minutes to run on my box; not a big deal.

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

[David Abrahams]

Stefan Seefeld <seefeld@...> writes:

> David Abrahams wrote:
>
>>> abrahams@...:/cvsroot/boost
>>
>> Oh, that's just intolerable.  Did they even announce the change??!
>
> They did, to project admins, last week (11/5).

That would be me, among others.  I don't recall ever seeing such an
announcement.  If I had seen it, I'd have posted it here.

> FWIW, there are tools to recursively adjust CVS/ metadata, though
> that should be easy enough to script by hand.

Yeah, easy enough, especially with Ralf's helpful formula.

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

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

[David Abrahams]

"Jeff Garland" <jeff@...> writes:

> 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...

Why not just create a tracker at SF, Jeff?

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

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

[David Abrahams]

David Abrahams <dave@...> writes:

>>   - 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.

Oh, I wasn't thinking.  All my recent changes to concept_check are on
the trunk.  Jeremy created this test, which IIUC just shows how broken
every standard library implementation on the planet is.  Jeremy, I
think the chips are down and you need to decide what to do about this.

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

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

[Thomas Witt-2]

Hi,

I am just replying to Jeff for convenience as he brings up a few points
I like to addressed.


Jeff Garland wrote:

> 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.

Boost.Build is not the only issue that is causing a stall. Though it
being basic infrastructure it's part of some chicken and egg issues.
I.e. I can't fix unless testing works finding build issues is hindered
by other outstanding issues. AFAICS this makes for slow progress. If
anybody here is worth to single out it's me for not putting on the
screws harder.

>
> 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.

The regression results are readily available. Even without the nag I
think it's reasonable to assume for developers to check them. I am not
pointing that out as an accusation but to show that we all work under
certain time constraints and that they seem to make impossible what
otherwise might be reasonably expected.

The reason for the nag to be still inactive is that I was not convinced
that not a significant part of the nagging is about testing/build
issues, I need to review this decision given the current situation. I
did not want people to ignore it for a low signal to noise ratio.


>  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.

Yes.

>
> 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.

I've been giving this some thought and frankly I am not so optimistic.
The whole idea of stability is based on reverting to a known stable
state. I think this idea is flawed in that we are operating in an ever
changing environment. If you looked at the regression table few entries
are of the what used to work is now broken variety. Compiler and OS
changes are issues that can't be dealt with by reverting. Library
interdependencies are another issue. Let's say lib A uses some
undocumented feature/corner-case of lib B what happens if B is upgraded
and breaks A? Who is at fault who is responsible, who finds out?

I think the biggest potential in improving things is to better handle
change. The biggest issue here is infrastructure to me. Somebody already
mentioned testing resources turnaround times and compiler availability.
As I've learned the hard way the supporting infrastructure for boost is
huge and there are not always clear responsibilities. Given this the
reliability is just insufficient. Most people here are part time
boosters they just don't have the time to learn all the intricate
details of the system, so every failure is a stumbling block. AFAICS the
problem starts at the sf level. We have seen way to many
outages/breaking changes recently. As an example regression testing
looks broken due to their server renaming. In my opinion being able to
run the nagging script continuously would go a long way and this goal
does not even interfere with the "stable branch" idea but is a
prerequisite AFAICS.


> 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.

In general I agree, I just don't think it (alone) fixes the problem.

Thomas

--
Thomas Witt
witt@...

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

[Beman Dawes]

"Thomas Witt" <witt@...> wrote in message
news:e42uk4$ibl$1@......

>
> 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.

The proposal to radically alter the release approach is motivated by a
general need to scale up the release process as Boost grows, and to decouple
releases for unrelated libraries.

It isn't a particular problem with 1.34, or any particular release. So
please don't take the proposal as a criticism of any release or the people
working on any release.

--Beman



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

[Beman Dawes]

"Nicola Musatti" <Nicola.Musatti@...> wrote in message
news:loom.20060512T133243-385@......

> 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.

With SVN, the distinction between a branch and a tag is blurred. They are
both really just (virtual) copies at a given point in time. It is up to us
exactly how we want to organize the releases we do.

If I understand you correctly, you are pointing out that sometimes we may
want an explicit bugfix branch of STABLE rather than just moving on to the
next week's STABLE tag point. We can certainly do that if useful. At this
point, I'm not sure we want to try to micro-manage those future decisions.
Rather, we can just make adjustments as we gain experience.

> 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.

I thought of that, but decided to recommend keeping the initial scheme
simple and a continuation of the current, familiar numbering scheme.

Thanks,

--Beman





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

[Beman Dawes]

"Thorsten Ottosen" <thorsten.ottosen@...> wrote in message
news:4463A34E.1060400@......

> 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?

Yes. The upgrade to A is a breaking change that affects other libraries. So
even though the new version of A works well and is itself stable, it should
not be merged to STABLE until all other libraries that depend on it are
stable. Then all of the libraries involved should be merged into STABLE at
the same time.

I've updated the doc to make that clearer.

Thanks,

--Beman



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

[Beman Dawes]

"David Abrahams" <dave@...> wrote in message
news:ud5eiorfd.fsf@......

> 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.

Point taken, although I'm not sure how serious a problem it is.

If it is a real problem, maybe something link this:

   Step one: developers during the week merge into a "next" branch of
stable.
   Step two: once a cycle (tentatively weekly), a single merge of the "next"
branch into stable head is done.

--Beman






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

[David Abrahams]

David Abrahams <dave@...> writes:

> 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.

Any comment here?  Why the time slots?

--
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:

> "David Abrahams" <dave@...> wrote in message
> news:ud5eiorfd.fsf@......
>> 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.
>
> Point taken, although I'm not sure how serious a problem it is.
>
> If it is a real problem, maybe something link this:
>
>    Step one: developers during the week merge into a "next" branch of
> stable.
>    Step two: once a cycle (tentatively weekly), a single merge of the "next"
> branch into stable head is done.

I still don't understand why we'd bother with either approach.  What
problem are you solving.

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

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

[Michael Fawcett]

On 5/17/06, David Abrahams <dave@...> wrote:

>
> "Beman Dawes" <bdawes@...> writes:
>
> > "David Abrahams" <dave@...> wrote in message
> >>
> >> 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.
> >
> > Point taken, although I'm not sure how serious a problem it is.
> >
> > If it is a real problem, maybe something link this:
> >
> >    Step one: developers during the week merge into a "next" branch of
> > stable.
> >    Step two: once a cycle (tentatively weekly), a single merge of the
> "next"
> > branch into stable head is done.
>
> I still don't understand why we'd bother with either approach.  What
> problem are you solving.
>

How long do regression tests take to run?  My understanding was that they
took a while.  If a library maintainer is allowed to merge into stable while
a regression test is taking place, does the stable branch remain untested
until the regression testing takes place again (two days later), or does it
kick off another regression test?

I'm unclear how the flow of events take place if you don't lock for
regression testing.

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

[David Abrahams]

"Michael Fawcett" <michael.fawcett@...> writes:

> How long do regression tests take to run?  My understanding was that
> they took a while.

Depends on the site, of course, but yes, "a while" is not inaccurate.

> If a library maintainer is allowed to merge into stable while
> a regression test is taking place, does the stable branch remain untested
> until the regression testing takes place again (two days later), or does it
> kick off another regression test?

We get to decide, I suppose.

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

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

[Thomas Witt-2]

Beman,

Beman Dawes wrote:

> "Thomas Witt" <witt@...> wrote in message
> news:e42uk4$ibl$1@......
>
> The proposal to radically alter the release approach is motivated by a
> general need to scale up the release process as Boost grows, and to decouple
> releases for unrelated libraries.
>
> It isn't a particular problem with 1.34, or any particular release. So
> please don't take the proposal as a criticism of any release or the people
> working on any release.

I didn't take it personally and if I haven't made that clear my intent
wasn't to criticize or single out boost.build either. I was just trying
to point out that the proposal does not address one of the main issues
in this release.

IIUC that wasn't goal of the proposal, I just wanted people to
understand that there are other issues.

Thomas

PS: For a more general comment see my reply to Jeff


--
Thomas Witt
witt@...

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

[Nicola Musatti]

Beman Dawes wrote:
[...]
> With SVN, the distinction between a branch and a tag is blurred. They are
> both really just (virtual) copies at a given point in time. It is up to us
> exactly how we want to organize the releases we do.

I see.

> If I understand you correctly, you are pointing out that sometimes we may
> want an explicit bugfix branch of STABLE rather than just moving on to the
> next week's STABLE tag point. We can certainly do that if useful. At this
> point, I'm not sure we want to try to micro-manage those future decisions.
> Rather, we can just make adjustments as we gain experience.

This sounds reasonable. While it is unreasonable to waste resources on
things that just may be useful, but aren't necessary, I feel it is just
as important not to close the way in advance to exceptions to the main
strategy. From what you write I see this is not the case, so your
proposal is fine with me as it stands now.

Cheers,
Nicola Musatti

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

[Kenneth Porter]

On Friday, May 12, 2006 8:43 AM +0100 Russell Hind <rh_gmane@...> wrote:

> 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.

I'm using this on Linux:

<http://svnwcrev.tigris.org/>


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