[1.45] Where are we in the release process?
I'm asking because someone's just assigned a Boost.Interval issue to me: https://svn.boost.org/trac/boost/ticket/4799#comment:1 Seems like there is a trivial fix in Trunk, but as the library appears not to have been maintained for while, it looks like none of the patches that some folks have applied to Trunk have been merged to release :-( On a related note, I believe there are quite a few old and unmerged changes to the Utility lib as well. We really need to figure out a better way of dealing with this... John.
On 10/29/2010 5:03 AM, John Maddock wrote:
I'm asking because someone's just assigned a Boost.Interval issue to me: https://svn.boost.org/trac/boost/ticket/4799#comment:1
Seems like there is a trivial fix in Trunk, but as the library appears not to have been maintained for while, it looks like none of the patches that some folks have applied to Trunk have been merged to release :-(
On a related note, I believe there are quite a few old and unmerged changes to the Utility lib as well.
According to the schedule Beman sent around earlier, we are now only taking showstopper fixes. Beman?
We really need to figure out a better way of dealing with this...
It currently requires a lot of discipline from each developer to make sure every change they apply to trunk also ends up in release. I wonder if commits to trunk to schedule a nag mail to be sent to the submitter a week later that says, "Did you check the tests? Did you merge to release?" Or open a track ticket that says, "merge changelist xxx to release." -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Sat, Oct 30, 2010 at 1:12 AM, Eric Niebler <eric@boostpro.com> wrote:
On 10/29/2010 5:03 AM, John Maddock wrote:
We really need to figure out a better way of dealing with this...
It currently requires a lot of discipline from each developer to make sure every change they apply to trunk also ends up in release. I wonder if commits to trunk to schedule a nag mail to be sent to the submitter a week later that says, "Did you check the tests? Did you merge to release?" Or open a track ticket that says, "merge changelist xxx to release."
How about if the release managers do it for the maintainers instead, and back out changes from the release branch in case things break from the test cycle? -- Dean Michael Berris deanberris.com
On 10/29/2010 10:23 AM, Dean Michael Berris wrote:
On Sat, Oct 30, 2010 at 1:12 AM, Eric Niebler <eric@boostpro.com> wrote:
On 10/29/2010 5:03 AM, John Maddock wrote:
We really need to figure out a better way of dealing with this...
It currently requires a lot of discipline from each developer to make sure every change they apply to trunk also ends up in release. I wonder if commits to trunk to schedule a nag mail to be sent to the submitter a week later that says, "Did you check the tests? Did you merge to release?" Or open a track ticket that says, "merge changelist xxx to release."
How about if the release managers do it for the maintainers instead, and back out changes from the release branch in case things break from the test cycle?
The release managers need less to do, not more. Unless you're volunteering. :-) -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Sat, Oct 30, 2010 at 2:06 AM, Eric Niebler <eric@boostpro.com> wrote:
On 10/29/2010 10:23 AM, Dean Michael Berris wrote:
How about if the release managers do it for the maintainers instead, and back out changes from the release branch in case things break from the test cycle?
The release managers need less to do, not more. Unless you're volunteering. :-)
Ha! Touche. :D Maybe if Boost libraries are finally using Git, I *might* consider working with branches. ;) -- Dean Michael Berris deanberris.com
Dean Michael Berris wrote:
On Sat, Oct 30, 2010 at 2:06 AM, Eric Niebler <eric@boostpro.com> wrote:
On 10/29/2010 10:23 AM, Dean Michael Berris wrote:
How about if the release managers do it for the maintainers instead, and back out changes from the release branch in case things break from the test cycle?
The release managers need less to do, not more. Unless you're volunteering. :-)
Ha! Touche. :D Maybe if Boost libraries are finally using Git, I *might* consider working with branches. ;)
So, do I understand correctly that you don't volunteer? If so, it's probably not important what's your faviourite version control system is ;-) It's-the-process-not-tools-yours, Volodya
On Sat, Oct 30, 2010 at 2:46 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Dean Michael Berris wrote:
Ha! Touche. :D Maybe if Boost libraries are finally using Git, I *might* consider working with branches. ;)
So, do I understand correctly that you don't volunteer?
Yeah, not at this time. ;) I'm still working on other potential contributions to Boost aside from trying to help maintain existing libraries. Maybe after 1.45 is released. :D
If so, it's probably not important what's your faviourite version control system is ;-)
You're right. It doesn't matter why my favorite is, but it matters that Boost isn't using it -- which greatly affects my wanting to contribute to release management or even helping maintain existing libraries. ;)
It's-the-process-not-tools-yours,
Saying-it's-better-to-have-good-processes-and-good-tools-than-just-having-processes'ly yours, (LOL) :D -- Dean Michael Berris deanberris.com
Eric Niebler wrote:
On 10/29/2010 5:03 AM, John Maddock wrote:
I'm asking because someone's just assigned a Boost.Interval issue to me: https://svn.boost.org/trac/boost/ticket/4799#comment:1
Seems like there is a trivial fix in Trunk, but as the library appears not to have been maintained for while, it looks like none of the patches that some folks have applied to Trunk have been merged to release :-(
On a related note, I believe there are quite a few old and unmerged changes to the Utility lib as well.
According to the schedule Beman sent around earlier, we are now only taking showstopper fixes. Beman?
We really need to figure out a better way of dealing with this...
It currently requires a lot of discipline from each developer to make sure every change they apply to trunk also ends up in release. I wonder if commits to trunk to schedule a nag mail to be sent to the submitter a week later that says, "Did you check the tests? Did you merge to release?" Or open a track ticket that says, "merge changelist xxx to release."
I guess it's better to nag the maintainer of a library, given that merging just once is a sensible strategy. On which note -- do we have up-to-date list of maintainers? Or, do we know the maintainer of libs/maintainers.txt? It appears to contain entries where a different person is know to maintain that library recently, or where the listed maintainer is known to be MIA, or have officially declared he's not maintaining that library. - Volodya
On 29 October 2010 19:59, Vladimir Prus <vladimir@codesourcery.com> wrote:
On which note -- do we have up-to-date list of maintainers? Or, do we know the maintainer of libs/maintainers.txt? It appears to contain entries where a different person is know to maintain that library recently, or where the listed maintainer is known to be MIA, or have officially declared he's not maintaining that library.
I don't think it has a maintainer, it's meant to be developers' responsibility to keep it up to date. We check that new libraries have an entry but that's about it. The way that we deal with this kind of shared data is pretty bad, it's duplicated in several places (the maintainers list, lib/libraries.htm, the website, Trac) which requires a lot of maintenance that often goes undone. It shouldn't be too hard to generate most of that from a single information source, maybe some sort of metadata file in the library directory? Daniel
Daniel James wrote:
On 29 October 2010 19:59, Vladimir Prus <vladimir@codesourcery.com> wrote:
On which note -- do we have up-to-date list of maintainers? Or, do we know the maintainer of libs/maintainers.txt? It appears to contain entries where a different person is know to maintain that library recently, or where the listed maintainer is known to be MIA, or have officially declared he's not maintaining that library.
I don't think it has a maintainer, it's meant to be developers' responsibility to keep it up to date. We check that new libraries have an entry but that's about it.
The way that we deal with this kind of shared data is pretty bad, it's duplicated in several places (the maintainers list, lib/libraries.htm, the website, Trac) which requires a lot of maintenance that often goes undone. It shouldn't be too hard to generate most of that from a single information source, maybe some sort of metadata file in the library directory?
Maybe. For example, it's always possible to make Jamfile present for all libraries, right at libs/somelib, and report some metatadata. - Volodya
On 30 October 2010 23:10, Vladimir Prus <vladimir@codesourcery.com> wrote:
Daniel James wrote:
The way that we deal with this kind of shared data is pretty bad, it's duplicated in several places (the maintainers list, lib/libraries.htm, the website, Trac) which requires a lot of maintenance that often goes undone. It shouldn't be too hard to generate most of that from a single information source, maybe some sort of metadata file in the library directory?
Maybe. For example, it's always possible to make Jamfile present for all libraries, right at libs/somelib, and report some metatadata.
I'm not sure what you mean. I'm referring to things like the library name, a short description, categories, library authors, current maintainers, documentation location. I wouldn't have thought that was the kind of thing a build system would be concerned with. Daniel
Daniel James wrote:
On 30 October 2010 23:10, Vladimir Prus <vladimir@codesourcery.com> wrote:
Daniel James wrote:
The way that we deal with this kind of shared data is pretty bad, it's duplicated in several places (the maintainers list, lib/libraries.htm, the website, Trac) which requires a lot of maintenance that often goes undone. It shouldn't be too hard to generate most of that from a single information source, maybe some sort of metadata file in the library directory?
Maybe. For example, it's always possible to make Jamfile present for all libraries, right at libs/somelib, and report some metatadata.
I'm not sure what you mean. I'm referring to things like the library name, a short description, categories, library authors, current maintainers, documentation location. I wouldn't have thought that was the kind of thing a build system would be concerned with.
Library name and short description is a metadata that a build system can make good use of -- say, .pc files as used by pkg-config can have that. - Volodya
Sorry for the slow replies. On 4 November 2010 17:41, Vladimir Prus <vladimir@codesourcery.com> wrote:
Maybe. For example, it's always possible to make Jamfile present for all libraries, right at libs/somelib, and report some metatadata.
We'd probably also need metadata in sub-directories.
Library name and short description is a metadata that a build system can make good use of -- say, .pc files as used by pkg-config can have that.
OK, is this something you'd be willing to do, because I wouldn't know how to do it in boost build. It could possibly produce a text file containing the data in an easy to use format (such as json or xml?), or I suppose with the python port it could just create a nested dict. There's no rush, I could create a ticket for later? Daniel
On 1:59 PM, Vladimir Prus wrote:
Eric Niebler wrote:
On 10/29/2010 5:03 AM, John Maddock wrote: [...]
We really need to figure out a better way of dealing with this... It currently requires a lot of discipline from each developer to make sure every change they apply to trunk also ends up in release. I wonder if commits to trunk to schedule a nag mail to be sent to the submitter a week later that says, "Did you check the tests? Did you merge to release?" Or open a track ticket that says, "merge changelist xxx to release." I guess it's better to nag the maintainer of a library, given that merging just once is a sensible strategy.
This seems like another thing that a group of volunteers could do. It doesn't require intimate familiarity with the library, but a careful eye comparing regression tests: trunk vs release . If trunk passes more than release with no new mysteries introduced, all trunk changes can be merged. The volunteers, then, would inspect and certify to the release manager that this was the case, and the manager do the merge with confidence. Minimal work for the release manager. No special permissions for the volunteers (i.e., a larger group of folks whose work you're much-less familiar with wouldn't be given power to make changes). Even teams of two volunteers, checking each others' work. Reasonable?
On which note -- do we have up-to-date list of maintainers? Or, do we know the maintainer of libs/maintainers.txt? It appears to contain entries where a different person is know to maintain that library recently, or where the listed maintainer is known to be MIA, or have officially declared he's not maintaining that library.
Particularly valuable when the maintainer is MIA.
participants (6)
-
Daniel James -
Dean Michael Berris -
Eric Niebler -
Jim Bell -
John Maddock -
Vladimir Prus