Hello, Thanks for your email. I had the same concern when I started working with Etherlab. I've also some patch (mostly EoE and SoE) but ... well I don't want to add a patchset as it's done now. For me the main question remain how to manage starting a new project on github but also keeping the sourceforge branch ?
Do main contributors (Florian Pose, Philipp Weyer, Gavin ...) have an opinion on that ? Thanks to ask this question, Best regards, Titouan Mesot -----Message d'origine----- De : etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] De la part de Esben Haabendal Envoyé : mercredi 28 février 2018 13:49 À : etherlab-dev@etherlab.org Objet : [etherlab-dev] Community contribution 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/ But as Gavin writes: > 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. 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 _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
