I strongly disagree with this model. Not only does it present potential new
contributors with an empty master branch, but it also is extremely involved
and time consuming.
Why pull in bugfixes regularly instead of cherrypicking on an as-needed
basis?
On Feb 8, 2015 7:01 PM, "PCMan" <pcman...@gmail.com> wrote:
> On Sun, Feb 8, 2015 at 10:44 PM, Jerome Leclanche <jer...@leclan.ch>
> wrote:
>
>> Workload is high, but I'm usually not a code contributor to LXQt so it
>> doesn't affect me as much. Still, with arch linux packaging duties on
>> top, I will eventually need someone else to pick up the slack.
>>
>> I did commit my release scripts to the repos, for what it's worth.
>>
>> J. Leclanche
>>
>> 2015-02-08 15:41 GMT+01:00 Helio Chissini de Castro <he...@kde.org>:
>> > I like this.
>> >
>> > Is very similar to waht we have on KDE and will make all modules more
>> > independent.
>> > Will make the release process a little bit harder, because from time
>> > to time we need to announce some modules or even one that had a minor
>> > update, but at same time, can move the process of release notes,
>> > security notes, and other related facts to module maintainer, making
>> > your job a minor process of review ans pass along.
>> >
>> > Tags on modules are decided by the module maintainer, and always under
>> > the main branch ( 0.9 ) today.
>> > master could be open to crazy new features.
>> >
>> > This model even allow to introduce new modules under a stable branch (
>> > 0.9 ), without affecting the process of development and even need to
>> > wait for a major full release.
>> >
>> > Is just decide how the process of deal with commits should go. Still
>> > doing pull requests or open the main repository for selected
>> > developers.
>> > Is a question on how much time and insight you have to deal with pull
>> > requests or not. Today is manageable, but assuming that more and more
>> > people will in some way join LXQt development, will be an extra work
>> > that would be solved by having access direct to master tree.
>> >
>> > []'s Helio
>> >
>> >
>> > On Sun, Feb 8, 2015 at 12:23 PM, Jerome Leclanche <jer...@leclan.ch>
>> wrote:
>> >> Hi Helio, you're right to raise this now. Let's include the whole ML
>> for this.
>> >>
>> >> The issue here is that our current development model is not fully
>> >> adapted to minor releases. As an alpha/beta product, we can afford
>> >> that and unless we come accross highly critical issues (security or
>> >> release-is-completely-borked), we don't need to deal with this stuff.
>> >> It saves a lot of time.
>> >>
>> >> That said, it is time to move to a better model as 1.0 is coming soon
>> >> and testing the product includes testing the release cycle :). The
>> >> current concern is that we have a lot of modules, all of which are on
>> >> one release cycle (liblxqt's). This is useful as doing one release per
>> >> component is fairly insane; depending on liblxqt instead gives us the
>> >> modularity we want without having to do this sort of cycle. For what
>> >> it's worth, lxde classic is on a fully independent cycle for all its
>> >> modules, but it also releases infrequently.
>> >>
>> >> I personally believe having *one* version is a lot less confusing for
>> >> the users, but we can't afford re-releasing the entire suite if we
>> >> find a security issue in eg. one of the panel plugins.
>> >>
>> >> My solution is to have a separate release dot for the components. In
>> >> essence, LXQt 0.9.0 would not be 0.9.0, but LXQt 0.9 and we'd have
>> >> lxqt-panel 0.9.0, lxqt-panel 0.9.1 etc. If a 0.9.1 seems needed in
>> >> such or such component we branch it off the tag at that point into
>> >> stable/0.9.1 - no need to do it earlier. This is actually compatible
>> >> with the current release process and seems very uninvasive. Thoughts?
>> >>
>> >> 2015-02-08 15:11 GMT+01:00 Helio Chissini de Castro <he...@kde.org>:
>> >>> Hello again guys
>> >>>
>> >>> I would like to raise the topic on the development and branch system.
>> >>>
>> >>> As 0.9.0 is out on the world, how is the proper procedure to go on
>> >>> minor releases ?
>> >>> The proper questions are:
>> >>>
>> >>> - Should we have a 0.9 branch ?
>> >>> - Should we need tag 0.9.0 to remember when the tarballs are set ?
>> >>> - Considering no branch will be done, how to avoid major features to
>> >>> be merged on master. We will follow the kernel mode where Jerome is
>> >>> the git master and will pick the proper pull requests, so never a
>> >>> branch ?
>> >>>
>> >>> I know this is too soon on the 0.9.0 release, but i'm already thinking
>> >>> on next minor and major releases as as well and concerned that if i
>> >>> want today compare the master with the released 0.8 and 0.9 releases,
>> >>> i would rely of not so exact method od the day of the tarballs.
>> >>>
>> >>> Sorry for annoying everyone on Sunday
>> >>> Have a good weekend, Helio
>> >
>>
>>
> This is the perfect time to discuss about the use of git branches.
> To not make things too complicated, here is a proposal for the new
> workflow.
>
> 1. The latest major release is kept in the master branch and is tagged.
> 2. Future bug fixes goes to master branch directly (after peer review if
> not trivial)
> 3. New features happen only in a separate "develop" branch, not the
> "master" branch.
> 4. After some bugs fixes, we make a minor release from the master branch,
> and add a tag for it.
> 5. Rebase the develop branch on master periodically to pull in new fixes.
> 6. When the develop branch is fully tested and is ready for production
> use, merge it back to master branch
> 7. Make a new release for the master branch, and go back to "1" again.
>
> This is a pretty simple model that is used by some projects.
> Any comments and thoughts?
>
> Cheers!
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Lxde-list mailing list
> Lxde-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxde-list
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list
