Commit 7344b9374b701f98ae5e144904c2758838f7d28a
1 parent
e920f51b
Exists in
master
and in
3 other branches
08-contributions.tex: reviews
Showing
1 changed file
with
28 additions
and
26 deletions
Show diff stats
opensym2017/content/08-contributions.tex
| 1 | -\section{Contributing with Free Software Communities} | 1 | +\section{Contributions to the upstream communities} |
| 2 | \label{sec:contributions} | 2 | \label{sec:contributions} |
| 3 | 3 | ||
| 4 | %- projeto feito do jeito certo com relação ao software livre (contribuições upstream etc) | 4 | %- projeto feito do jeito certo com relação ao software livre (contribuições upstream etc) |
| @@ -9,24 +9,30 @@ | @@ -9,24 +9,30 @@ | ||
| 9 | %* Coper, empacotamentos (obs), omniauth | 9 | %* Coper, empacotamentos (obs), omniauth |
| 10 | 10 | ||
| 11 | 11 | ||
| 12 | -During the execution of this project we made several contributions from | ||
| 13 | -different levels to the communities we interacted with. This occurred due to | ||
| 14 | -our development process aligned with those of the respective communities. We | ||
| 15 | -used to discuss with upstream the features and bug fixes that we was working | ||
| 16 | -on, this kind of discussion improve the developers' technical solutions and | ||
| 17 | -allowed upstream to accept our contribution more easily. | ||
| 18 | - | ||
| 19 | -In Colab we helped upstream to redesign the entirely architecture, enabling the | ||
| 20 | -development of plugins to integrate new tools. We also added a feature that | ||
| 21 | -allowed Colab to run asynchronous tasks, which was a major improvement for us | ||
| 22 | -since we were developing a complex system. A migration to the latest Django | ||
| 23 | -version was made (web framework used by Colab). Moreover, we worked on RevProxy | ||
| 24 | -(the greatest Colab dependency) to put it in a good shape, fixing many bugs. | 12 | +During the execution of this project we made several contributions to |
| 13 | +the upstream communities we interacted with. This occurred due to our | ||
| 14 | +development process aligned with those of the respective communities. | ||
| 15 | +During development, we would explicitly discuss the features and bug | ||
| 16 | +fixes that we were working on with the applicable upstream communities. | ||
| 17 | +This contributed to improve the developers technical solutions with | ||
| 18 | +expertise outside of our team, and make it easier for those changes to | ||
| 19 | +be accepted in the original projects. Having changes accepted upstream | ||
| 20 | +in turn makes our life easier as it minimizes the delta between our | ||
| 21 | +codebase and upstream's allowing us to upgrade and benefit from | ||
| 22 | +development work from others. | ||
| 23 | + | ||
| 24 | +In Colab, we helped upstream redesign the entirely architecture, | ||
| 25 | +enabling the development of plugins to integrate new tools. We also | ||
| 26 | +added a feature that allowed Colab to run asynchronous tasks, which was | ||
| 27 | +a major improvement for us since we were developing a complex system. A | ||
| 28 | +migration to the latest Django version was made (web framework used by | ||
| 29 | +Colab). Moreover, we worked on RevProxy (the more important dependency | ||
| 30 | +of Colab) to put it in a good shape, fixing many bugs. | ||
| 25 | 31 | ||
| 26 | Gitlab was the tool that we made the least number of modifications. We | 32 | Gitlab was the tool that we made the least number of modifications. We |
| 27 | -contributed with some improvements related with configuration files and we | ||
| 28 | -developed a new omniauth plugin, which enables the user authentication in | ||
| 29 | -Gitlab via REMOTE\_USER HTTP header. This omniauth plugin was needed because | 33 | +contributed with some improvements related with configuration files and |
| 34 | +we developed a new plugin that enables user authentication in Gitlab | ||
| 35 | +through the REMOTE\_USER HTTP header. This plugin was needed because | ||
| 30 | Colab uses this mechanism to manage the authentication. | 36 | Colab uses this mechanism to manage the authentication. |
| 31 | 37 | ||
| 32 | Noosfero was the tool that contemplated several functional requirements, | 38 | Noosfero was the tool that contemplated several functional requirements, |
| @@ -35,15 +41,11 @@ migrate to the latest Rails version (web framework used by Noosfero), enable | @@ -35,15 +41,11 @@ migrate to the latest Rails version (web framework used by Noosfero), enable | ||
| 35 | the federation implementation (federation with other social networks), decouple | 41 | the federation implementation (federation with other social networks), decouple |
| 36 | the interface and the back-end, and so forth. | 42 | the interface and the back-end, and so forth. |
| 37 | 43 | ||
| 38 | -We also contributed with some DevOps tools as well during the project. Some | ||
| 39 | -member of our team took the maintenance of some python libraries that we used | ||
| 40 | -to support our scripts to upload our packages to OBS (Open Build Service). | ||
| 41 | -Since we were composed by many teams with large number of developers we had | ||
| 42 | -some problems related with the tracking of our per team/software releases, the | ||
| 43 | -DevOps team did not know when was the right time to package that software or | ||
| 44 | -not. Thus we developed a tool called copr-status to keep tracked the version | ||
| 45 | -packaged and the version finished by the developers, basically this is a web | ||
| 46 | -interface that helps you to visualize the status of that package/software. | 44 | +We also made some contributions on the DevOps front. Some members of |
| 45 | +them team became maintainers of some python libraries that were used by | ||
| 46 | +our scripts to upload packages to OBS (Open Build Service). We developed | ||
| 47 | +a tool called copr-status to keep track of the different stages of the | ||
| 48 | +lifecycle of each of the individual packages we were working on. | ||
| 47 | 49 | ||
| 48 | %TODO: Mezuro | 50 | %TODO: Mezuro |
| 49 | 51 |