[Sugar-devel] ASLO activities with no repository

[Tony Anderson]

Thanks again for your help.

What am I planning to do that will affect GitHub notifications?

What does this have to do with mentoring style?

I am glad you are getting the permissions you need to start getting 
engaged with the process.

Tony

On 05/26/2017 04:59 AM, James Cameron wrote:
> So I'm going to have to suffer and delete hundreds of GitHub
> notifications, all because you want to avoid a database?
>
> I expect most developers will turn off notifications.
> We will lose developer engagement as a result of this design.
>
> It doesn't sound like you are mentoring, it sounds like you are
> micromanaging.  Yet you aren't engaged in the process you are
> changing.
>
> Alright then, we'll see which process survives the transition.
>
> You have made me even more wary, and that's good for our end-users.
>
> On Thu, May 25, 2017 at 05:17:53PM +0800, Tony Anderson wrote:
>> I appreciate this new information.
>>
>> You have described the activity maintainer:
>>
>> "The role of an activity maintainer is to accept changes from others,
>> test the activity, iterate with fixes, update version, tag a release,
>> make a bundle, upload to ASLO, upload to download.sugarlabs.org, and
>> field any questions that arise."
>>
>>
>> The developer in this description provides the changes.
>>
>> My model is slightly different:
>>
>> An activity needs to be ported to GTK+3. The developer makes a clone and
>> makes the necessary changes with one or more commits. When the task is
>> complete, the developer requests the maintainer to publish the new activity
>> version.
>>
>> The maintainer works with the developer as you did with Utkarsh on PR #327
>> to ensure that the new version is ready for release. When that is done, the
>> maintainer bundles the activity and adds it to
>> download.sugarlabs.org/activities. ASLO then displays that version.
>>
>> "No, you're wrong, and you've got this wrong repeatedly, so please pay
>> attention; for download.sugarlabs.org/sources there is a tar file not an xo
>> file, and the setup.py argument is different; dist_source."
>>
>> The bundles are stored in download.sugarlabs.org/activities. This is the
>> source from which ASLO downloads bundles. The source directory along with
>> others there have nothing to do with ASLO.
>>
>> "There is a simpler explanation; the bug in ASLO, which was fixed recently;
>> and now the latest version released to ASLO is displayed."
>>
>>   Great! Thanks to you and whoever else helped to fix that problem."
>>
>> "I'll continue to disagree until you've shown further understanding of the
>> process. If you break the process too much, then I'll bypass it as I've
>> already had to do for the existing process breakage; which is why we have
>> several point releases of activities in OLPC OS; like Terminal 44.1,
>> Wikipedia 38.2, Pippy 70.2, Maze 26.1, GetBooks 16.2, Gears 6.2, Fototoon
>> 22.1, FindWords 3.1, and Browse 200.1. All due to absence of maintenance.
>> Sebastian was quite right to call out the problem yet again, and your
>> insistence on process change seems likely to make the problem worse."
>>
>> You have your own requirements which are apparently not now supported by
>> ASLO. The ASLO process was not broken, you just chose not to use it.
>>
>> I am working with Sam Cantaro to help mentor the ASLOv3 project. The goal of
>> this project is to make things better. It needs support from the community
>> in terms of requirements and things to avoid.
>>
>> An important simplification for this project is to separate the 'Developer
>> Hub' functionality so that it does not need to be replicated. The intent is
>> to replace it with a process based on github.
>>
>> Please help us to understand what risks you see in ASLOv3 and with trying to
>> make sure that every activity published on ASLO has a corresponding git
>> repository.
>>
>> Sam and I are in agreement that the information displayed should come from
>> the bundles and not from a database as at present. This will require
>> defining standards for the bundle different from those now in place. I
>> expect there will need to be a script to verify that a new activity version
>> has this information, possibly run as a part of bundlebuilder.
>>
>> Tony
>>
>> On 05/25/2017 03:06 PM, James Cameron wrote:
>>> On Thu, May 25, 2017 at 10:07:50AM +0800, Tony Anderson wrote:
>>>> James
>>>>
>>>> Your steps a-f and the references seem based on the Developer Hub in
>>>> ASLO.
>>> No, that's coincidence.  The steps predate that description, and were
>>> part of OLPC software development process for activities before Sugar
>>> Labs began.
>>>
>>>> In this procedure the developer does the first two steps. Step c is
>>>> an updated version number in activity.info.  Step d is 'setup.py
>>>> dist_xo'. Step e depends on the Developer Hub, but can only be done
>>>> by the developer or someone authorized by the developer. The
>>>> Developer Hub puts the bundle in download.sugar.labs/activities.
>>> Fine so far, but the better term is activity maintainer.
>>>
>>>> Step f is accomplished by step d, there is no second copy.
>>> No, you're wrong, and you've got this wrong repeatedly, so please pay
>>> attention; for download.sugarlabs.org/sources there is a tar file not
>>> an xo file, and the setup.py argument is different; dist_source.
>>>
>>> A reasonable mistake for you to make; you conflated the multiple
>>> purposes of download.sugarlabs.org, and you're not an activity
>>> maintainer, or you'd have known by now.
>>>
>>> For a given activity the tar file is not the same as the xo file,
>>> though there are plenty of similarities.  In particular the xo file
>>> has the locale directory and the tar file does not, but there may be
>>> other differences where the developer has added dist_xo or dist_source
>>> targets to setup.py.  Help and TurtleArt have done that, and there are
>>> likely more.
>>>
>>> And the above, by the way, are reasons why a zip or tar from GitHub
>>> won't be sufficient.
>>>
>>> Please read and understand the code in
>>> src/sugar3/activity/bundlebuilder.py
>>>
>>>> In this process a new submission or version is vetted by a moderator
>>>> before being displayed by ASLO.
>>> Yes, that point you make is true, but has no bearing on the
>>> discussion, because as we agreed with Samuel it will be removed.
>>>
>>> There will be no moderation apart from GitHub pull request and commit
>>> review for activities maintained there.
>>>
>>>> This may explain the many activities which display earlier versions
>>>> of an activity.
>>> There is a simpler explanation; the bug in ASLO, which was fixed
>>> recently; and now the latest version released to ASLO is displayed.
>>>
>>>> The later bundles were not uploaded through the Developer Hub or
>>>> released through the moderator.
>>> Yes, in many cases because we the activity maintainers didn't want
>>> the new version to be offered through ASLO.  An example is Browse-200,
>>> which in the state it is in if offered would break Browse entirely and
>>> not be recoverable without using Terminal.
>>>
>>> Also because without access to ASLO my point releases were not made
>>> there; instead delivered as updates to OLPC OS laptops through the
>>> microformat software update, which my download.laptop.org logs tell me
>>> is quite popular.
>>>
>>>> This Developer Hub procedure does not require that the developer use
>>>> a version control system.
>>> Yes, that's good.  Lower barrier to participation.  The GSoC and GCI
>>> students really struggle with git, so anything we can do to avoid it
>>> for standalone tasks is worth the effort.  Otherwise developers are
>>> forced to learn a complex version control system they might not need.
>>>
>>>> The intent is to replace the Developer Hub with procedures based on
>>>> github.
>>> For many reasons I still think this is a shortsighted and uninformed
>>> intent.
>>>
>>>> The github procedure involves two independent contributors - the
>>>> developer who prepares the repository for release and the maintainer
>>>> that performs the functions you have described previously.
>>> That's bad.  I'd prefer one person be responsible for an activity,
>>> because relying on two is going to slow things down, and things are
>>> already too slow.
>>>
>>>> One major benefit is that the procedure described in reference four
>>>> is not necessary.
>>> I don't think that's a major benefit; the procedure has not been used
>>> for many years.
>>>
>>>> Any authorized contributor has the permissions needed to make
>>>> changes to an activity and to prepare a new version. A maintainer
>>>> works with the developer to ensure the new version satisfies
>>>> applicable community standards and then to publish it to ASLO.
>>>>
>>>> ASLOv3 displays the most recent version of an activity. This means
>>>> the only connection between github operations and ASLO is the
>>>> installation of a new bundle in download.sugarlabs.org/activities.
>>> I'll continue to disagree until you've shown further understanding of
>>> the process.
>>>
>>> If you break the process too much, then I'll bypass it as I've already
>>> had to do for the existing process breakage; which is why we have
>>> several point releases of activities in OLPC OS; like Terminal 44.1,
>>> Wikipedia 38.2, Pippy 70.2, Maze 26.1, GetBooks 16.2, Gears 6.2,
>>> Fototoon 22.1, FindWords 3.1, and Browse 200.1.  All due to absence of
>>> maintenance.  Sebastian was quite right to call out the problem yet
>>> again, and your insistence on process change seems likely to make the
>>> problem worse.
>>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel