[etherlab-dev] Community contribution

[Titouan Mesot]

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-bounces at etherlab.org] De la part de
Esben Haabendal
Envoyé : mercredi 28 février 2018 13:49
À : etherlab-dev at 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 at etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5629 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20180301/a64a6d85/attachment.bin>