David Chandek-Stark: Realit=
y of Fedora turned out to be different from the assumptions of Fedora
Andrew Woods: Expectations of behavior ha=
ve not been formalized, but there is a 90-something % overlap in expectatio=
ns of what Fedora does
A. Soroka: the=
re is a difference b/t creating a policy (what Andrew Woods is suggesting) and fixing a bug (what David Chandek-Stark wants), and bugs can =
be fixed w/o a policy. Holding David Chandek-Stark's need to the standard of this policy may result i=
n much unhappiness; instead, in the absence of a policy, if the bug gets fi=
xed, this may be sufficient
David Chandek-Stark: in the=
absence of a spec, I assume as a user that if the REST API says "X", Fedor=
a will do "X". If that's not true, that would concern me
A. Soroka: yes=
, the API can change, and until a spec is formalized, there is no standard =
for deciding when that API should or should not change; there have been cas=
es when the documentation was wrong and there have been cases when the code=
was wrong and it could be a misunderstanding of the documentation.
David Chandek-Stark: I woul=
d expect the rest API would change; what is the management of that change o=
ver time?
A. Soroka: Tha=
t is correct, change management is unclear; it is currently acted on in a c=
ase-by-case basis; the Spec should have a change management process built i=
n.
Andrew Woods: IF we had the spec and TCK,=
how would we approach a support policy? acknowledging that we have limited=
developer resources. What would be the appropriate policy.
A. Soroka if t=
here is agreement of the spec, this would go to the implementation team. Th=
e spec change management should be different than the ref impl.
A. Soroka:&nbs=
p;Andrew Woods is asking for guarantees, an=
d if developer time is from single individuals and institutions, supporting=
maintenance branches relates to real time commitments
Andrew Woods: for example, in the change =
from MODE 4 -> 5, there is still a hurdle migrating from one backend to =
the other, this supports a higher need to support bug fixes in the earlier =
version.
A. Soroka: thi=
s should be part of the semantic versioning scheme
Andrew Woods: Example where the underlyin=
g backend is undergoing a major change, but the Fedora API isn't changing; =
all the versions now are tied to 4.x.x, which doesn't work well with semant=
ic versioning.
4.6.0 Release is ready for code freeze (next week). 4.7.0 will be relea=
sed soon thereafter.=20
4.6.0 will be a (informal) LTS; tooling will need to be put into place =
for migrating MODE 4 -> 5
Elliot Metsger: why the rush to move to MODE 5? =
Does MODE provide tooling to move from 4 -> 5?
Andrew Woods: MODE does provide support f=
or migration ( /fcr:backup and /fcr:restore); Esm=C3=A9 Cowles has tested backup and =
restore, though with some glitches; We don't want to tie people to particul=
ar back ends, but this is useful for migrations
Nick Ruest: if we're putting out two rele=
ase candidates, what are we committing ourselves to in terms of supporting =
two releases?
Andrew Woods: this would be two supported=
versions
Elliot Metsger: two simultaneous releases would =
be confusing; if there was more clarity about Modeshape 4 -> 5 and previ=
ous version support
Unknown User (acoburn): if there are no=
t two simultaneous releases, I could build my own MODE5-backed Fedora for o=
ur immediate institutional needs
Andrew Woods: we can move forward now wit=
h a 4.6.0 release; a 4.7.0 will happen at some future time
What is the support strategy for mode 4.6.0?
A. Soroka: imp=
ort/export tooling is the answer to that
Andrew Woods: back-porting bugs would be =
applied on a case-by-case basis, as discussed earlier in the meeting
A. Soroka: not=
sure about the degree to which we can guarantee back-porting bugs; there m=
ay be situations where we do back-port, but we should be clear that we may =
not back-port bugs to earlier released versions. This gives us a powerful i=
ncentive to bring the Spec process to a resolution.