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
Reply to: