-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delete repository #9
Comments
@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? |
@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). |
@quozl I merged this Repository into a fork of https://github.com/fdanesse/Bichos keeping histories of both the Repositories which is available here:- 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.
I will try it again after installing sugar on virtual box. Thanks |
Considering only "doesn't show up in activity list", the causes can be;
In both scenarios, you may find confirming evidence in Regarding testing the activity; I'm not familiar with it. Do you have a test plan? |
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. |
Thanks. |
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 |
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. |
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>.
|
what do you need?
El jue., 28 feb. 2019 a las 0:50, James Cameron (<[email protected]>)
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>
.
|
@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 @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. |
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>.
|
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. |
@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. |
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 (<[email protected]>)
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
> <
#9 (comment)>,
> 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
<#9 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABsJbuS255IGwOHYDkoozF45XeYx1fgBks5vSOUGgaJpZM4YYyRR>
.
|
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!
Workaround may be to not backdate the tags. |
@quozl You have mentioned how you downloaded v1 and v2 bundles from "Hello, my name is sunjammer.sugarlabs.org and I live at the Global NAPs collocation facility, hosted by the FSF. Regarding why the tags failed to push to the clone, I'm trying look for a solution online. Thanks! |
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 |
I was able to push tags. Let's keep this repo for a week. |
Reviewed the situation. While we have a plan to delete this repository, it contains the pull requests that led to the issue sugarlabs/Bichos#2, so I'll wait for that issue to close before deleting this repository. |
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.
The text was updated successfully, but these errors were encountered: