Summary/Minutes from today's FESCo Meeting (2012-07-23)

Bill Nottingham notting at redhat.com
Wed Jul 25 21:42:01 UTC 2012


"Jóhann B. Guðmundsson" (johannbg at gmail.com) 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.

> 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. 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.

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.

> 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.

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),
it seems to the outside world like you don't share the same set of values
there. If that's the case, it *is* going to cause repeated friction, and
make make it harder for you to effectively and/or happily contribute.

Bill


More information about the devel mailing list