propozition of specs cleanups

[Tomasz Kłoczko]

Dnia 03-02-2006, pią o godzinie 17:54 +0530, Rahul Sundaram napisał(a):
[..]
> >Good to know you focus on my expression (not on sense chages).
> >  
> >
> The expression is as atleast as important as the changes being proposed. 
> There is no point in being rude unnecessarily. It certainly cant 
> motivate the developers to get involved to do the changes.

Sorry but my rude expression it is reaction on submiting many separated
BR via bugzilla for *very* small changes in many packages.
There is no leader in fedora development team or someone other hwo watch
on all traffic in CVS or other persons who can commit some mainly
stylistics changes ? If no .. look on current form od FC spec files. So
many styles as many developers. This it makes much more harder for any
developers .. this is like idendenting .c files.

Few years ago I itroduce using common specs style in PLD. This was done
by very simple awk script (if anyone don't know why it have so common
form).
Transform specs files to some common form allow catch many bugs in
specs. For example many FC specs do not have "rm -rf $RPM_BUILD_ROOT" on
top %install breaks --short-circuit %install only build.
Next: many specs files produces main package and devel. For prevent some
hazard dependencies best will be add in devel "Requires: %{name} =
%{version}-%{release}" or even "Requires: %{name} =
%{epoch}:{version}-%{release}" if package have Epoch.

If you want more I have *very long* list of this kind things. but IMO
best will be introduce all this one by one for aprove and inform in best
possible way all developers about some common rules on maintainig specs.

Do you see now most of this kind changes can be performed by single
perl/sed regexp ? if yes .. ask: why the hell for change N single line
cleanups in N spec files must be involved N developers ? this single
change and require single developer who can commit this with aprove all
other developers.

IMO best way for introduce this kind changes will be make propozition of
this kind changes (one by one or in small groups) for discuss -> after
pass few days for discuss and without protests -> performe single commit
by someon who have permission for this kind stylistics/cosmetics changes
for making this like "shoot and forget" without absorbe each developer
for making each single line/small adjustment.

Ones more: I'm not talking about bugs or critical bugs. I'm talking
about prepare some kind of "common spec coding style".
If introducing this kind chanes will be possible only via bugzilla for
each package this will create unnormal amout of traffic in bugzill wich
can stop many people for many days or weeks. Do you see this now ?

> >If you want my time for spending on bugzilla -> please pay me for this
> >(sorry) or show me how can I introduce in time frame comparable to time
> >spend on thinking on sed line 
> >  
> >
> It probably can be done within the buildsystem to enforce such things. 
> Meanwhile if you dont want to voluntarily spend the time involved in 
> reporting this changes to the individual developers through bugzilla 
> feel free to drop it but several people have done similar things before.

Hanging this in build system is bad point.
This will be like indenting .c files on compile stage.

kloczek