On 09/08/2017 11:14 AM, James Hogarth wrote:
On 8 September 2017 at 16:04, Randy Barlow
<bowlofeggs@xxxxxxxxxxxxxxxxx <mailto:bowlofeggs@xxxxxxxxxxxxxxxxx>>
wrote:
On 09/08/2017 10:51 AM, Tom Hughes wrote:
> Surely (c) would make a mockery of change system. What would not
make a
> mockery of the change system would be to invoke the contingency
plan.
>
> Except there doesn't seem to be one:
>
>
https://fedoraproject.org/wiki/Changes/Modular_Server#Contingency_Plan
<https://fedoraproject.org/wiki/Changes/Modular_Server#Contingency_Plan>
There is actually a contingency plan, it is just in a different change.
The change process/template did map very well to what we are trying to
do so there are a few changes that all go together.
https://fedoraproject.org/wiki/Changes/ModularRelease#Contingency_Plan
You kind of need to look at:
* https://fedoraproject.org/wiki/Changes/Modular_Server
* https://fedoraproject.org/wiki/Changes/Host_and_Platform
* https://fedoraproject.org/wiki/Changes/ModularRelease
as all connected. Apologies for any confusion.
Basically, the contingency plan is to just not ship the modular server
version, or do it on the side similar to boltron. Right now, we are
building a traditional version of server every time there is a normal
compose. We actually have to make a change(s) to make the contingency
plan not the actual plan.
I suggest option (b), delaying modularity until Fedora 28, though I
agree that it's problematic that there doesn't seem to be a
contingency
plan defined here.
Speaking from Bodhi's perspective, I think we should have had modular
functionality in Bodhi before the beta freeze. Technically there
is also
a Bodhi change request to add non-RPM artifacts (modules) that is also
not done. It makes me nervous to make such a large change in Bodhi so
close to the final freeze.
Delaying the modular server release until F28 will give us time to
work
out bugs in Bodhi and other tooling and help us to release a more
solid
server product to our users.
+1 to that
It doesn't exist as a product our users depend on yet ... so there's
no "loss" or issues to the current userbase.
Rushing things almost always causes unforeseen issues that then crop
and require further hack/hot fixes and scrambling ...
If we delay the whole F27 for this product that they aren't relying on
... what happens if there's further issues? This then leads to a
direct impact on F28 and any other work for that.
The only really sensible thing that lines up with process and
minimises disruption on our users and other bits and pieces is to just
postpone that one feature to F28 ... particularly in light of the
boshi dependencies still not in place Randy mentioned.
This is going to be a new way of handling servers and services within
Fedora ... let's not launch it without significance confidence and
testing as a bad launch will leave a bad taste in people's mouth in
the future and be more hurtful to the project than a delay of that
feature for a more well tested solution early next year with F28.
I really want to keep working to an F27 goal and we will discuss this
with Fesco at the meeting today. The modular server, while having some
of its own issues has also been effected by the changes that delayed the
traditional F27 builds. As a result, we have been delayed as well.
That said, I agree, we would like it to be a "good release." I just
don't think we need to pull the plug yet as we have a solid fall back
plan.
From mattdm:
Also note that the release blocking images list for F27 does not yet
even exist, let alone has it been updated for this Change:
https://fedoraproject.org/wiki/Releases/26/ReleaseBlocking (F26 page)
https://fedoraproject.org/wiki/Releases/27/ReleaseBlocking (Doesn't
exist)
</mattdm>
^^ I am not sure how this is related to modular server at all as it is a
normal part of the traditional distribution process and not provided by
the modularity wg.
Langdon
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
