Release plan, tarballs and translation issues.

[PCMan]

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)
2. How to give the components version numbers? Are there any rules?
3. The translation workflow? Transifex, pootle, or both?
4. Release schedule?
5. Luis is working on building all of the components with a toplevel
CMakeLists.txt file. Are there any progress? Or, are there anything
needs to be fixed in the autotools stuff?

About the translation part, I'd like to ask Martin Baggie for details.
How exactly should pootle work with the xml *.ts files?
With gettext files, we only touch the template *.pot file and let you
merge the changes to other *.po files. With Qt *.ts xml files, how to
keep this work flow?
Should we only touch the template *.ts file and leave the task of
merging the changes to *.ts files of different languages to you?
By default the Qt linguist rules generated by cmake will update *.ts
files of all languages at the same time. To avoid conflicting with
pootle, we'll need to avoid committing other *.ts files and only
commit the template *.ts file to git. Then, you need to update the
other *.ts files by merging the new changes in the template. It seems
that the command "lconvert" does this, but doing this manually can be
time-consuming. Do you have better workflow?

Thank you all.

[Petr Vaněk]

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.

>
> 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.

>
> 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

>
> 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.

Before release:

We need a bugtracker before release definitely!

We need clear git workflow in meaning: this is the main repo and it's synced to github every commit...


my 2c,
petr

[Jerome Leclanche]

Hi

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

J. Leclanche

[Luís Pereira]

On Tue, Mar 25, 2014 at 11:47 PM, PCMan <pcma...@gmail.com> wrote:
> 5. Luis is working on building all of the components with a toplevel
> CMakeLists.txt file. Are there any progress? Or, are there anything
> needs to be fixed in the autotools stuff?

Hi.
I was absent due to personal stuff. I wrote an email stating my
absence but...... I didn't send it to the mailing list. Sorry :(

I need some changes in the autotools stuff. I will propose them on the
mailing list.
Regards,
--
Luís Pereira

[Jerome Leclanche]

We have a release planned on the 7th; if this is stuff that should go
in before 0.7.0, make sure to say so so that we can fast track it.
J. Leclanche