Esben Haabendal
2018-02-28 12:48:45 UTC
Hi all
In order to ease maintenance and improve the development of
etherlabmaster, I believe we need to make some changes to how things are
done.
In the current situation, it is not clear what can be done to get
patches merged to the official repository. So we are basically all
relying on Gavin maintaining his patchset, which he does based on the
default branch and backports from stable-1.5 branch.
The default branch is mostly unmaintained, last commit is from August
2017, and as far as I can see, the last patch coming from community
contribution (as in not from IgH) is dated back to April 2015.
The idea of viewing the default branch as "upstream" does not really
make sense, when you cannot actually get something "upstreamed" to it.
The only true upstream we have is currently Gavins patchset
https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/
Note, this by no means a criticism of Gavins work. We have and are
still very pleased with the work he has done. I don't know what we
should have done without it for the last couple of years!
But I believe we can and should do better than that. Together with you,
Gavin.
Sending patches to an "unstable" patchstack is IMHO much harder than
what is usual for community FOSS projects. It is most likely keeping
some people from contributing their work back to the etherlabmaster
community.
And for those who do try to work actively with this model, it is placing
an unreasonable maintenance burden, as you have to be prepared for
continous rebasing your work, as the patchset is such a moving target.
I propose we switch from the current patchset approach, and start
cooperating via a GitHub project. Changes can then be sent to the
project in the form of a GitHub pull request, and this can be reviewed,
discussed and merged much simpler.
Compared to the current situation, it could be a replacement for the
patchset by Gavin. I expect that IgH (Florian) will continue maintaining
the stable-1.5 and default branch for its customers in the current
sourceforge mercurial repostiory. But it would ofcourse be nice if IgH
would be willing to work together with the etherlabmaster community yet
again, and they will be more than welcome to do that.
On the GitHub project, we could maintain a master branch which carries
the latest development version of our etherlabmaster, and one or more
stable branches.
With this as a platform, it should be possible to start making releases
(again). Putting a proper version number on the code, taking care of
API and ABI breakage, providing structured information about what
changed since last version, and with library ABI versioning managed for
released versions.
To ease sharing of code with IgH etherlabmaster, vendor branches should
be setup to track IgH stable-1.5 and default branches in the GitHub
project. Changes made by IgH can then either be cherry-picked or merged
from them.
If we do this, I hope it should be much more obvious for new-comers how
to work with and contribute to the etherlabmaster community.
As it is now, a typical new-comer will have a hard time finding out what
to do.
Just finding the correct "baseline" to start with is hard. Should you
use stable-1.5 branch, default branch, the full patchset on top of
default, or some combination of these?
And when you have made some changes based on the chosen baseline, how do
you send it "back"? Where and in which form? What can and should you
do to get it "merged", for whatever that might mean?
If you have some changes that have not been merged in the chosen
"baseline", and the baseline is updated, how do you integrate your
changes with the new baseline version?
Let's address this together by creating a GitHub project for maintaining
the etherlabmaster code together.
Contributing to etherlabmaster will be easy. You start by picking the
branch to work from, either a stable branch or the current development
branch. When you want to contribute changes back, you send a GitHub
pull request. When you want to integrate changes made to the branch you
use as baseline, you do a simple git merge or git rebase.
Well, this got **really** long.
If you made it all the way through it, please let me know what you
think.
If we setup a GitHub project, will you work with that? Do you prefer
the current setup? Or do you have other ideas for how we should work
together.
/Esben
In order to ease maintenance and improve the development of
etherlabmaster, I believe we need to make some changes to how things are
done.
In the current situation, it is not clear what can be done to get
patches merged to the official repository. So we are basically all
relying on Gavin maintaining his patchset, which he does based on the
default branch and backports from stable-1.5 branch.
The default branch is mostly unmaintained, last commit is from August
2017, and as far as I can see, the last patch coming from community
contribution (as in not from IgH) is dated back to April 2015.
The idea of viewing the default branch as "upstream" does not really
make sense, when you cannot actually get something "upstreamed" to it.
The only true upstream we have is currently Gavins patchset
https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/
However neither the patches nor the patchset is stable, in the sense
that future versions of the patchset may add, remove, reorder, or
modify existing patches
So our upstream is per definition not stable.that future versions of the patchset may add, remove, reorder, or
modify existing patches
Note, this by no means a criticism of Gavins work. We have and are
still very pleased with the work he has done. I don't know what we
should have done without it for the last couple of years!
But I believe we can and should do better than that. Together with you,
Gavin.
Sending patches to an "unstable" patchstack is IMHO much harder than
what is usual for community FOSS projects. It is most likely keeping
some people from contributing their work back to the etherlabmaster
community.
And for those who do try to work actively with this model, it is placing
an unreasonable maintenance burden, as you have to be prepared for
continous rebasing your work, as the patchset is such a moving target.
I propose we switch from the current patchset approach, and start
cooperating via a GitHub project. Changes can then be sent to the
project in the form of a GitHub pull request, and this can be reviewed,
discussed and merged much simpler.
Compared to the current situation, it could be a replacement for the
patchset by Gavin. I expect that IgH (Florian) will continue maintaining
the stable-1.5 and default branch for its customers in the current
sourceforge mercurial repostiory. But it would ofcourse be nice if IgH
would be willing to work together with the etherlabmaster community yet
again, and they will be more than welcome to do that.
On the GitHub project, we could maintain a master branch which carries
the latest development version of our etherlabmaster, and one or more
stable branches.
With this as a platform, it should be possible to start making releases
(again). Putting a proper version number on the code, taking care of
API and ABI breakage, providing structured information about what
changed since last version, and with library ABI versioning managed for
released versions.
To ease sharing of code with IgH etherlabmaster, vendor branches should
be setup to track IgH stable-1.5 and default branches in the GitHub
project. Changes made by IgH can then either be cherry-picked or merged
from them.
If we do this, I hope it should be much more obvious for new-comers how
to work with and contribute to the etherlabmaster community.
As it is now, a typical new-comer will have a hard time finding out what
to do.
Just finding the correct "baseline" to start with is hard. Should you
use stable-1.5 branch, default branch, the full patchset on top of
default, or some combination of these?
And when you have made some changes based on the chosen baseline, how do
you send it "back"? Where and in which form? What can and should you
do to get it "merged", for whatever that might mean?
If you have some changes that have not been merged in the chosen
"baseline", and the baseline is updated, how do you integrate your
changes with the new baseline version?
Let's address this together by creating a GitHub project for maintaining
the etherlabmaster code together.
Contributing to etherlabmaster will be easy. You start by picking the
branch to work from, either a stable branch or the current development
branch. When you want to contribute changes back, you send a GitHub
pull request. When you want to integrate changes made to the branch you
use as baseline, you do a simple git merge or git rebase.
Well, this got **really** long.
If you made it all the way through it, please let me know what you
think.
If we setup a GitHub project, will you work with that? Do you prefer
the current setup? Or do you have other ideas for how we should work
together.
/Esben