On 07/25/2012 09:42 PM, Bill Nottingham wrote:
"Jóhann B. Guðmundsson" (johannbg@xxxxxxxxx) said:
Standardization on the changes so it can be documented in the guidlines
so people know what to do in their unit file. (such as around
Documentation=, what fields are no longer necessary, etc.)
That's just laughable since afaik systemd would be the only program
that is forced to go through these change and get the approvals from
FPC while others simply get away with mentioning changes in upstream
documentation.
I don't see this sort of bias that you're implying here. Init script
packaging changes went through FPC. Desktop file packaging goes through FPC.
Ruby gems packaging changes go through FPC. Why wouldn't something
like systemd services that also affects a few hundred packages? Yes,
systemd does have a bit higher bar on things than, say, alienblaster,
but that's because it's much more important to the overall system.
You guys ( FESCO ) seem to have easily dismiss that fact when you
accepted the preset feature or when accepting systemd.
If you guys FESCO had wanted documentation how to construct units you
guys would have asked for one when you guys accepted systemd as the new
init system then most certainly this argument would make sense. .
If the migration process was not needed to be handled on per initscript
bases I would have written one long time ago.
I thought you guys meant the removal of the environment files that
resides in /etc/sysconfig/ directory and that was why the feature
was being rejected and mentioning that upstream needed some kind of
upstream patching was just utter and total bullshit since putting
environment files in /etc/sysconfig/$file is Fedora/RHEL specific
and is the reason why upstream has been rejected our units when they
have been submitted upstream...
This was also a concern of FESCo, yes - having a clear migration path
for users and administrators, rather than dropping them all and picking up
the pieces.
Again ye had no problem accepting the preset feature....
Additionally, there was a minor concern about if there are
going to be more cleanups that pop up each release, as some of the
cleanups (documentation is the obvious one) didn't exist when the units
were first written. These sorts of changes are the sort of thing that
are great for standardizing in conjunction with FPC guidelines, so others
can see how to do it and evangelize the work upstream and possibly even
help. Teaching to fish instead of giving fish, more or less.
I will be doing the cleanup process one time. After that my systemd
involvement will be more or less concluded and I will be returning to QA
and continue the work I was doing there and had been doing there for
several release cycles before I was asked to handle the migration.
Really, that's all that needs done here - get a standard for what a
cleaned up unit should look like, what it should include, etc., and
get that through FPC. Essentially, a list of what should be changed
in:
https://fedoraproject.org/wiki/Packaging:Systemd
It's not like the feature was rejected out of hand; it was just
redirected.
?
There is nothing on that page that is mentioned on that page that would
get affected by the cleanup process thus nothing is subjected to be
changed there.
Then you guys started to act like kids in candy store and cherry
pick stuff from the feature requests well here's a news flash that
wont work with me. When I submit features I will submit them as is,
work on them as is and finish them myself as is
While I commend your desire on doing the work on features you submit
yourself, Fedora *IS* a community project; it's about collaboration,
not a collection of individuals all going in different directions.
We do have policies and procedures in Fedora for a reason. You may not
like them. Heck, I don't like them some of the time either. And some of
them can use fixing - we have ongoing work on fixing the feature process
as we speak.
Yes I saw that effort which still does not seem to make a room for
features that span over several release cycles.
However, when you say you'll only do the features your way, yourself,
and aren't willing to accept alternatives, or work with the community's
elected representatives on this (that's how your statements read to me),
And my work proves otherwise...
it seems to the outside world like you don't share the same set of values
there. If that's the case,
I personally would choose fewer better maintained components in the
distribution then many poorly maintained or not maintained at all and
personally I want feature to be actually 100% done instead of just be
claimed to be done thus if the "outside world" wants and accepts half
implemented things in the release then sure we do not share the same
value. Heck when we in QA miss a serious bug that affects large user
base I take that as a personal failure on my behalf as crazy as that is,
in the end that's just how I am.
JBG
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
