F21 System Wide Change: Headless Java

Stanislav Ochotnicky sochotnicky at redhat.com
Thu Nov 21 13:38:47 UTC 2013


Quoting Miloslav Trma─Ź (2013-11-21 13:48:51)
> On Thu, Nov 21, 2013 at 1:31 PM, Aleksandar Kurtakov
> <akurtako at redhat.com> wrote:
> > I agree with you that the current Features/Changes system is useless as is now. It was supposed to be a way to collect information for Release notes nothing more AFAIK.
> 
> From the FESCo side, IMHO "collecting information for Release Notes"
> was fairly useless; the current system allows every affected
> maintainer to be aware of changes and raise concerns, and this has led
> several times to significantly altering the proposal for the better.
> 
> > Discussions, decisions, changes and so on happen in whatever way the parties doing the work think is better for them.
> 
> The "parties doing the work" proposed to:
> > (optional) Mass-change spec files that have "Requires: java" to "Requires: java-headless"
> I.e. mass-break non-headless packages, and to ask "Other developers"
> to clean up after the Change owners breaking their packages.  That's
> may actually be the right thing to do (I'm uncertain), but at the very
> least the affected maintainers should have an opportunity to speak up
> whether they are willing to do it or not, and that's the reason the
> Change process is imposing a public discussion.
> 
> In the thread you and others have suggested that there in fact there
> are no or few "Other developers", and this is all a Java SIG internal
> thing; I don't know whether it's true (and I don't currently care to
> collect the data); the proposal certainly hasn't been written that
> way.

From my perspective as Change owner, I proposed it for two reasons:
    * Release notes and just wider audience for the change (as Alex mentioned)
    * Get feedback on *serious* problems with the proposal

I agree that *affected maintainers* should have an opportunity to speak up.
Based on their input in the thread I believe noone objected to mass filing bug,
waiting a bit for maintainers to either look themselves or fix it up
automatically.  *That* kind of input was constructive and helped flesh out the
process for rolling out the change for users/maintainers. 


-- 
Stanislav Ochotnicky <sochotnicky at redhat.com>
Software Engineer - Developer Experience

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com


More information about the devel mailing list