Hi Federico, With the undergoing Google Code In contest, it make sense to delayed my proposal. I will be out of my office for one month and will not be able to be active on that field. If we decide to commit this proposal I will be glad to maintain those packages. Cheers
Light Xavier / Pudhuveedu PGP Fingerprint: CAE5 CE4A EFE9 134F D991 5465 081C B6FB 2EAC 6CC9 <http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x081CB6FB2EAC6CC9> 2017-12-18 0:33 GMT+05:30 Federico Capoano <[email protected]>: > I have been trouble to reply to all messages and pull requests latelly. > I'm sorry for this. > > I can't find a way to test all the proposed changes, but I can tell you > your help in maintaining our package in the official LEDE repository would > be absolutely welcome and very helpful. > > Federico > > On Fri, Dec 15, 2017 at 5:17 AM Xavier Maysonnave <[email protected]> > wrote: > >> >> Hi All, >> >> I'll take more time about your doubts. >> I need to investigate a little bit more. >> >> In the meantime I setup a new project on my repo called >> openwisp-feed-origin >> <https://github.com/xmaysonnave/openwisp-feed-origin>. >> The idea is the following: >> - openwisp-feed is the mirror on what's deployed at OpenWRT/LEDE while >> openwisp-feed-origin is our own feed before deployment. >> This address the gap who could exist between both repo. We could imagine >> a newer version available on our repos giving us the needed time to deploy >> on OpenWRT/LEDE. The good thing about this solution is that both feeds >> retrieve the same version (possibly). >> The other good thing is that those feeds have different identifier >> letting the user either use the official openwisp-config or our hosted >> openwisp-config-origin. The identifier are different avoiding any semantic >> collapse. >> >> - here is a snapshot of my feed: >> >> src-git packages https://git.lede-project.org/ >> feed/packages.git;lede-17.01 >> src-git luci https://git.lede-project.org/project/luci.git;lede-17.01 >> src-git routing https://git.lede-project.org/feed/routing.git;lede-17.01 >> src-git telephony https://git.lede-project.org/ >> feed/telephony.git;lede-17.01 >> src-git openwisp https://github.com/xmaysonnave/openwisp-feed-origin >> >> The comma specifies a branch while a caret specifies a tagged version, >> here is an example (this one is not implemented yet but it gives a good >> idea on what could be achieved. >> >> >> src-git openwisp https://github.com/xmaysonnave/openwisp-feed-origin >> ^ >> b54aded2336059e0be46f046992fabaae927ab46 >> >> >> >> This sample shows a git commit hash after the caret and is linked to a >> git commit hash. >> This value actually is the real 0.4.5 commit hash. >> but is not operational on my repo yet. >> >> Feedback are very welcome. >> >> Light >> >> Xavier >> / Pudhuveedu >> >> PGP Fingerprint: CAE5 CE4A EFE9 134F D991 5465 081C B6FB 2EAC 6CC9 >> <http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x081CB6FB2EAC6CC9> >> >> 2017-12-13 13:58 GMT+05:30 Federico Capoano <[email protected]>: >> >>> Thank you for your work Xavier! >>> >>> The only doubt I have about forcing a choice between SSL libraries is >>> that when our build system compiles and produces new versions of >>> openwisp-config that are then published on downloads.openwisp.org >>> <http://downloads.openwisp.org/openwisp-config/>, we enable all the SSL >>> libraries and we only compile openwisp-config, this produces all the >>> variants with a single compilation, which is very efficient and easy to >>> maintain. >>> >>> Can you find a way to have both? Like a flag that when enabled allows >>> enabling all SSL libraries? >>> >>> Regarding the name, it's called openwisp-config because in the original >>> vision this package is focused on handling configuration logic, to make it >>> clear we don't want to add a huge amount of features in there, as many >>> other projects instead tend to do: they bloat their packages until they >>> become unmaintainable. >>> We have additional packages (luci-openwisp and openwisp-netcheck which >>> hasn't been rolled out into production yet) and we'll likely add more into >>> the mix. It's just a matter to refine this ecosystem properly over time >>> (good documentation, clean makefile, avoid duplication by sharing common >>> code and so on - which now surely need improvement) and then create one >>> single meta-package called openwisp which allows users to choose what they >>> want from these features we have or want to have (configuration, limited >>> luci, net-check, monitoring, ecc), we are just not at that stage yet. >>> >>> Federico >>> >>> On Wed, Dec 13, 2017 at 6:40 AM Xavier Maysonnave < >>> [email protected]> wrote: >>> >>>> Hi federico, >>>> Basically I agree on what you say. >>>> Little steps, planning, documenting. >>>> I forked and started to work on a cleaner version (my personal taste). >>>> On https://github.com/xmaysonnave there is several cloned repos. >>>> openwisp-config is the agent package while openwisp-feed is the >>>> OpenWRT/LEDE feed. >>>> At this stage when the official feeds are loaded, one has to patch the >>>> feeds/packages/admin/openwisp-config with the content of >>>> openwisp-feed/openwisp-config content. >>>> I try to reach a flexible balance between what's hosted on OpenWRT/LEDE >>>> and the upcoming version. >>>> Right now the main thing I did is a choice list where the user choose >>>> its ssl flavor. reducing the risk to build and deploy the four variant with >>>> unpredictable results. >>>> I would like to properly host a feed in the main openwisp github >>>> letting the user to choose which version he want to use. The legacy feed or >>>> the openwisp hosted feed. That way it reduces the manual manipulation and >>>> gives the user to choose what he want. I've no idea how long time it could >>>> take to deploy a feed on OpenWRT/LEDE but many times it takes a while >>>> between the availability of a new version and its effective deployment. >>>> Feedback are welcomed. >>>> I like to clone and prepare something in parallel. It helps to clarify >>>> things. >>>> By the way I don't like to much the name openwisp-config. openwisp >>>> alone sounds more effective. >>>> Thanks >>>> >>>> Light >>>> >>>> Xavier >>>> / Pudhuveedu >>>> >>>> PGP Fingerprint: CAE5 CE4A EFE9 134F D991 5465 081C B6FB 2EAC 6CC9 >>>> <http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x081CB6FB2EAC6CC9> >>>> >>>> 2017-12-10 17:26 GMT+05:30 Federico Capoano <[email protected] >>>> >: >>>> >>>>> Hi Xavier, >>>>> >>>>> the version in the LEDE feeds need to be updated, it was put up by >>>>> Gabriel, an occasional contributor, but he's not maintaining it and I >>>>> don't >>>>> have time to do it right now.. >>>>> >>>>> At the moment I think we really have to start planning next steps in a >>>>> way that a good balance between usefulness and maintenance overhead is >>>>> reached. >>>>> So I would want to ask you: how would the life of openwisp users >>>>> improve by implementing the change you suggest? And who will be >>>>> responsible >>>>> of maintaining the new feed as the project moves forward? >>>>> >>>>> I would encourage anyone who is using openwisp-config >>>>> <https://github.com/openwisp/openwisp-config> actively to step up and >>>>> help us maintain it so it's in good shape, starting from closing some of >>>>> the minor issues, preparing a change log for the current version, and >>>>> updating the lede feed. >>>>> >>>>> I think the key for success here is to start with small steps and then >>>>> start thinking about bigger changes as we go along and gain confidence. >>>>> >>>>> Federico >>>>> >>>>> >>>>> On Tuesday, December 5, 2017 at 6:51:48 AM UTC+1, Xavier Maysonnave >>>>> wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> With the Google Code-In I'm pretty happy to come back top OpenWisp2 >>>>>> and started with a tour around its ecosystem. >>>>>> I successfully installed the controller on one of our dedicated >>>>>> virtual machine. >>>>>> I started to play with openwisp-config and followed the available >>>>>> documentation. >>>>>> I realized that we can improve the current situation. >>>>>> Either LEDE or OpenWRT host the openwisp-config feed. >>>>>> >>>>>> Here is the content of the feed under the lede-17.01 branch: >>>>>> https://git.lede-project.org/?p=feed/packages.git;a=tree;f=admin;h= >>>>>> fdcf3fc3b9b87e332deb1d0e599acf17cdaddde0;hb=refs/heads/lede-17.01 >>>>>> >>>>>> If someone follow the documentation he needs to customize its >>>>>> feeds.conf with the following src-git: src-git openwisp >>>>>> https://github.com/openwisp/openwisp-config.git >>>>>> >>>>>> In that case the feed contains its definition and the package content >>>>>> . >>>>>> The documentation doesn't say that either OpenWRT and LEDE already >>>>>> contain the feed who target the 0.4.5 version. >>>>>> It sounds to me that this should be improved. OpenWISP could host two >>>>>> projects. >>>>>> One could be the feed itself without the package and another one who >>>>>> could be the package itself. >>>>>> The feed could reflect which version of LEDE we target (branch or >>>>>> tagged) in the LEDE spirit. >>>>>> To day at LEDE they have two branches, master and lede-17.01 and they >>>>>> have tagged version like v17.01.4. >>>>>> The feed are setup accordingly. >>>>>> >>>>>> Typically for the lede-17.01 branch the feeds.conf contains: >>>>>> src-git packages https://git.lede-project.org/ >>>>>> feed/packages.git;lede-17.01 >>>>>> >>>>>> while the v17.01.4 tagged version refers to : >>>>>> src-git packages https://git.lede-project.org/feed/packages.git^ >>>>>> cd5c448758f30868770b9ebf8b656c1a4211a240 >>>>>> >>>>>> If you play with feeds hosted on LEDE or OpenWRT you will retrieve >>>>>> the 0.4.5 version of openwisp-config. >>>>>> >>>>>> It sound reasonable to have the same pattern hosted at OpenWisp. >>>>>> Decoupling the feed from the package content and gives the >>>>>> flexibililty to choose the needed version: >>>>>> src-git: src-git openwisp https://github.com/openwisp/ >>>>>> openwisp-config.git;b54aded2336059e0be46f046992fabaae927ab46 >>>>>> the 0.4.5 version in that case or other version. >>>>>> >>>>>> Light >>>>>> >>>>>> Xavier >>>>>> / Pudhuveedu >>>>>> >>>>>> PGP Fingerprint: CAE5 CE4A EFE9 134F D991 5465 081C B6FB 2EAC 6CC9 >>>>>> <http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x081CB6FB2EAC6CC9> >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "OpenWISP" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "OpenWISP" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "OpenWISP" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OpenWISP" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "OpenWISP" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
