WebOS-Patches Web Portal now Online! (Browse Patches, Submit New or Submit Update!)

[dBsooner]

I have finally finished the next version of my "WebOS-Patches Submission Form". I have decided to name it the "webOS-Patches Web Portal". What are the new features in this portal you ask?

1. Online Browsing of Patches available in the WebOS-Patches feed! Yes, you can now browse all the WebOS-Patches from your web browser.
2. Ability for developers to submit an UPDATE to their (or anyone's) patches!
3. More robust new patch submission back-end processing.
4. Faster turn around time as most processes are now automated.
5. Administration panel to allow the WebOS-Patches admins to process patches universally.
6. Plus much, much, more...

As you can see the biggest addition is the ability for everyone to browse the WebOS-Patches feed from a web browser. Bear in mind I didn't make this very pretty. I just made it functional. Later incarnations will make it more pretty on the eyes. However, the information is there and is very user-friendly. Just check it out for yourself: dBsooner's webOS-Patches Web Portal

The other big addition is the ability to submit an update to a patch. If you select "Submit an Update" from the WebOS-Patches Web Portal, you will be presented with a list of all Patches in the feed. You can select the one you want to update and click next. This will take you to the submission form and pre-fill all the data on the form. It also adds a new field for a true changelog. Note to developers: You cannot change the Category or Title of a patch you are updating. This is because these two are tied directly to the packageid which is crucial to how the auto-update process works. Also, some installers rely on the packageid not changing. Therefor, you will not be able to change these two fields during an update.

There is also a lot of hidden features the public will never see. The admin panel allows the WebOS-Patches admins to automate most of the old processes. These processes used to be done by hand which was very tedious. Hints why it took so long to turn around a patch when you submit it. Further, more admins can now do the job as it will be pretty much fool proof. (Yes, some of us can be pretty foolish when we go weeks without sleep). More Admins = MUCH faster turn around. As you can see, the goal is to get stuff to the community more quickly and efficiently.

So, I say "enjoy the new WebOS-Patches Portal!" Let me know your thoughts. Please be constructive with any criticisms. Also remember, I wasn't going to looks. I was going for pure functionality to get this release out to the public.

We will use this thread to strictly talk about the WebOS-Patches Web Portal. Any posts talking about patches, submissions not being accepted yet, patches not applying, etc will be deleted.

I have setup a Trac site for keeping track of the progress of the WebOS-Patches Web Portal. You can see the history of changes, what is in the works and even browse the source code.

I will be using this thread as a way for you all to inform me of bugs, enhancement suggestions, etc. As you give them to me, I will create the tickets for them.

Check out the Trac site at: WebOS-Patches Web Portal Trac

Update: You can now sort the browsing section! I have also added the date the patch was last updated to the table. However, this date is the date it was last updated via the portal. All patches began with Sunday January 11th as their "last updated" date because this is the day the portal was brought online. If the patch has been updated since then, the last updated will reflect the new date. Also, emails are now sent to the developers when they submit a patch as well as whenever it is approved or denied.







-Daniel

[DrewPre]

Are there crib notes for the above post? :0)

[AdmiralRaptor]

got the link to this post from twitter, i gotta say, I am pleasantly surprised to see this! Definitely a very nice thing to add, just as Palm claims to be airing the app catalogue in desktop browser as well. Actually if you were able to get all the feeds available from preware, functioning very similarly to the on-device app, but in browser, you could probably replace the precentral.net app catalogue, and adding text messaging links to the download link, much like Palm says they're going to do with the in-browser app catalogue would be cool.

If you could do that with the web site, I guarantee you the browser page will be a hit. I would not suggest posting developer news, or developer forums on the site though, they can find the wiki on their own already, but keep the site very simple and void of techy stuff, you want it to be super user-friendly for the avg person, so that if a non-technical pre user stumbled accross the site on accident, they could very easily learn their way around, get preware on the phone, and start patching.

[cfbauer]

Originally Posted by AdmiralRaptor

I would not suggest posting developer news, or developer forums on the site though, they can find the wiki on their own already, but keep the site very simple and void of techy stuff, you want it to be super user-friendly for the avg person, so that if a non-technical pre user stumbled accross the site on accident, they could very easily learn their way around, get preware on the phone, and start patching.

Cheers! I love it. One suggestion:

I think an easy to find "how do I use these things?" link on the to navigation / home page / both would help new users. It could be a quick description, something like:

These patches allow users of Palm's WebOS to change the way it works. They can be installed using your computer and WebOS Quick Install, found here.

This seems so obvious to those of us used to the system, but intros on the home page are a Godsend for potentially confused new users, and they just take a small amount of effort.

[Blacklight]

Thanks, this is very comfortable! I think screenshots and maybe a rating-system/sorting options would make it even more comfortable, but this is already pretty good

[ajborley]

Great stuff! One question about this:

Originally Posted by dBsooner

The other big addition is the ability to submit an update to a patch. If you select "Submit an Update" from the WebOS-Patches Web Portal, you will be presented with a list of all Patches in the feed. You can select the one you want to update and click next. This will take you to the submission form and pre-fill all the data on the form. It also adds a new field for a true changelog. Note to developers: You cannot change the Category or Title of a patch you are updating. This is because these two are tied directly to the packageid which is crucial to how the auto-update process works. Also, some installers rely on the packageid not changing. Therefor, you will not be able to change these two fields during an update.

Does this mean someone who submits an update is branching the patch or creating a new version of the patch? If they create a new version is there not scope for someone to maliciously edit a patch in some way and then watch as the update is pushed out to everyone who has it? I'm sure I've got the wrong end of the stick here!

Many thanks again!

[dBsooner]

Originally Posted by Blacklight

Thanks, this is very comfortable! I think screenshots and maybe a rating-system/sorting options would make it even more comfortable, but this is already pretty good

There are screenshots. Just click the SS1/2/3 link for each patch. If there is a SS, those links are there. It's a popup when you click the link.

I am going to add sorting later today. I just wanted to get the base system online before the week started.

I am thinking of a rating system, but don't know how to approach that yet. I would like for it to tie into Preware/WOSQI/etc somehow, but need to brainstorm.

Thanks for the suggestions!

[dBsooner]

Originally Posted by ajborley

Great stuff! One question about this:



Does this mean someone who submits an update is branching the patch or creating a new version of the patch? If they create a new version is there not scope for someone to maliciously edit a patch in some way and then watch as the update is pushed out to everyone who has it? I'm sure I've got the wrong end of the stick here!

Many thanks again!

Nah, you got the wrong process on this. But it's a common misconception. Let me give you the run down:

1) Developer sees a patch they want to UPDATE (not branch.. branching would mean changing the code in some way to make it function differently. Updating is simply enhancing or making it work for new WebOS Verisions) and creates/modifies the .patch file.
2) Developer goes to the WebOS-Patches Web Portal and selects "Submit Update".
3) Developer selects the patch they are submitting an update for.
4) The NEW UPDATED patch is put into a holding status for an admin to review. The OLD patch is not touched in any way and is still listed as the current patch for all to see and use.
5) Admin reviews the patch submitted to ensure it's safe and doesn't spawn a new branch of the patch, etc. That it is strictly an UPDATE.
6) If admin agrees, he/she selects "accept". This starts the ball rolling for the patch to move from the Web Portal to the build area where it gets packaged up for distribution via the WebOS-Patches feed.
7) Admin can also modify the title, update area, etc if he/she chooses. This would be in the case the patch was a branch, not an update. Then the admin could choose accept and the process to build starts.

So, things aren't completely automatic. An admin still reviews the submission to ensure it's safe. Until we can get login's and password's and everything else, there is no real way to authenticate a patch submission. Therefor, it's not safe to automate all processes. There is still the need for a manual review.

Does this answer your question? Basically there is no way for a malicious patch to get out without an admin's knowledge. This is by design.

[Shawalli]

it might also be useful to put a "last updated" column (or maybe a date next to the supported version number) somewhere to so people can see how fresh or stale a patch is. A patch will obviously work with the versions it says it supports, but sometimes it's also good to know how long ago the patch was made.

[josecaguas]

I don't know how reasonable a request this is but I'd like to see some kind of caution when patchs are incompatible. Say two patches affect something similar like device menu etc.

[Spader]

Very nice! A great way to browse the patches available without having to go through Preware.

[dBsooner]

Originally Posted by Shawalli

it might also be useful to put a "last updated" column (or maybe a date next to the supported version number) somewhere to so people can see how fresh or stale a patch is. A patch will obviously work with the versions it says it supports, but sometimes it's also good to know how long ago the patch was made.

This is going to be the plan. However, before this new system went into place, there was really no way of tracking when a patch was creating. I suppose I could look at the git commits and then translate a day to epoch time...

What I plan on doing, though, is just wait till all the patches cycle through and start using the "timestamp" I have for them. I epoch timestamp 3 things: time submitted, time accepted, time updated. The submitted time is really only of use to admins. The other two will be available to the public. But, at this time all patches have a timestamp within 2 seconds of each other (however long it took to do 200 insertion's on the sql database). I'll look at maybe updating them with their original git submit time, but don't plan on it as it would be a lot of work.

-dB

[dBsooner]

Originally Posted by josecaguas

I don't know how reasonable a request this is but I'd like to see some kind of caution when patchs are incompatible. Say two patches affect something similar like device menu etc.

This has been a problem since day 1 of patching. It's probably not likely to change anytime soon. HOWEVER, I might be able to add a "POSSIBLE" conflict when two patches touch the same file within 10 lines of each other or something. But that wouldn't guarantee an incompatibility. It would only me the two patches come very close to modifying the same lines of code. I'll look into it.

Thanks!

-dB

[egaudet]

Originally Posted by dBsooner

This has been a problem since day 1 of patching. It's probably not likely to change anytime soon. HOWEVER, I might be able to add a "POSSIBLE" conflict when two patches touch the same file within 10 lines of each other or something. But that wouldn't guarantee an incompatibility. It would only me the two patches come very close to modifying the same lines of code. I'll look into it.

Thanks!

-dB

There's far too much involved for it to be worth anything, and that's even if you can get it robust.

A patch's "line" number is not forced, and GNU patch will correctly adjust the line offset (succeeded with fuzz). There are far too many combinations to do a robust check of them all.

The only option really is to allow users to mark/notify which patches are incompatible with each other.

[dBsooner]

Originally Posted by emoney_33

There's far too much involved for it to be worth anything, and that's even if you can get it robust.

A patch's "line" number is not forced, and GNU patch will correctly adjust the line offset (succeeded with fuzz). There are far too many combinations to do a robust check of them all.

The only option really is to allow users to mark/notify which patches are incompatible with each other.

Or: Apply the patch to a Stock WebOS. Find out what file(s) that patch touched and then find any other patches that touch the same file(s) and apply them one by one (apply->remove, apply->remove). If any fail to apply, then it's an incompatibility.

That still would be a huge headache. Sure, automation would help here, but is it really worth it? I don't think so.

[egaudet]

Originally Posted by dBsooner

Or: Apply the patch to a Stock WebOS. Find out what file(s) that patch touched and then find any other patches that touch the same file(s) and apply them one by one (apply->remove, apply->remove). If any fail to apply, then it's an incompatibility.

That still would be a huge headache. Sure, automation would help here, but is it really worth it? I don't think so.

Well I guess if AB, AC and BC works then ABC will work. So you could probably do a test on each new submission that does "apply to stock webos" then --dry-run every single patch (use lsdiff and grep if you want to limit to only same file patches) to mark conflicts. The combinations for each patch would be (1+2...+n-1+n), with n being the numbered of patches that touched the a file in said patch.

Thinking about it, it may not be AS bad as I originally thought. But still not guaranteed to be completely accurate, I'm sure I'm missing some outside cases.

[dBsooner]

I have setup a Trac site for keeping track of the progress of the WebOS-Patches Web Portal. You can see the history of changes, what is in the works and even browse the source code.

I will be using this thread as a way for you all to inform me of bugs, enhancement suggestions, etc. As you give them to me, I will create the tickets for them.

Check out the Trac site at: WebOS-Patches Web Portal Trac

[dBsooner]

Added the ability to sort the patches while you are browsing them! I updated the OP with more information.

[milominderbinder]

Thanks for doing this!

- Craig

[plee3]

I saw that the dependencies for the pdf-viewer patches have been removed in the preware/build.git repository a couple of days ago.

But since the version stamps have not been changed, the .ipk for these patches have not been rebuilt to no longer have the pdf-viewer-extract-app dependency.

When will these pdf-viewer patches be updated?

Thanks... plee3