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 away from the comment that describes it (so
>>>> the comment ends up being next to something else).
>
> Definitely a bug.
>
Ok
>
> IMHO we should consider two things:
>
> 1. File bug to not mess up comments
+1
> 2. File wishlist bug "please provide options for different style"
Or maybe the "fix" command should only fix actual problems and not make
unnecessary rearrangements and spacing changes. Maybe there could be a
command like `cme rewrite` to do what "fix" currently does.
>
> If this might solve your issues about the usage of cme in team uploads
> I'd be happy.
With my change to your second point, I think it would.
> 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.
>
-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.
Many thanks and regards
Afif
--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
Reply to: