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

["Jóhann B. Guðmundsson"]

On 07/25/2012 09:42 PM, Bill Nottingham wrote:
> "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.

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