Re: Device mount point is disabled (and fixed to wrong device)

[Rob Mason]

Hi Jef

Yes, I think I may be having issues with irda and Mint rather than
Subsurface.  Here's what I can see from dmesg:

usb 2-1.2: new full-speed USB device number 3 using ehci-pci
usb 2-1.2: New USB device found, idVendor=066f, idProduct=4200
usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-1.2: Product:  IrDA/USB Bridge
usb 2-1.2: Manufacturer:  Sigmatel Inc
usbcore: registered new interface driver usbserial
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial support registered for generic
usbcore: registered new interface driver option
usbserial: USB Serial support registered for GSM modem (1-port)
option 2-1.2:1.0: GSM modem (1-port) converter detected
usb 2-1.2: GSM modem (1-port) converter now attached to ttyUSB0
usbcore: registered new interface driver stir4200

Here's the libdivecomputer logfile:

Subsurface: v4.7.6, built with libdivecomputer
v0.7.0-devel-Subsurface-branch (8ae735a4d70307ebe2a42d315697f02ce71dbe88)
ERROR: No dive computer found. [in uwatec_smart.c:182
(uwatec_smart_device_open)]

I assume subsurface needs to find irda0??




On 3 February 2018 at 20:00, Jef Driesen  wrote:

> On 03-02-18 18:05, Berthold Stoeger wrote:
>
>> On Samstag, 3. Februar 2018 17:46:10 CET Rob Mason wrote:
>>
>>> Hi Berthold - the subgear is irda, not bluetooth. It has worked
>>> previously
>>> on older versions, but unable to connect on 4.7.6-1 on Mint Linux 18.3.
>>> --
>>>
>>
>> Yes I know. Nevertheless, the "interface consistency fix" in commit
>> d23bd46
>> enables the device field only for serial transport.
>>
>> To my defense - I just copied old buggy code, but made it more
>> noticeable. I
>> pushed a fix to github. If you can compile from source, you can use this.
>> If
>> not, there is a workaround: Select a dive computer with serial transport
>> (I
>> think the XP-Air is), change the device and then go back to the XP-10.
>> This
>> should be saved to the preferences, so you only have to do it once (until
>> you
>> change dive computer).
>>
>
> The reason why the dropdown is disabled is because IrDA communication
> doesn't use a device node at all. Libdivecomputer will automatically
> discover the IrDA device address. So it doesn't matter what is shown in the
> dropdown box, because it's not used for anything.
>
> If the download fails because no dive computer is found, that means the
> discovery did not found any IrDA device (or at least not one that matches a
> known dive computer). Enable the libdivecomputer logfile checkbox and send
> us the log. That should tell us what is going on.
>
> Jef
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cloud PIN

[Dirk Hohndel]

On Sat, Feb 03, 2018 at 05:05:44PM +0100, harry.vanderv...@ziggo.nl wrote:
> Hello Dirk,
> 
> I am switched from mobile phones. I re-installed the mobile app. 
> 
> Bud my old Cloud PIN is not working anymore.
> 
> Can you please send me a new one. My E-mail address
> (  harry.vanderv...@ziggo.nl).

The PIN is only needed the very first time you connect to the Subsurface
cloud storage (it's used to verify that you gave us the correct email
adderss). After that, all you need is your email and password.

So I'm not quite sure what you are asking for...

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Device mount point is disabled (and fixed to wrong device)

[Jef Driesen]

On 03-02-18 18:05, Berthold Stoeger wrote:

On Samstag, 3. Februar 2018 17:46:10 CET Rob Mason wrote:

Hi Berthold - the subgear is irda, not bluetooth. It has worked previously
on older versions, but unable to connect on 4.7.6-1 on Mint Linux 18.3. --


Yes I know. Nevertheless, the "interface consistency fix" in commit  d23bd46
enables the device field only for serial transport.

To my defense - I just copied old buggy code, but made it more noticeable. I
pushed a fix to github. If you can compile from source, you can use this. If
not, there is a workaround: Select a dive computer with serial transport (I
think the XP-Air is), change the device and then go back to the XP-10. This
should be saved to the preferences, so you only have to do it once (until you
change dive computer).


The reason why the dropdown is disabled is because IrDA communication doesn't 
use a device node at all. Libdivecomputer will automatically discover the IrDA 
device address. So it doesn't matter what is shown in the dropdown box, because 
it's not used for anything.


If the download fails because no dive computer is found, that means the 
discovery did not found any IrDA device (or at least not one that matches a 
known dive computer). Enable the libdivecomputer logfile checkbox and send us 
the log. That should tell us what is going on.


Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Device mount point is disabled (and fixed to wrong device)

[Rob Mason]

Hi Berthold - the subgear is irda, not bluetooth. It has worked previously on 
older versions, but unable to connect on 4.7.6-1 on Mint Linux 18.3.
--
Rob Mason
07770 578764

On 3 February 2018 16:43:14 GMT+00:00, Berthold Stoeger 
 wrote:

Hi Rob,

On Samstag, 3. Februar 2018 12:57:18 CET Rob Mason wrote:
 Hi,

 I'm running Version 4.7.6 on linux Mint 18.3 - using a Subgear XP-10
 (infrared).

 My infrared adapter is found on /dev/ttyUSB1, but the 'Device or Mount
 Point' drop down list is disabled and fixed to /dev/ttyS30. Dive computer
 is not found. How can I changed this to /dev/ttyUSB1 ???

