Please help with the Git Transition

[Dave Abrahams]

As I am currently in a whirlwind of preparation to move my family across
the country to California, I have tried to set everything up so the
transition to Git could make progress without *too* much of my
attention. I hope some other people can move the project forward during
the next two weeks.

IMO we should organize the project around this tracker:
https://github.com/ryppl/boost-svn2git/issues. Beman, it would be
helpful if you'd move the information from
https://svn.boost.org/trac/boost/wiki/MoveToModularizedGit to there and
update any other pages on https://svn.boost.org/trac/boost/wiki that you
deem relevant.

Thanks everybody!

--
Dave Abrahams

[Beman Dawes]

I'll start on that tomorrow morning.

--Beman

[Beman Dawes]

On Wed, Feb 6, 2013 at 11:16 AM, Dave Abrahams <da...@boostpro.com> wrote:
>

First cut done. It seemed to me that "Milestones" rather than "Issues"
better suited our most of our needs, so six milestones and one issue
have been created.

See https://github.com/ryppl/boost-svn2git/issues/milestones

> Thanks everybody!

You are the one who deserves special thanks! To be moving to a new job
on the other side of the country, and still find time to help with
this important Boost conversion is very special and much appreciated!

--Beman

[Dave Abrahams]

on Fri Feb 08 2013, Beman Dawes <bdawes-AT-acm.org> wrote:

> On Wed, Feb 6, 2013 at 11:16 AM, Dave Abrahams <da...@boostpro.com> wrote:
>>
>> As I am currently in a whirlwind of preparation to move my family across
>> the country to California, I have tried to set everything up so the
>> transition to Git could make progress without *too* much of my
>> attention. I hope some other people can move the project forward during
>> the next two weeks.
>>
>> IMO we should organize the project around this tracker:
>> https://github.com/ryppl/boost-svn2git/issues. Beman, it would be
>> helpful if you'd move the information from
>> https://svn.boost.org/trac/boost/wiki/MoveToModularizedGit to there and
>> update any other pages on https://svn.boost.org/trac/boost/wiki that you
>> deem relevant.
>
> First cut done. It seemed to me that "Milestones" rather than "Issues"
> better suited our most of our needs, so six milestones and one issue
> have been created.

Hmm, I don't think these milestones will be effective unless you
eventually attach issues to them, will they? Otherwise, how do they
become "done?"

--
Dave Abrahams

[Beman Dawes]

Apparently you have to attach a tracker issue, and then close it to
cause the milestone to close. The milestone feature is seriously
lacking, but it is good enough for a project like this where we can
mentally visualize the critical paths.

To mark one of the individual steps in a milestone as done, change the
"- [ ]" to "- [x]" and a check mark will appear in the step's
check-off box.

--Beman

[David Abrahams]

I know how the checkboxes work. You can just click them directly if you want. But it seems like—for reasons I don't understand—you want to use the system in an unorthodox way. Why is it a good idea to use checkboxes in milestones with a single fake issue rather than just using issues in milestones? If you use checkboxes, you can't assign each one to different people, and that's just the most glaring disadvantage.

[Beman Dawes]

On Sat, Feb 9, 2013 at 8:42 PM, David Abrahams <da...@boostpro.com> wrote:
>
> On Feb 8, 2013, at 4:41 PM, Beman Dawes <bda...@acm.org> wrote:
>
>> On Fri, Feb 8, 2013 at 12:02 PM, Dave Abrahams <da...@boostpro.com> wrote:
>>>
>>> on Fri Feb 08 2013, Beman Dawes <bdawes-AT-acm.org> wrote:
>>>

....

