search

sugarlabs / bichos-activity

Other
0 stars 2 forks source link

Delete repository #9

Open quozl opened 5 years ago

quozl commented 5 years ago

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.

avinashbharti97 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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:

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

Thanks

quozl commented 5 years ago

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

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 commented 5 years ago

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 commented 5 years ago

Thanks.

tony37 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 https://github.com/sugarlabs/bichos-activity/issues/9#issuecomment-468126892, or mute the thread https://github.com/notifications/unsubscribe-auth/AAULkoGt89zo6XX5SF2ZX0NGYRx3ysl-ks5vR1HwgaJpZM4YYyRR.

fdanesse commented 5 years ago

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 https://github.com/sugarlabs/bichos-activity/issues/9#issuecomment-468126892, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJbnDiNUULGMeKqOi9Za9NoTI0L8-Gks5vR1HwgaJpZM4YYyRR .

quozl commented 5 years ago

@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;

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 commented 5 years ago

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 https://github.com/sugarlabs/bichos-activity/issues/9#issuecomment-468522315, or mute the thread https://github.com/notifications/unsubscribe-auth/AAULktsS4qmOsi1_Y8BYyJhVevWoRl-tks5vSJWBgaJpZM4YYyRR.

quozl commented 5 years ago

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 commented 5 years ago

@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.

fdanesse commented 5 years ago

I can help you if you need me, but please explain me what you want in Spanish. I am very bad with English.

El vie., 1 mar. 2019 a las 5:29, tony37 (notifications@github.com) escribió:

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 < https://github.com/sugarlabs/bichos-activity/issues/9#issuecomment-468522315>,

or mute the thread < https://github.com/notifications/unsubscribe-auth/AAULktsS4qmOsi1_Y8BYyJhVevWoRl-tks5vSJWBgaJpZM4YYyRR .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sugarlabs/bichos-activity/issues/9#issuecomment-468585348, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJbuS255IGwOHYDkoozF45XeYx1fgBks5vSOUGgaJpZM4YYyRR .

nswarup14 commented 5 years ago

@quozl I have merged the histories of the two repositories here. I have resolved any conflicts that arose while cherry-picking the commits. Please Review.

quozl commented 5 years ago

Thanks for your work on this. I think from the responses so far that I've failed to properly explain what was needed, so I've done it myself. Look at https://github.com/sugarlabs/Bichos/commits/master for the result so far. Note how few commits are listed.

Here's what I did;

The tags would not push though, and I'm looking into that. Any hints welcome!

$ git push --tags
Total 0 (delta 0), reused 0 (delta 0)
To github.com:sugarlabs/Bichos.git
 ! [remote rejected] v1 -> v1 (pre-receive hook declined)
 ! [remote rejected] v2 -> v2 (pre-receive hook declined)
error: failed to push some refs to 'git@github.com:sugarlabs/Bichos.git'

Workaround may be to not backdate the tags.

nswarup14 commented 5 years ago

@quozl I think I finally understood the issue at hand. I wasn't aware about how tagging takes place on Git, so I might have cherry-picked the commits incorrectly.

You have mentioned how you downloaded v1 and v2 bundles from sunjammer.sugarlabs.org. However, I am unable to find the bundles in the above link. The link redirects me to a static web page and with the following information.

"Hello, my name is sunjammer.sugarlabs.org and I live at the Global NAPs collocation facility, hosted by the FSF. My job is to run the core infrastructure of Sugar Labs, a non-profit promoting a creative learning environment designed for young children"

Regarding why the tags failed to push to the clone, I'm trying look for a solution online.

Thanks!

quozl commented 5 years ago

Thanks. Sorry about that. Bundles are available here;

I got to that directory from

I knew the bundle number from searching for the release announcements in my mail;

Might you try adding the same backdated tags and pushing them to your repository? This will at least confirm it isn't a problem with my environment. Use git push --tags to push tags.

nswarup14 commented 5 years ago

@quozl I was successfully able to push the tags to the right commit messages. However I was only able to push it to my fork (here), and I can't seem find an option to make a PR. Can you guide me on this?

Thanks.

quozl commented 5 years ago

I was able to push tags. Let's keep this repo for a week.

quozl commented 5 years ago

Reviewed the situation. While we have a plan to delete this repository, it contains the pull requests that led to the issue https://github.com/sugarlabs/Bichos/issues/2, so I'll wait for that issue to close before deleting this repository.