Re: [Lxde-list] [razor-qt] Re: Release plan, tarballs and translation issues.

[Jerome L. <ad...@gm...>]

Hi

On Wed, Mar 26, 2014 at 7:33 AM, Petr Vaněk <pe...@ya...> 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 raz...@go....
> For more options, visit https://groups.google.com/d/optout.

J. Leclanche