>>>> First cut done. It seemed to me that "Milestones" rather than "Issues"
>>>> better suited our most of our needs, so six milestones and one issue
>>>> have been created.
>>>
>>> Hmm, I don't think these milestones will be effective unless you
>>> eventually attach issues to them, will they? Otherwise, how do they
>>> become "done?"
>>
>> Apparently you have to attach a tracker issue, and then close it to
>> cause the milestone to close. The milestone feature is seriously
>> lacking, but it is good enough for a project like this where we can
>> mentally visualize the critical paths.
>>
>> To mark one of the individual steps in a milestone as done, change the
>> "- [ ]" to "- [x]" and a check mark will appear in the step's
>> check-off box.
>
> I know how the checkboxes work. You can just click them directly if you want. But it seems like—for reasons I don't understand—you want to use the system in an unorthodox way. Why is it a good idea to use checkboxes in milestones with a single fake issue rather than just using issues in milestones?

It is an attempt to keep the focus on the bigger picture action items,
rather than get lost in the details.

I have an intense dislike for tracking systems that focus on progress
with individual issues rather than focusing on progress toward overall
completion. They are useful for bug tracking but not for project
management. Issue based tracking without a critical path component can
create an illusion of progress for projects that are in fact moving
backward rather than forward. Such tracking was a key factor in the
two most serious project failures I had the misfortune to see. Tacking
a milestone system on top of a bug tracker doesn't turn a bug tracker
into a project management system. They are different animals.

> If you use checkboxes, you can't assign each one to different people, and that's just the most glaring disadvantage.

Just tag each item with the person responsible. I.E. "(Jane Doe)".

--Beman

[Dave Abrahams]

Milestones will tell you how close they are to completion... but only if
you divide them into issues.

> They are useful for bug tracking but not for project management. Issue
> based tracking without a critical path component can create an
> illusion of progress for projects that are in fact moving backward
> rather than forward.

Where's the critical path component in what you set up?

> Such tracking was a key factor in the two most serious project
> failures I had the misfortune to see. Tacking a milestone system on
> top of a bug tracker doesn't turn a bug tracker into a project
> management system. They are different animals.
>
>> If you use checkboxes, you can't assign each one to different
>> people, and that's just the most glaring disadvantage.
>
> Just tag each item with the person responsible. I.E. "(Jane Doe)".

I still don't understand what you're doing here or why it's better, but
as long as you are taking responsibility for "project management" I
guess I don't care. I think you will find it harder to manage other
people on this project unless you explain how your system is supposed to
work, though. Should nobody ever create an issue in this tracker?
Those are the kinds of question your explanation should cover.

--
Dave Abrahams

[Beman Dawes]

On Sun, Feb 10, 2013 at 1:10 PM, Dave Abrahams <da...@boostpro.com> wrote:
>
> on Sun Feb 10 2013, Beman Dawes <bdawes-AT-acm.org> wrote:

> Milestones will tell you how close they are to completion... but only if
> you divide them into issues.
>
>> They are useful for bug tracking but not for project management. Issue
>> based tracking without a critical path component can create an
>> illusion of progress for projects that are in fact moving backward
>> rather than forward.
>
> Where's the critical path component in what you set up?

There isn't one:-)

>>> If you use checkboxes, you can't assign each one to different
>>> people, and that's just the most glaring disadvantage.
>>
>> Just tag each item with the person responsible. I.E. "(Jane Doe)".
>
> I still don't understand what you're doing here or why it's better, but
> as long as you are taking responsibility for "project management" I
> guess I don't care.

I was hoping to avoid taking responsibility for "project management"
but that might be best. The release managers are starting to need
coordination with the conversion as we start focusing on the next
release.

> I think you will find it harder to manage other
> people on this project unless you explain how your system is supposed to
> work, though. Should nobody ever create an issue in this tracker?
> Those are the kinds of question your explanation should cover.

Right. I'll start that on the Ryppl list.

--Beman

[Dave Abrahams]

on Mon Feb 11 2013, Beman Dawes <bdawes-AT-acm.org> wrote:

>> I think you will find it harder to manage other people on this
>> project unless you explain how your system is supposed to work,
>> though. Should nobody ever create an issue in this tracker? Those
>> are the kinds of question your explanation should cover.
>
> Right. I'll start that on the Ryppl list.

I'm very concerned about this.

Also, the repository being used for that particular tracker no longer
has any useful code in it. I'm moving the status Wiki page over to
github.com/ryppl/Boost2Git


--
Dave Abrahams