Delete repository

[quozl]

https://github.com/fdanesse/Bichos is the upstream repository for this activity, and contains the history and is the place where a maintainer has done the most work.

• fork the other repository,
• compare the two repositories,
• merge the histories,
• delete this repository.

[avinashbharti97]

@quozl What you mean by 'this' in 'delete this repository'?

from my interpretation what we have to do is merge the all commit histories of https://github.com/fdanesse/Bichos with the https://github.com/sugarlabs/bichos-activity/ and keep the https://github.com/sugarlabs/bichos-activity/ for future development.

So by 'this' are you referring to the maintainer's Repo or the current Repo?

[quozl]

@avinashbharti97, no, this means https://github.com/sugarlabs/bichos-activity because that's where is issue is connected.

Many activities are held in repositories that are not in the https://github.com/sugarlabs organisation. Moving repositories to the organisation is by permission of the repository owner, and if we don't get permission, we create a fork using GitHub. The https://github.com/fdanesse/Bichos repository is owned by @fdanesse. The https://github.com/sugarlabs/bichos-activity repository is not fork using GitHub. So my list above is correct; at the start there are two repositories (improperly forked), during the middle steps there are three repositories, and after the last step there are two repositories (properly forked).

[avinashbharti97]

@quozl I merged this Repository into a fork of https://github.com/fdanesse/Bichos keeping histories of both the Repositories which is available here:-
https://github.com/avinashbharti97/Bichos

But on cloning the merged repo as an activity (appending .activity) into sucrose doesn't show up in activity list, and I couldn't understand the reason behind this behavior.
The possible reason could be:

• Sucrose installed on my laptop is broken or having some issue
• Activity broke in the process of merge
• something else

I will try it again after installing sugar on virtual box.
It would be helpful if you will test the merged activity.

Thanks

[quozl]

Considering only "doesn't show up in activity list", the causes can be;

• the change happened too gradually, and when Sugar went to check the change found the activity incomplete; workaround is to touch the Bichos.activity directory, and this is done by OLPC OS packages for Ubuntu to ensure Sugar checks again, or;
• the activity metadata is invalid.

In both scenarios, you may find confirming evidence in shell.log, so please check it.

Regarding testing the activity; I'm not familiar with it. Do you have a test plan?

[avinashbharti97]

Since the activity is not in english language I would not like to test it. And by 'test' I only meant to check if the merged activity is working or not. So all I wanted is to check by cloning the repo as an activity bundle and if all seems okay then I will make a pull request to the original developer.

[quozl]

Thanks.

[tony37]

The simple process is to base a repository on the activity as stored in the ASLO archive. Changes to the activity in a developer's repository is irrelevant. A change to an activity should be submitted by pull request.

A history of the changes made between the current version and the one created by a pull request can be included in the pull request.

Tony

[quozl]

Thanks, but as you don't make changes as a developer, your opinion is not needed on the issue. This is an issue of development source control, as distinct from release source control.

[tony37]

The development history is shown in the Github repository. The development is done by a developer independent of Sugar, Github as pointed out in your guidelines: neither gitHub or git are mandatory (which is absolutely corret). The developer is free to develop as he or she pleases.  What needs to be controlled is submissions of new activity versions to gitHub (and thus to ASLO). I am sure my opinion is not needed; however, I will continue to distrust version control in github until some proper procedures are put in place. Tony

…

On 2/28/19 11:50 AM, James Cameron wrote: Thanks, but as you don't make changes as a developer, your opinion is not needed on the issue. This is an issue of development source control, as distinct from release source control. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAULkoGt89zo6XX5SF2ZX0NGYRx3ysl-ks5vR1HwgaJpZM4YYyRR>.

[fdanesse]

what do you need? El jue., 28 feb. 2019 a las 0:50, James Cameron (<notifications@github.com>) escribió:

…

Thanks, but as you don't make changes as a developer, your opinion is not needed on the issue. This is an issue of development source control, as distinct from release source control. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABsJbnDiNUULGMeKqOi9Za9NoTI0L8-Gks5vR1HwgaJpZM4YYyRR> .

[quozl]

@tony37, no it isn't shown. You only added v1 and v2 commits. All the other commits before that were lost. This isn't the way developers use git. We use git not just as a release source control system, but also as a development source control system. Perhaps you've not used it that way; fine, but let us use it the way git is normally used. We use git bisect in particular to track down which change in development caused a problem. Each change carries context which helps. Adding commits for whole bundles reduces the usefulness of git.

