[#proposal] Rules for adding patches to legacy
23 views
Skip to first unread message
Lars Kiesow
Oct 8, 2024, 8:46:07 AM10/8/24
to d...@opencast.org
Hi everyone,
at the DACH meeting we had a longer discussion about making updates
easier where we concluded that no participant is trusting Opencast to
not break stuff. Even with a minor update.
Discussing how we could maybe improve the situation we came up with two
suggested changes to the development process. Both are specifically
adressing patches to the legacy branch (the second newest release
branch; r/15.x right now):
- We strongly recommend to not add new features to the legacy branch.
Even bug fixes should only be added if the bugs pose a significant
problem to the overall community.
- If a developer wants to add a patch to the legacy branch, the patch
(pull request) must come with an explanation why it needs to be
merged in legacy and cannot just go into stable or develop.
This means that the rules for stable do not change and developers and
adopters still have about 7 month before the rules apply to a given
release branch. We hope that the most important bugs are found until
then.
It also means that developers still can add the same patches they can
add now. But they need to actually think about why they need to go into
legacy and about what risks are involved.
We hope this helps making at least the legacy version of Opencast more
stable, which in turn makes updates between minor versions easier.
If no one objects, this proposal will pass on
Fri Oct 11 02:42 PM CEST 2024
All the best,
Lars
at the DACH meeting we had a longer discussion about making updates
easier where we concluded that no participant is trusting Opencast to
not break stuff. Even with a minor update.
Discussing how we could maybe improve the situation we came up with two
suggested changes to the development process. Both are specifically
adressing patches to the legacy branch (the second newest release
branch; r/15.x right now):
- We strongly recommend to not add new features to the legacy branch.
Even bug fixes should only be added if the bugs pose a significant
problem to the overall community.
- If a developer wants to add a patch to the legacy branch, the patch
(pull request) must come with an explanation why it needs to be
merged in legacy and cannot just go into stable or develop.
This means that the rules for stable do not change and developers and
adopters still have about 7 month before the rules apply to a given
release branch. We hope that the most important bugs are found until
then.
It also means that developers still can add the same patches they can
add now. But they need to actually think about why they need to go into
legacy and about what risks are involved.
We hope this helps making at least the legacy version of Opencast more
stable, which in turn makes updates between minor versions easier.
If no one objects, this proposal will pass on
Fri Oct 11 02:42 PM CEST 2024
All the best,
Lars
Greg Logan
Oct 8, 2024, 9:37:30 AM10/8/24
to d...@opencast.org
I worry that this will effectively just promote legacy to stable, stable to develop, and develop to... bleed, but it's addressing an issue affecting adoption and (imo) it'll be easier to handle as a developer anyway.
+1
G
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencast.org.
Matthias Neugebauer
Oct 8, 2024, 9:49:05 AM10/8/24
to d...@opencast.org
Christoph Reifers
Oct 9, 2024, 1:57:32 AM10/9/24
to d...@opencast.org
Hi,
also big +1 from my side even though im not a dev ;)
Regarding the comment from Greg: This is exactly the issue at the moment. Just consider what kind of issues appeared in the first releases of 16.x. IMHO that did not deserve the label "stable". This probably also means that we as a community must come up with better QA processes but that's another topic.
- Christoph
Lars Kiesow
Oct 11, 2024, 5:38:34 PM10/11/24
to d...@opencast.org
I'm happy to see that this proposal passed. I'm going to submit a pull
request that adds this to the pull request template.
–Lars
> > <mailto:dev%2Bunsu...@opencast.org>.
request that adds this to the pull request template.
–Lars
> >
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to dev+uns...@opencast.org.
>
> To unsubscribe from this group and stop receiving emails from it,
> send an email to dev+uns...@opencast.org.
--
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to dev+uns...@opencast.org.
>
> To unsubscribe from this group and stop receiving emails from it,
> send an email to dev+uns...@opencast.org.
Reply all
Reply to author
Forward
0 new messages