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: December
Hi everybody, advent is over and the calender[1] has been filled with lots of entries. All in all 95 bugs have been closed, that is the second highest number after the all time record of 150 last year. So congratulations to all participants for a great job! Though some new bugs appeared during that bug squashing, because new versions of packages FTBFS, the starting count of 150 bugs could be reduced to 134. The number of serious bugs could be reduced from 9 to 6. So, get some rest now for the next calendar in 2017 :-). I wish everybody a Happy New Year! Thorsten [1]http://debian-med.alteholz.de/advent
biojava4-live build update issue
hi Andreas, I had a look at your build issues after switching to git and new code is based on a more recent jmol version (14.6.2) than before. Previous was on 1.3.0.14. Fortunatly debian jmol release is 14.6.4. so jmol needs to be udpated to latest and d/control must require jmol >= 14.6.4. I updated d/control New dependency libvecmath-java was also required, added to d/control and d/build.xml Now build looks fine, should I go to upload and did you want to do something else ? Olivier
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
