Hi On Wed, Mar 26, 2014 at 7:33 AM, Petr Vaněk <p...@yarpen.cz> wrote: > What about distro packages? Will we follow Razor's original proposal? > https://github.com/Razor-qt/razor-qt/wiki/Packaging > > I'll make packages for suse/fedora probably so I'm planning to take old > razor spec file as a base to create lxqt packages. ;) > > https://github.com/Razor-qt/razor-qt/wiki/Packaging > > On 26/03/14 07:47, PCMan wrote: >> Hello, >> Since most parts of the merged desktop work well, maybe we should have >> a release plan? >> Here are some problems: >> 1. Creating tarballs: Do we need some cmake macros to hellp create >> tarballs? (something like create_portable_header.cmake or >> create_pkgconfig) > > I try to simulate autotools "make dist" for cmake in all my projects. We had > it in Razor (top level CMakeLists.txt), line 188 > https://github.com/Razor-qt/razor-qt/blob/master/CMakeLists.txt > It's a very simple macro which can be included in all cmake based repos.
I will be taking care of Arch packaging on the AUR. I am adding Balló György, who is the maintainer of the current LXDE packages on Arch Linux. Balló: Please let me know if you would like the release packages to eventually end up in community/. As long as we have install instructions we should be fine. Current packaging is very standard, just cmake -DCMAKE_INSTALL_PREFIX=/usr && make && make DESTDIR=... install. > >> >> 2. How to give the components version numbers? Are there any rules? > > Not yet. We can chose what we want to. I'd like to have the same version for > all "core" packages, including libfm-qt probably. End user apps (image view) > can have their own version. On the other side the single version for all > stuff can help with users orientation. I agree with keeping common versioning for all core components. KDE has a similar policy. libfm, pcmanfm and lximage should have their own versioning so that they can have their own release schedule. > > >> >> 3. The translation workflow? Transifex, pootle, or both? > > I cannot say anything about translation. I was not involved in Razor > translation before too. I found just this simple howto: > https://github.com/Razor-qt/razor-qt/wiki/How-to-translate Well, I work on Pootle now so I can't not recommend it ;) I am not a translator though so in the end, it's up to what contributors would prefer. Still, I would probably be able to make life easier for us and help with setup/issues if we go with Pootle. > >> >> 4. Release schedule? > > Personally I don't care as I compile everything manually for myself. Lxqt > works for me now, so it can be released anytime, but I'm just simple user - > I don't use anything like removable devices, sound, etc. I suggest maintaining whatever makes developer life easier during alpha. My proposal would be: - Official "first alpha" release some time in May - No backports and *no upgrade paths* during alpha. - Try to stick to a rapid release schedule (4-8 weeks would be nice). This will force us to have an efficient release cycle. - Essentially no feature freeze before release, except maybe before the first one. > > Before release: > > We need a bugtracker before release definitely! So here's something that happened while we were talking about bug trackers... Github massively improved theirs. I am very comfortable recommending it as our main tracker. Incidentally, I honestly this will help bug reporting - a lot of people, especially in the Linux space, have Github accounts. Nobody has bugs.lxde accounts and none of the trackers do proper third party auth (except Mozilla's bugzilla tip which does Persona b ut I'm not sure if that's even available for the public). Creating an account is a big barrier of entry to reporting a bug - I must have reported hundreds of bugs to projects I've used no more than five minutes just because it was *that* accessible when they had their tracker on github. Let's also have bugs.lxqt.org (or maybe bugs.lxde.org? But this would take in gtk bugs) redirect to https://github.com/LXDE/lxde-qt/issues, with /123 redirecting to https://github.com/LXDE/lxde-qt/issue/123 and use those URLs. In the future, should Github become a crapfest, this will give us durable URLs. With that in mind, i suggest turning off component-specific bug trackers and have all issues tagged based on their component. https://github.com/Razor-qt/razor-qt/issues for inspiration. > > We need clear git workflow in meaning: this is the main repo and it's synced > to github every commit... Yes. Same reasoning as above: Let's have the main repo on git.lxde.org and have it mirrored on Github. And finally, we need the mailing lists set up. I saw you sent an email about this earlier. > > > my 2c, > petr > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Razor-qt" group. > For more options, visit this group at > http://groups.google.com/group/razor-qt?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "Razor-qt" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to razor-qt+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. J. Leclanche ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Lxde-list mailing list Lxde-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxde-list