@fdanesse, my apologies, this repository was created by @tony37 against the wishes of other developers. In doing that he lost your commit history; your authorship, dates, and specific changes. I'd like to get them back. I think the way to get them back is to;

• fork your repository to Sugar Labs,
• compare the two repositories,
• merge the histories, (not a simple merge as @avinashbharti97 did, but a cherry-pick),
• delete this repository.

I'm not the best person for the job because I don't understand the activity and can't read the language. So I created this issue so that when someone does become available, they can work on it.

Eventually, a new release can be made.

[tony37]

I realize your mind is made up  but I will try again. The crux of the matter is that a Sugar activity is not the same as code for what you call the 'Sugar Desktop'. The Sugar code is developed cooperatively among a team of developers each of whom is making changes to various files. The goal is to build a system release. This is an environment for which git and gitHub is designed. A sugar activity is an independent program produced or adapted by someone who submitted it to ASLO and had it accepted for distribution. When a new version of an activity is ready, it was submitted via the same process with a new version number (and no information on the specific code changes made). Because the original contributors for many of the activities are no longer supporting them, it becomes the responsibility of the Sugar community to preserve their value. The gitHub role here to keep a record of that changes made between versions. Naturally, the contributor may keep a git repository to support development, but that is irrelevant to our need to maintain version control for the activity. So generally between version releases of an activity, we should see one commit. However, we should expect multiple commits on the files that are part ot Sugar. What has the highest priority to me is to make and keep as many of these activities as possible usable. The good news is that virtually all of them worked when originally submitted and so are victims of changing upstream support. This generally means that the problems can be resolved without a detailed knowledge of the design. This has been quite evident in the ports to GTK3. In this specific instance, finding out if the original developer of bichos kept a git record of the development is interesting but has no bearing on whether that activity works (it doesn't). This problem has nothing to do with development, the activity wraps binary code which does not work on ARM. I still dream of the possibility of Sugar Labs and its community becoming focused on its original objectives - to provide a more effective educational opportunity for school children on the wrong side of the (ever-growing) digital divide. Sadly, that mission is being far more effectively served today by the Raspberry Pi Foundation and the Make movement. Tony

…

On 3/1/19 10:50 AM, James Cameron wrote: @tony37 <https://github.com/tony37>, no it isn't shown. You only added v1 and v2 commits. All the other commits before that were lost. This isn't the way developers use git. We use git not just as a release source control system, but also as a development source control system. Perhaps you've not used it that way; fine, but let us use it the way git is normally used. We use |git bisect| in particular to track down which change in development caused a problem. Each change carries context which helps. Adding commits for whole bundles reduces the usefulness of git. @fdanesse <https://github.com/fdanesse>, my apologies, this repository was created by @tony37 <https://github.com/tony37> against the wishes of other developers. In doing that he lost your commit history; your authorship, dates, and specific changes. I'd like to get them back. I think the way to get them back is to; * fork your repository to Sugar Labs, * compare the two repositories, * merge the histories, (not a simple merge as @avinashbharti97 <https://github.com/avinashbharti97> did, but a cherry-pick), * delete this repository. I'm not the best person for the job because I don't understand the activity and can't read the language. So I created this issue so that when someone does become available, they can work on it. Eventually, a new release can be made. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAULktsS4qmOsi1_Y8BYyJhVevWoRl-tks5vSJWBgaJpZM4YYyRR>.

[quozl]

But @tony37, you don't do development with us; no source code changes, just lots of verbal conflict, and trolling like "what you call the 'Sugar Desktop'". Please stop intruding. If you really cared, we'd see you working on real problems rather than always whinging about how we do things.

[walterbender]

@tony37 As I explained some time ago when you made repos without preserving the git commit history, this (1) makes it harder for maintainers to follow the logic of changes; (2) it removes valuable information for the learner by suggesting that activities appear in whole clothe rather than being an iterative process that often involves many disparate contributors; (3) it devalues the role of the individuals who contributed their time and talent in creating the activity, more often than not with no other compensation than acknowledgement of their work from the community, users, and potential contributors, and (4) it anonymizes their contributions, making it unclear whom a potential contributor might consult for help with the activity in question or other activities that may be related in theme or practice.

As someone who has written quite a few Sugar activities, I find the practice of deleting the git history really off-putting.

We have had well-established processes in place (documented here) that has been working well. If you have issues with these instructions, please raise your issues with the community either as a GH issue or in a discussion thread on the devel mailing list.