Re: cme and stylistic changes in team uploads
Hi all, in my case, I use cme like syntax highlighting: to have a consistent visual pattern so that it is easier to spot that something changed in a wrong way. Thus, for a team upload, I think that it is important to not change the visual pattern to which the lead maintainers are used to. Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
Re: cme and stylistic changes in team uploads
On الإثنين 26 كانون الأول 2016 06:50, Ghislain Vaillant wrote: On 25/12/16 23:51, Afif Elghraoui wrote: I think it's enough consistency that people are either using dh_make, debmake, or the debian-med packaging template and just adding to that. If people were writing these packaging files from scratch, there would be real consistency issues. Come on, I am sure most people just copy an existing debianization that is close enough to the package they intend to work on, despite our best efforts to advise against doing so. Either way, it's not written from scratch. This is beside the point anyway and I think there's been too much digression. [...] I'd definitely not request the cme style while I'm recommending it to newcommers for the said reasons. I'm usually doing it in team uploads since up to now nobody expressed that its not wanted. I'd not use it for instance on packages where you are Uploader and I know that you do not like it. Place yourself as a newcomer for a minute. You were advised to use cme because whatever changes you make, you are guaranteed a well-formed d/control or d/copyright, or else the software will scream at you. You are now happy with your contribution and get it uploaded, only to be publicly shamed on the team's mailing list for not respecting the main uploader's custom style. Now let me ask you this, does this sound like a great packaging experience to you? I agree with you 100% that it isn't and also made exactly the same point in my previous message that you are making now. Please see the last part of my previous message (not snipped from this reply). [...] I agree that can be helpful, but to me it's outweighed by the problems I have with it. The problem here is you putting comments in d/control to categorize dependencies. This is highly non-standard. If you really want to do such thing, then you should be using build profiles [1] which would bring additional benefits. [1] https://wiki.debian.org/BuildProfileSpec Otherwise, your comments in d/control are just plain noise, I am afraid. As I said, I'm not going to dispute particular points of style here. This is a digression. I only named a couple of my problems with it here to avoid derailing this thread. I think the specific issues are better discussed with the cme developers. [...] I never observed this. Could you please give an example? That could also be a topic for a bug report. This is really not a big deal, but I was referring to something like: [...] where in the latter case, both lists are aligned. Again, not a very big deal. Not a very big deal indeed! I didn't want to go deep into details, but I merely provided an answer to a question I was asked. [...] -1. I think that requiring everyone to have to remember everyone else's quirks will create huge barriers to teamwork over time, with the brunt of the problems coming to newcomers who have enough to learn aside from getting inside everyone's head. I'd like to agree with everyone on a standard procedure. We should all just "take one for the team" and stop this madness of imposing one's style over a consistent one. I would say "preserving" rather than "imposing", but sure. I'm sure you would agree, though, that if I'm just making a team upload to fix a problem in one of your packages, it wouldn't be a good idea for me to also go through and change all your variable assignments from "A = B" to "A=B" or vice versa or whatever. I'm trying to make exactly this point. It's just that in this case, cme fixes problems while also changing style. Because it's not the packager actively changing these things as it is in my example with d/rules, it's clear that my issues should have been taken up with the cme people and not here. Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: cme and stylistic changes in team uploads
On 25/12/16 23:51, Afif Elghraoui wrote: I think it's enough consistency that people are either using dh_make, debmake, or the debian-med packaging template and just adding to that. If people were writing these packaging files from scratch, there would be real consistency issues. Come on, I am sure most people just copy an existing debianization that is close enough to the package they intend to work on, despite our best efforts to advise against doing so. I don't impose this on anyone--I would not force people requesting sponsorship to use it, nor would I change it while making a team upload. I'd definitely not request the cme style while I'm recommending it to newcommers for the said reasons. I'm usually doing it in team uploads since up to now nobody expressed that its not wanted. I'd not use it for instance on packages where you are Uploader and I know that you do not like it. Place yourself as a newcomer for a minute. You were advised to use cme because whatever changes you make, you are guaranteed a well-formed d/control or d/copyright, or else the software will scream at you. You are now happy with your contribution and get it uploaded, only to be publicly shamed on the team's mailing list for not respecting the main uploader's custom style. Now let me ask you this, does this sound like a great packaging experience to you? cme introduces some consistency in the formatting that is definitely welcome. Its not *only* the formatting its also a defined sequence of fields which I consider a helpful standard. It also helps you flag things like non-secure VCS URIs and out-of-date standards fairly easily. Its not just flagging it - its fixing it and by doing so it saves time. That is what I meant, I should have been more explicit. It saves valuable time **not** spent on ensuring the consistency of the Debian files being worked on. Now, if I have to second-check everything cme does, then the original purpose of the software is defeated. Flagging is what lintian does. Yes, lintian is *only* flagging and I need to rebuild the package after manual work. Cme does things in advance and saves me another build which is very convenient. I agree that can be helpful, but to me it's outweighed by the problems I have with it. The problem here is you putting comments in d/control to categorize dependencies. This is highly non-standard. If you really want to do such thing, then you should be using build profiles [1] which would bring additional benefits. [1] https://wiki.debian.org/BuildProfileSpec Otherwise, your comments in d/control are just plain noise, I am afraid. While cme also makes those changes for you, it removes trailing commas from listings (making for noisier diffs) I admit I was considering a bug report against cme about this but somehow never took the time. In the past I learned that cme authors are quite sensible and if you have good reasons are responsive about this. I understand why they would want to classify this as WONTFIX. Supporting many exotic formating practices is a pain. So if this really concerns you I'd try a bug report if I would be in your shoes. and misaligns all itemized lists. I never observed this. Could you please give an example? That could also be a topic for a bug report. This is really not a big deal, but I was referring to something like: Build-Depends: A, B, C ... Depends: D, E, versus Build-Depends: A, B, C ... Depends: D, E where in the latter case, both lists are aligned. Again, not a very big deal. Not a very big deal indeed! I'm not trying to convince anyone because I'm not really interested in disputing style; all I'm saying is that if someone wants to make a team upload, I don't think that making stylistic changes should be part of it. It depends. If I know that the team member does not like it I agree. He made himself clear, that is for sure. However, in the past I touched so many packages of team members who in the beginning were not aware about cme and its features and who were happy about the change or team members who somehow stopped caring for the package in question or left the team at all that the overall style consistence became a feature of the Debian Med packages which I do not want to miss today. That's the reason we have even put ... simply call cme fix dpkg-control to get a properly formated, sanity checked debian/control file. in our team policy[1]. I had the same experience, even for contributions outside d-science and d-med. Although in the case of someone leaving the team or stopping work on a package, presumably someone else has joined the uploaders list, in which case subsequent changes are no longer Team uploads. My suggestion was only to not change style as part of Team uploads. That being said, like any other tools, it should not be used blindly and whoever messed with your
Re: cme and stylistic changes in team uploads
Hello, على السبت 24 كانون الأول 2016 22:51، كتب Andreas Tille: > Hi, > > On Sat, Dec 24, 2016 at 10:00:07PM -0800, Afif Elghraoui wrote: >>> On 24/12/16 15:41, Afif Elghraoui wrote: I'm admittedly no fan of cme's styling. While I have my own style that I prefer to use in d/control, > > I admit before I started cme I had a different style as well. I decided > that the advantages cme had regarding content are way superior over > keeping my own style. Moreover I consider it a feature to have a common > style inside a team. > There is another "styling" tool with different > formating style (I always forget its name since I'm not using it). I think you mean devscripts' `wrap-and-sort`. > I > know that style is something (like color of web pages, names of > projects) people can be quite opinionated about. I personally try to > save my own time and adapt to something that could be potentionally a > common agreement since I'm convinced that some common style has some > value. Its not really necessary but helps others to step in. I think it's enough consistency that people are either using dh_make, debmake, or the debian-med packaging template and just adding to that. If people were writing these packaging files from scratch, there would be real consistency issues. > I don't impose this on anyone--I would not force people requesting sponsorship to use it, nor would I change it while making a team upload. > > I'd definitely not request the cme style while I'm recommending it to > newcommers for the said reasons. I'm usually doing it in team uploads > since up to now nobody expressed that its not wanted. I'd not use it > for instance on packages where you are Uploader and I know that you do > not like it. > >>> cme introduces some consistency in the formatting that is definitely >>> welcome. > > Its not *only* the formatting its also a defined sequence of fields > which I consider a helpful standard. > >>> It also helps you flag things like non-secure VCS URIs and >>> out-of-date standards fairly easily. > > Its not just flagging it - its fixing it and by doing so it saves > time. > >> Flagging is what lintian does. > > Yes, lintian is *only* flagging and I need to rebuild the package > after manual work. Cme does things in advance and saves me another > build which is very convenient. I agree that can be helpful, but to me it's outweighed by the problems I have with it. > >> While cme also makes those changes for >> you, it removes trailing commas from listings (making for noisier diffs) > > I admit I was considering a bug report against cme about this but > somehow never took the time. In the past I learned that cme authors are > quite sensible and if you have good reasons are responsive about this. > So if this really concerns you I'd try a bug report if I would be in > your shoes. > >> and misaligns all itemized lists. > > I never observed this. Could you please give an example? That could > also be a topic for a bug report. This is really not a big deal, but I was referring to something like: Build-Depends: A, B, C ... Depends: D, E, versus Build-Depends: A, B, C ... Depends: D, E where in the latter case, both lists are aligned. Again, not a very big deal. > >> I'm not trying to convince anyone because I'm not really interested in >> disputing style; all I'm saying is that if someone wants to make a team >> upload, I don't think that making stylistic changes should be part of it. > > It depends. If I know that the team member does not like it I agree. > However, in the past I touched so many packages of team members who in > the beginning were not aware about cme and its features and who were > happy about the change or team members who somehow stopped caring for > the package in question or left the team at all that the overall style > consistence became a feature of the Debian Med packages which I do not > want to miss today. That's the reason we have even put > >... simply call > >cme fix dpkg-control > >to get a properly formated, sanity checked debian/control file. > > in our team policy[1]. > Although in the case of someone leaving the team or stopping work on a package, presumably someone else has joined the uploaders list, in which case subsequent changes are no longer Team uploads. My suggestion was only to not change style as part of Team uploads. >>> That being said, like any other tools, it should not be used blindly and >>> whoever messed with your comment should have inspected the diff before. > > I confirm that messing up comments is a bug (which I also was to lazy to > report - which I always regret if I touch a package with comments in > d/control). > Is there a reason to apply cme systematically to packages as part of any upload? Besides my dislike for what it does to the file, it has in one case moved a Depends line
Re: cme and stylistic changes in team uploads
Hi, On Sat, Dec 24, 2016 at 10:00:07PM -0800, Afif Elghraoui wrote: > > On 24/12/16 15:41, Afif Elghraoui wrote: > >> I'm admittedly no fan of cme's styling. While I have my own style that I > >> prefer to use in d/control, I admit before I started cme I had a different style as well. I decided that the advantages cme had regarding content are way superior over keeping my own style. Moreover I consider it a feature to have a common style inside a team. There is another "styling" tool with different formating style (I always forget its name since I'm not using it). I know that style is something (like color of web pages, names of projects) people can be quite opinionated about. I personally try to save my own time and adapt to something that could be potentionally a common agreement since I'm convinced that some common style has some value. Its not really necessary but helps others to step in. > >> I don't impose this on anyone--I would not > >> force people requesting sponsorship to use it, nor would I change it > >> while making a team upload. I'd definitely not request the cme style while I'm recommending it to newcommers for the said reasons. I'm usually doing it in team uploads since up to now nobody expressed that its not wanted. I'd not use it for instance on packages where you are Uploader and I know that you do not like it. > > cme introduces some consistency in the formatting that is definitely > > welcome. Its not *only* the formatting its also a defined sequence of fields which I consider a helpful standard. > > It also helps you flag things like non-secure VCS URIs and > > out-of-date standards fairly easily. Its not just flagging it - its fixing it and by doing so it saves time. > Flagging is what lintian does. Yes, lintian is *only* flagging and I need to rebuild the package after manual work. Cme does things in advance and saves me another build which is very convenient. > While cme also makes those changes for > you, it removes trailing commas from listings (making for noisier diffs) I admit I was considering a bug report against cme about this but somehow never took the time. In the past I learned that cme authors are quite sensible and if you have good reasons are responsive about this. So if this really concerns you I'd try a bug report if I would be in your shoes. > and misaligns all itemized lists. I never observed this. Could you please give an example? That could also be a topic for a bug report. > I'm not trying to convince anyone because I'm not really interested in > disputing style; all I'm saying is that if someone wants to make a team > upload, I don't think that making stylistic changes should be part of it. It depends. If I know that the team member does not like it I agree. However, in the past I touched so many packages of team members who in the beginning were not aware about cme and its features and who were happy about the change or team members who somehow stopped caring for the package in question or left the team at all that the overall style consistence became a feature of the Debian Med packages which I do not want to miss today. That's the reason we have even put ... simply call cme fix dpkg-control to get a properly formated, sanity checked debian/control file. in our team policy[1]. > > That being said, like any other tools, it should not be used blindly and > > whoever messed with your comment should have inspected the diff before. I confirm that messing up comments is a bug (which I also was to lazy to report - which I always regret if I touch a package with comments in d/control). > >> Is there a reason to apply cme systematically to packages as part of any > >> upload? Besides my dislike for what it does to the file, it has in one > >> case moved a Depends line away from the comment that describes it (so > >> the comment ends up being next to something else). Definitely a bug. > > Comments in d/control, what is this practice? Why do we have > > README.Debian and README.source then? > > I mostly do it to set aside build-dependencies that are needed for tests > and perhaps a few other things that are not really appropriate in README.*. +1 IMHO we should consider two things: 1. File bug to not mess up comments 2. File wishlist bug "please provide options for different style" If this might solve your issues about the usage of cme in team uploads I'd be happy. If not we should probably find a way to ensure not to mess up individual team members preferences which I would respect if explicitly expressed in contrast to the recommendations in our policy. Kind regards Andreas. [1] https://debian-med.alioth.debian.org/docs/policy.html#debian-control -- http://fam-tille.de
Re: cme and stylistic changes in team uploads
Hi, Ghislain, على السبت 24 كانون الأول 2016 08:12، كتب Ghislain Vaillant: > On 24/12/16 15:41, Afif Elghraoui wrote: >> Hi, all, >> >> I'm admittedly no fan of cme's styling. While I have my own style that I >> prefer to use in d/control, I don't impose this on anyone--I would not >> force people requesting sponsorship to use it, nor would I change it >> while making a team upload. > > cme introduces some consistency in the formatting that is definitely > welcome. It also helps you flag things like non-secure VCS URIs and > out-of-date standards fairly easily. > Flagging is what lintian does. While cme also makes those changes for you, it removes trailing commas from listings (making for noisier diffs) and misaligns all itemized lists. I'm not trying to convince anyone because I'm not really interested in disputing style; all I'm saying is that if someone wants to make a team upload, I don't think that making stylistic changes should be part of it. > That being said, like any other tools, it should not be used blindly and > whoever messed with your comment should have inspected the diff before. > > That being said? > >> Is there a reason to apply cme systematically to packages as part of any >> upload? Besides my dislike for what it does to the file, it has in one >> case moved a Depends line away from the comment that describes it (so >> the comment ends up being next to something else). > > Comments in d/control, what is this practice? Why do we have > README.Debian and README.source then? > I mostly do it to set aside build-dependencies that are needed for tests and perhaps a few other things that are not really appropriate in README.*. regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
