qinit: no default value for branch/repository format

[Olof Bjarnason]

Reproduce:

1. Create a new folder
2. Right-click inside the folder, choose "Bazaar Init..." command
3. Click OK button in TortoizeBZR dialog
4. Get following output in "console panel" at bottom of dialog:
Run command: bzr init --format= C:\Temp\Nymapp
bzr: ERROR: Bad value "" for option "format".

Workaround: Change the Repository Format combo box to "2a".

[Olof Bjarnason (objarni)]

Hmm I have a short question; is QBzr the same thing as TortoiseBZR..? Maybe I've added this bug to the wrong project on launchpad?

[Alexander Belchenko (bialix)]

Olof Bjarnason пишет:
> Hmm I have a short question; is QBzr the same thing as TortoiseBZR..?
> Maybe I've added this bug to the wrong project on launchpad?

TortoiseBzr is using many GUI dialogs from QBzr. So QBzr there is just
separate project which is used by TBZR as library. Is it makes sense for
you?

Don't worry about filing bug to wrong project, we know how to change
project if needed.

[Olof Bjarnason (objarni)]

Alexander - ah thank you. QBzr is the "library" and TortoiseBZR is the "application". It makes sense :)

[Olof Bjarnason (objarni)]

I added an "affects project" link to TortoiseBZR - hope that was OK?

[Alexander Belchenko (bialix)]

Olof Bjarnason пишет:
> I added an "affects project" link to TortoiseBZR - hope that was OK?

"Affects project" means that bug need to be fixed in several projects. In this particular case I can
reproduce this bug even without TortoiseBzr, so I don't think we need to fix it in TortoiseBzr.

[Ian Clatworthy (ian-clatworthy)]

Alexander Belchenko wrote:
> Olof Bjarnason пишет:
>> I added an "affects project" link to TortoiseBZR - hope that was OK?
>
> "Affects project" means that bug need to be fixed in several projects. In this particular case I can
> reproduce this bug even without TortoiseBzr, so I don't think we need to fix it in TortoiseBzr.
>

Really? I think it's fine to leave a bug as affecting multiple projects
if it's quite likely someone else which duplicate it. For example, the
"missing toolbars" problem is a windows packaging bug but I'm ok with
having it listed under the explorer bugs until the fixed.

I'm not saying you're wrong btw, just that I think the actual best
practice is arguably grey at times.

Ian C.

[Alexander Belchenko (bialix)]

Ian Clatworthy пишет:
> Alexander Belchenko wrote:
>> Olof Bjarnason пишет:
>>> I added an "affects project" link to TortoiseBZR - hope that was OK?
>> "Affects project" means that bug need to be fixed in several projects. In this particular case I can
>> reproduce this bug even without TortoiseBzr, so I don't think we need to fix it in TortoiseBzr.
>>
>
> Really? I think it's fine to leave a bug as affecting multiple projects
> if it's quite likely someone else which duplicate it. For example, the
> "missing toolbars" problem is a windows packaging bug but I'm ok with
> having it listed under the explorer bugs until the fixed.
>
> I'm not saying you're wrong btw, just that I think the actual best
> practice is arguably grey at times.

Well, from user point of view -- you're right. But as developer/maintainer I found non-relevant bugs
in the project a bit distracting.

[Olof Bjarnason (objarni)]

Ian & Alexander, I looked around a little and there is a "bug" filed for Launchpad itself regarding the wording "Also affects project". Look at it here: https://bugs.launchpad.net/malone/+bug/528786

But I can't see what the point of the whole "affect system" is, if it is not supposed to work like Ian and I expected ("the user view").

Maybe Alexander can shed some light on a "real usage" of "Also affects project"?

[Alexander Belchenko (bialix)]

Olof Bjarnason пишет:
> Ian & Alexander, I looked around a little and there is a "bug" filed for
> Launchpad itself regarding the wording "Also affects project". Look at
> it here: https://bugs.launchpad.net/malone/+bug/528786
>
> But I can't see what the point of the whole "affect system" is, if it is
> not supposed to work like Ian and I expected ("the user view").
>
> Maybe Alexander can shed some light on a "real usage" of "Also affects
> project"?

I don't have a real answer on this.

It depends on how TBZR maintainer (Naoki) working with bugs. I've
described my preffered way to work with bugs in QBzr.

The best status of this bug for TBZR could be "Won't Fix", because this
bug cannot be fixed in TBZR itself.

Does it sounds OK for you? Ian?

[Ian Clatworthy (ian-clatworthy)]

Alexander Belchenko wrote:

> Does it sounds OK for you? Ian?

My preference is for bugs to just be assigned to the project where the
bugs needs to be fixed. I was simply saying that, at times, we ought to
relax that in light of how users see things, particularly for "obvious"
bugs that multiple people are likely to report.

Ian C.

[Olof Bjarnason (objarni)]

Actually I think this is a problem with Launchpad itself. It should be clarified what "Also affects project" really is supposed to be about.

One idea I had now is that "Also affects project" works as Ian and I expected (gets added to a "higher level" project's issue list), but that it is flagged with some tag/status indicating it is a "issue within a lower level project".

Then, when the higher-level project developers list current bugs, they can choose whether they want to see those lower-level bugs affecting them or not. Maybe the default search should be "not see them" - if I understand Alexanders sentiment above correctly Naoki and he does not really want to see bugs from within dependencies in their own project.

The value with the whole Affects-system would be that lower-level project developers could get an indication of how important a certain bug is (how many projects/people are dependent on it's fixing).

[Olof Bjarnason (objarni)]

Ian - I wrote my comment before your comment showed up.

What you say makes sense. A lower-level issue should not be duplicated to a higher-level project (duplication is bad!).

Isn't it valuable, though, for both the higher-level project developers/users aswell as the lower-level project developers/users to be able to see what issues are with their respective projects, regardless of the location of the issue? After all, both projects are affected by the issue, in one way or the other.

So maybe adding a project to the "Also affects projects"-link should do this:

1. Show up in the issues' list (as TortoiseBZR does in this issue)
2. Show up in the project where the issue is located (QBzr in this case)
3. Show up in the affected projects "known bugs in lower-level projects" (I don't know if there actually is such a list yet - might be an improvement of Launchpad)

I for one would find it usable to know what bugs are known in all of the software my project depends on, instead of having to traverse each issue list in every sub-project (and sub-sub-project ..).