That looks like a change concerning the Bluetooth interface, which I made some
time ago. :( I'm looking into it.

Berthold

Acasta Ltd - A Crown Commercial Service Supplier. CyberEssentials Certified 
QGCE013.
Registered in England 6619191. 42 Pitt Street, Barnsley, S70 1BB. VAT 
Registered 934 6797 75.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Cloud PIN

[harry.vanderveen]

Hello Dirk,

I am switched from mobile phones. I re-installed the mobile app. 

Bud my old Cloud PIN is not working anymore.

Can you please send me a new one. My E-mail address
(  harry.vanderv...@ziggo.nl).

Kind regards,

Harry van der Veen

 

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Device mount point is disabled (and fixed to wrong device)

[Rob Mason]

Thanks - will give that a try.
--
Rob Mason
07770 578764

On 3 February 2018 17:05:00 GMT+00:00, Berthold Stoeger 
 wrote:

Hi,

On Samstag, 3. Februar 2018 17:46:10 CET Rob Mason wrote:
 Hi Berthold - the subgear is irda, not bluetooth. It has worked previously
 on older versions, but unable to connect on 4.7.6-1 on Mint Linux 18.3. --

Yes I know. Nevertheless, the "interface consistency fix" in commit  d23bd46
enables the device field only for serial transport.

To my defense - I just copied old buggy code, but made it more noticeable. I
pushed a fix to github. If you can compile from source, you can use this. If
not, there is a workaround: Select a dive computer with serial transport (I
think the XP-Air is), change the device and then go back to the XP-10. This
should be saved to the preferences, so you only have to do it once (until you
change dive computer).

Berthold

 Rob Mason
 07770 578764

 On 3 February 2018 16:43:14 GMT+00:00, Berthold Stoeger
  wrote:

 Hi Rob,

 On Samstag, 3. Februar 2018 12:57:18 CET Rob Mason wrote:
  Hi,

  I'm running Version 4.7.6 on linux Mint 18.3 - using a Subgear XP-10
  (infrared).

  My infrared adapter is found on /dev/ttyUSB1, but the 'Device or Mount
  Point' drop down list is disabled and fixed to /dev/ttyS30. Dive computer
  is not found. How can I changed this to /dev/ttyUSB1 ???

 That looks like a change concerning the Bluetooth interface, which I made
 some time ago. :( I'm looking into it.

 Berthold

 Acasta Ltd - A Crown Commercial Service Supplier. CyberEssentials Certified
 QGCE013. Registered in England 6619191. 42 Pitt Street, Barnsley, S70 1BB.
 VAT Registered 934 6797 75.



Acasta Ltd - A Crown Commercial Service Supplier. CyberEssentials Certified 
QGCE013.
Registered in England 6619191. 42 Pitt Street, Barnsley, S70 1BB. VAT 
Registered 934 6797 75.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: commit message titles and changelog entries

[Lubomir I. Ivanov]

On 3 February 2018 at 17:41, Dirk Hohndel  wrote:
>
>> On Feb 3, 2018, at 2:29 AM, Jan Mulder  wrote:
>>
>> On 03-02-18 10:30, Lubomir I. Ivanov wrote:
>>> i draw my experience (i.e. "where i've seen this") from a certain
>>> closed source software for audio engineers with an open-sourced
>>> backend and a fairly large and technical user base, where the users
>>> demand details from the updates.
>>> these developers follow the "release-small-release-often" model and
>>> their change logs look like this:
>>> # Regions: ensure time signature remains consistent at start/end
>>> of moved regions [p=1918885]
>>> or:
>>> :  [reference thread / issue]
>>> full log: https://forum.cockos.com/showpost.php?p=1919544&postcount=1
>>> i find this changelog useful for both developers and the wider public.
>>> if the users have questions about a certain vague entry, they have the
>>> means to ask us.
>>
>> Ok, looked at this, and this changelog is basically seems the output of git 
>> log. Useful for developers? No, they already have the tools for this. So 
>> while useful, it does does not add anything *new* for developers. Useful for 
>> users ... well I cannot speak for all users, but it would surprise me when 
>> the average Subsurface is really interested in git log style output.
>
> I don't think this level of details is useful for the typical user.

perhaps the bigger issue is that everyone adding changelog entries
uses a different style.
waiting on proposals from the the mailing list on how to standardize
the style for these a little.

>
>>> one convenient feature of Github is that it allows us to push commits
>>> on top of user PR branches to possibly add a commit touching the
>>> changelog.
>>
>> So ... the maintainer merging patching up the missing changelog stuff ... 
>> well ... that seems like babysitting to me. I would just review with: NAK, 
>> changelog missing/wrong.
>
> It's a fine line. I don't want to make it too hard to contribute, but yes, in 
> general requesting that the author adds a CHANGELOG entry seems fair.
>
 In general: ok. But I come back to my earlier remark: for who do we write
 the changelog?
>>
>> But what is missing in the discussion now, is an answer to this question. 
>> This answer cannot be a simple: for all users and developers and the website 
>> and Facebook announcements (as I do not believe that there is a unified list 
>> that suits all at the same time).
>
> I want to be able to copy from the ReleaseNotes (which are the target for the 
> CHANGELOG file, which exists to have fewer merge conflicts) to the 
> announcement. So what I want to see in there are user visible changes. High 
> level.
> So if I look at https://github.com/Subsurface-divelog/subsurface/pull/1091 
> I'd say that prior to applying the patch we had maybe too little detail. The 
> PR skirts being more verbose than I like, but I think it stays just barely on 
> the good side of things. My suggested changes would be basically nit-picking. 
> E.g., combine line 21+22, maybe drop line 19...
>

i have merged it. changes can be applied once copying to the ReleaseNotes files.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Device mount point is disabled (and fixed to wrong device)

[Berthold Stoeger]

Hi,

On Samstag, 3. Februar 2018 17:46:10 CET Rob Mason wrote:
> Hi Berthold - the subgear is irda, not bluetooth. It has worked previously
> on older versions, but unable to connect on 4.7.6-1 on Mint Linux 18.3. --

Yes I know. Nevertheless, the "interface consistency fix" in commit  d23bd46 
enables the device field only for serial transport.

To my defense - I just copied old buggy code, but made it more noticeable. I 
pushed a fix to github. If you can compile from source, you can use this. If 
not, there is a workaround: Select a dive computer with serial transport (I 
think the XP-Air is), change the device and then go back to the XP-10. This 
should be saved to the preferences, so you only have to do it once (until you 
change dive computer).

Berthold

> Rob Mason
> 07770 578764
> 
> On 3 February 2018 16:43:14 GMT+00:00, Berthold Stoeger
>  wrote:
> 
> Hi Rob,
> 
> On Samstag, 3. Februar 2018 12:57:18 CET Rob Mason wrote:
>  Hi,
> 
>  I'm running Version 4.7.6 on linux Mint 18.3 - using a Subgear XP-10
>  (infrared).
> 
>  My infrared adapter is found on /dev/ttyUSB1, but the 'Device or Mount
>  Point' drop down list is disabled and fixed to /dev/ttyS30. Dive computer
>  is not found. How can I changed this to /dev/ttyUSB1 ???
> 
> That looks like a change concerning the Bluetooth interface, which I made
> some time ago. :( I'm looking into it.
> 
> Berthold
> 
> Acasta Ltd - A Crown Commercial Service Supplier. CyberEssentials Certified
> QGCE013. Registered in England 6619191. 42 Pitt Street, Barnsley, S70 1BB.
> VAT Registered 934 6797 75.


___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Device mount point is disabled (and fixed to wrong device)

[Berthold Stoeger]

Hi Rob,

On Samstag, 3. Februar 2018 12:57:18 CET Rob Mason wrote:
> Hi,
> 
> I'm running Version 4.7.6 on linux Mint 18.3 - using a Subgear XP-10
> (infrared).
> 
> My infrared adapter is found on /dev/ttyUSB1, but the 'Device or Mount
> Point' drop down list is disabled and fixed to /dev/ttyS30. Dive computer
> is not found. How can I changed this to /dev/ttyUSB1 ???

That looks like a change concerning the Bluetooth interface, which I made some 
time ago. :( I'm looking into it.

Berthold
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: time for 4.7.7

[Willem Ferguson]

I am out of town diving Shearwater this weekend, interacting with the bt
interface. This needs some tlc in the user manual. But I can only do it Mon
evening. No other updates to user manual I am aware of. Kind regards,
Willem

On 02 Feb 2018 19:52, "Dirk Hohndel"  wrote:

Hi there,

I’m finally back and feeling well. Still catching up with all the activity
on GitHub - it’s so nice to see that things continue even if I’m not
available.
Thanks to Jan, Robert, Lubomir, and everyone else who kept things moving!

It’s been over a month since the last release, the CHANGELOG doesn’t show a
lot of exciting activity, but we decided to try for a much more steady
release cadence, so I think we should do this. I just pushed the latest
translations to Transifex (not a lot of new strings, but a hand full that
deserve translation). It would be nice if everyone could make sure that
nothing got broken and that we document what got fixed.

I think I’ll aim for Monday of next week - unless someone has objections.

Willem - are there any user manual changes that are still pending?

Thanks

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Device mount point is disabled (and fixed to wrong device)

[Rob Mason]

Hi,

I'm running Version 4.7.6 on linux Mint 18.3 - using a Subgear XP-10
(infrared).

My infrared adapter is found on /dev/ttyUSB1, but the 'Device or Mount
Point' drop down list is disabled and fixed to /dev/ttyS30. Dive computer
is not found. How can I changed this to /dev/ttyUSB1 ???

Thanks
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: commit message titles and changelog entries

[Dirk Hohndel]

> On Feb 3, 2018, at 2:29 AM, Jan Mulder  wrote:
> 
> On 03-02-18 10:30, Lubomir I. Ivanov wrote:
>> i draw my experience (i.e. "where i've seen this") from a certain
>> closed source software for audio engineers with an open-sourced
>> backend and a fairly large and technical user base, where the users
>> demand details from the updates.
>> these developers follow the "release-small-release-often" model and
>> their change logs look like this:
>> # Regions: ensure time signature remains consistent at start/end
>> of moved regions [p=1918885]
>> or:
>> :  [reference thread / issue]
>> full log: https://forum.cockos.com/showpost.php?p=1919544&postcount=1
>> i find this changelog useful for both developers and the wider public.
>> if the users have questions about a certain vague entry, they have the
>> means to ask us.
> 
> Ok, looked at this, and this changelog is basically seems the output of git 
> log. Useful for developers? No, they already have the tools for this. So 
> while useful, it does does not add anything *new* for developers. Useful for 
> users ... well I cannot speak for all users, but it would surprise me when 
> the average Subsurface is really interested in git log style output.

I don't think this level of details is useful for the typical user.

>> one convenient feature of Github is that it allows us to push commits
>> on top of user PR branches to possibly add a commit touching the
>> changelog.
> 
> So ... the maintainer merging patching up the missing changelog stuff ... 
> well ... that seems like babysitting to me. I would just review with: NAK, 
> changelog missing/wrong.

It's a fine line. I don't want to make it too hard to contribute, but yes, in 
general requesting that the author adds a CHANGELOG entry seems fair.

>>> In general: ok. But I come back to my earlier remark: for who do we write
>>> the changelog?
> 
> But what is missing in the discussion now, is an answer to this question. 
> This answer cannot be a simple: for all users and developers and the website 
> and Facebook announcements (as I do not believe that there is a unified list 
> that suits all at the same time).

I want to be able to copy from the ReleaseNotes (which are the target for the 
CHANGELOG file, which exists to have fewer merge conflicts) to the 
announcement. So what I want to see in there are user visible changes. High 
level.
So if I look at https://github.com/Subsurface-divelog/subsurface/pull/1091 I'd 
say that prior to applying the patch we had maybe too little detail. The PR 
skirts being more verbose than I like, but I think it stays just barely on the 
good side of things. My suggested changes would be basically nit-picking. E.g., 
combine line 21+22, maybe drop line 19...

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: commit message titles and changelog entries

[Jan Mulder]

On 03-02-18 10:30, Lubomir I. Ivanov wrote:


i draw my experience (i.e. "where i've seen this") from a certain
closed source software for audio engineers with an open-sourced
backend and a fairly large and technical user base, where the users
demand details from the updates.

these developers follow the "release-small-release-often" model and
their change logs look like this:
 # Regions: ensure time signature remains consistent at start/end
of moved regions [p=1918885]
or:
 :  [reference thread / issue]

full log: https://forum.cockos.com/showpost.php?p=1919544&postcount=1

i find this changelog useful for both developers and the wider public.
if the users have questions about a certain vague entry, they have the
means to ask us.


Ok, looked at this, and this changelog is basically seems the output of 
git log. Useful for developers? No, they already have the tools for 
this. So while useful, it does does not add anything *new* for 
developers. Useful for users ... well I cannot speak for all users, but 
it would surprise me when the average Subsurface is really interested in 
git log style output.





Nice, but a little too detailed to my liking. Are you thinking of some
automation/tooling behind it to check for these rules?


i think automating would just add another level of complication for
us. the maintainer merging the PRs should just proof read the change
log entries.
as long as they follow the consistent styling it would be OK for
certain entries to come up with custom areas / prefixes, even.


Agree. No tooling required, but I was just curious about further plans 
with this.




one convenient feature of Github is that it allows us to push commits
on top of user PR branches to possibly add a commit touching the
changelog.


So ... the maintainer merging patching up the missing changelog stuff 
... well ... that seems like babysitting to me. I would just review 
with: NAK, changelog missing/wrong.


But agree, the GitHub pushing to a PR of somebody else is nice, but at 
this moment I think that most of out contributors would be very 
surprised when they would receive a PR on their PR.




In general: ok. But I come back to my earlier remark: for who do we write
the changelog?


But what is missing in the discussion now, is an answer to this 
question. This answer cannot be a simple: for all users and developers 
and the website and Facebook announcements (as I do not believe that 
there is a unified list that suits all at the same time).


--jan
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: commit message titles and changelog entries

[Lubomir I. Ivanov]

On 3 February 2018 at 10:33, Jan Mulder  wrote:
> On 02-02-18 22:59, Lubomir I. Ivanov wrote:
>>
>> hello,
>>
>> 1)
>>
>> this suggestion is triggered by the need for streamlining the addition
>> of changelog entries by contributors in the CHANGELOG.md file.
>>
>> right now, we merge PRs that make an important change, but such PRs do
>> not append a change in the CHANGELOG.md file. adding notes in
>> CHANGELOG.md has to be made a requirement in PRs, otherwise before a
>> release one has to go over the usually big list of commits and find
>> relevant missing entries.
>
>
> Historically, we have pretty concise changelogs, more or less hand made, and
> relatively high level. Like "Numerous spelling errors", "Lots of small UI
> fixes". Obviously, this does tell only a part of the story, and possible
> relevant change can be forgotten in this process. So this does not seem the
> way to go.
>
> However, the big question is here: for who do we write the changelog? When
> it is for the website and announcements on internet, I tend to prefer the
> short and concise high level like we had, instead of a long list that seems
> correct and detailed enough (for who?).
>
> For example: in the PR 1091 one item is "Cloud-storage: support non-https://
> repositories for saving" ... yes I know where this is coming from ... but
> the general public?
>

i draw my experience (i.e. "where i've seen this") from a certain
closed source software for audio engineers with an open-sourced
backend and a fairly large and technical user base, where the users
demand details from the updates.

these developers follow the "release-small-release-often" model and
their change logs look like this:
# Regions: ensure time signature remains consistent at start/end
of moved regions [p=1918885]
or:
:  [reference thread / issue]

full log: https://forum.cockos.com/showpost.php?p=1919544&postcount=1

i find this changelog useful for both developers and the wider public.
if the users have questions about a certain vague entry, they have the
means to ask us.

>
>>
>> by doing that we also need a standardized CHANGELOG.md entry format.
>>
>> my suggestion is the following:
>>  - Area: change that was made (#github-link)
>>
>> examples:
>> - Planner: fixed a bug when moving data points (#32132)
>> - Mobile: fixed a bug when clicking button X. The bug also affected
>>menu X (#32132)
>>
>> notes about the format:
>> - the area name is uppercase
>> - lowecase after the "Area: ", should it be uppercase here?
>> - no period at the end of an entry only in-between sentences
>> - when there is a related issue a (#github-link) has to be added at the
>> end
>> - first line stats with "- " and no indentation. the next lines are
>> indented by "  ".
>>
>> example areas:
>> - Planner
>> - Mobile
>> - Desktop
>> - Bluetooth
>> - Map-widget
>> - Cloud-storage
>> - Uemis
>> - Import
>> - Export
>> - Profile
>> - Libdivecomputer
>>
>> opinions about this?
>
>
> Nice, but a little too detailed to my liking. Are you thinking of some
> automation/tooling behind it to check for these rules?

i think automating would just add another level of complication for
us. the maintainer merging the PRs should just proof read the change
log entries.
as long as they follow the consistent styling it would be OK for
certain entries to come up with custom areas / prefixes, even.

one convenient feature of Github is that it allows us to push commits
on top of user PR branches to possibly add a commit touching the
changelog..

>
>>
>> 2)
>>
>> for commit messages-  until now we have accepted commit messages that
>> do not specify an area, like these:
>> Fix bug when clicking button X
>> Small whitespace fix
>
>
> Fine for me. When I want to look at a commit, I do not only read the title,
> but also the rest of the text and even the code change if needed.
>
> In practice, it is often difficult to exactly pinpoint the area (and being
> concise). For example (from the PR 1091), "Bluetooth: do not add duplicate
> BT/BLE items", this mobile only, and it is even not (technically) restricted
> to Bluetooth. And the originating commit says "connectionList" and the
> related issue #1069 even says "mobile: During DC import, Rescan duplicates
> connections".
>

i guess that's true. i have followed this scheme for a long time for
my commits here and i try to always prefix a commit with "something: "
even if it's hard to come up with something.

>>
>> these are kind of vague, thus i would suggest requiring (perhaps not
>> strictly) an area prefix or a filename, like so:
>> Divelist: Fix bug when clicking button X
>> divelist.cpp: fix whitespace
>>
>> any opinions about this too?
>
>
> In general: ok. But I come back to my earlier remark: for who do we write
> the changelog?
>

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: commit message titles and changelog entries

[Jan Mulder]

On 02-02-18 22:59, Lubomir I. Ivanov wrote:

hello,

1)

this suggestion is triggered by the need for streamlining the addition
of changelog entries by contributors in the CHANGELOG.md file.

right now, we merge PRs that make an important change, but such PRs do
not append a change in the CHANGELOG.md file. adding notes in
CHANGELOG.md has to be made a requirement in PRs, otherwise before a
release one has to go over the usually big list of commits and find
relevant missing entries.


Historically, we have pretty concise changelogs, more or less hand made, 
and relatively high level. Like "Numerous spelling errors", "Lots of 
small UI fixes". Obviously, this does tell only a part of the story, and 
possible relevant change can be forgotten in this process. So this does 
not seem the way to go.


However, the big question is here: for who do we write the changelog? 
When it is for the website and announcements on internet, I tend to 
prefer the short and concise high level like we had, instead of a long 
list that seems correct and detailed enough (for who?).


For example: in the PR 1091 one item is "Cloud-storage: support 
non-https:// repositories for saving" ... yes I know where this is 
coming from ... but the general public?




by doing that we also need a standardized CHANGELOG.md entry format.

my suggestion is the following:
 - Area: change that was made (#github-link)

examples:
- Planner: fixed a bug when moving data points (#32132)
- Mobile: fixed a bug when clicking button X. The bug also affected
   menu X (#32132)

notes about the format:
- the area name is uppercase
- lowecase after the "Area: ", should it be uppercase here?
- no period at the end of an entry only in-between sentences
- when there is a related issue a (#github-link) has to be added at the end
- first line stats with "- " and no indentation. the next lines are
indented by "  ".

example areas:
- Planner
- Mobile
- Desktop
- Bluetooth
- Map-widget
- Cloud-storage
- Uemis
- Import
- Export
- Profile
- Libdivecomputer

opinions about this?


Nice, but a little too detailed to my liking. Are you thinking of some 
automation/tooling behind it to check for these rules?




2)

for commit messages-  until now we have accepted commit messages that
do not specify an area, like these:
Fix bug when clicking button X
Small whitespace fix


Fine for me. When I want to look at a commit, I do not only read the 
title, but also the rest of the text and even the code change if needed.


In practice, it is often difficult to exactly pinpoint the area (and 
being concise). For example (from the PR 1091), "Bluetooth: do not add 
duplicate BT/BLE items", this mobile only, and it is even not 
(technically) restricted to Bluetooth. And the originating commit says 
"connectionList" and the related issue #1069 even says "mobile: During 
DC import, Rescan duplicates connections".




these are kind of vague, thus i would suggest requiring (perhaps not
strictly) an area prefix or a filename, like so:
Divelist: Fix bug when clicking button X
divelist.cpp: fix whitespace

any opinions about this too?


In general: ok. But I come back to my earlier remark: for who do we 
write the changelog?


--jan
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface